It's been long enough that I don't remember what exactly the issue was, just that the drivers I found I struggled with. The only driver in OBEX is not for 8x8 modules but for 7-segment display.
I haven't had any time to work on my message board because of babysitting, but it didn't stop me from grabbing a Propeller and display, and mess with Duane's eye methods.
Duane if you have an updated version you would like to share, but maybe that is something you want to keep specific to your Hexbot crawler. I would be happy with a link to a video, that shows off your bots movable eyes. I thought that gave your robot instant personality, really cool!
Here's a dissected version of Duane's demo with his 'Max7219MultiArray140116e' driver, don't forget to specify how many arrays your set-up has, that is: 'ARRAYS_IN_USE =' in the demo, and 'MAX_ARRAY_ALLOWED =' in the driver. And also include the added resistors so the display doesn't go into test mode.
Duane if you have an updated version you would like to share, but maybe that is something you want to keep specific to your Hexbot crawler. I would be happy with a link to a video, that shows off your bots movable eyes. I thought that gave your robot instant personality, really cool!
I was really pleased with how much personality the LED eyes gave my hexapod.
I don't think I specifically documented the eyes anywhere. I got the idea from a friend in Brazil who make amazing robots.
Here's the video he made which inspired me to use these arrays as robot eyes.
I posted some photos and a video showing the gimbals I used in erco's $300 robot arm thread. These gimbals can be found for less than $3 on ebay. Adafruit sells these gimbals both with and without servos. They're generally sold without servos. I used HobbyKing's HXT900 servos but I used a black Sharpie to turn the blue servo black.
IIRC, ICStaion sold this gimbals with black horns. Not all the gimbals being sold include black servo horns. This isn't really big deal but it saves one the hassle of trimming other servo horns to the correct size and coloring them black (if desired).
Here's a photo of the gimbals without the LED arrays.
I used the arrays sold by ICStation. IIRC, I cut a notch (maybe one or two millimeters deep) in the PCB in order to fit the PCB inside the plastic clips of the gimbals. I wrapped a piece of black Gorrilla Tape around the edge of the array and PCB to hide the electronics and wires.
I didn't use header pins on the LED PCBs since there really wasn't room for a proper connector. I just soldered wires directly to the PCB.
To cut down on the number of wires going to the eyes, I modified the servo wires so the two servos and the LEDs shared a single set of power lines. Each eye had 5V, ground, two servo signals and the three LED control lines. One eye also had a data return line which was fed back up to the other eye.
A reason there aren't drivers for 8x8 array using MAX7219 is that there really isn't a standard way to wire the LEDs. You cannot know ahead of time which LED is connected to which bit in the eight data registers. Add to that you cannot know ahead of time how the 8x8 arrays are connected to each other. And then somebody physically rotates the array of arrays.
Here is a driver I did for Duane's 4x4 array (32 x 32) which scrolls text. It includes a 5x7 font with descenders and a few pithy sayings.
I did have to go to PASM to get acceptable scrolling. The fastest SPI interface I could manage in SPIN was less than 30 kB/sec; it took 100 mSec to update the screen. In PASM, it takes about 1 mSec.
I bought a couple of gimbals off of eBay, and they look identical. One of them arrived pre-broken, I used the other for a board camera, I used mini servos from RS, because they were on clearance, all of there servos have overshoot which is annoying.
I was really interested in your code for eye animation, I wondered if you had a tweaked version? Your demo has a lot going on, with menus and display adjustments. It is a little confusing for me, but that's easily done.
EDIT: BTW I will re-map the eyes, don't want to steal your bots individualism.
I did have to go to PASM to get acceptable scrolling. The fastest SPI interface I could manage in SPIN was less than 30 kB/sec; it took 100 mSec to update the screen. In PASM, it takes about 1 mSec.
I tried your driver this morning, the first thought that came to mind was: 'Times Square', that really moves the information around.
The MAX7219 demo code is very simple compared with the hexapod code. IIRC, I have one program to load data and PASM code into the upper EEPROM. The main code pulls the PASM code from upper EEPROM and loads it into a cog. I had to use these memory tricks to get all the code to fit.
I'm afraid the eye animation code isn't very well compartmentalized from the other code. I'm not sure, but I think the eye patterns are stored in upper EEPROM. I don't mind sharing my hexapod code which includes the eye animation code but I'd be surprised if you find it useful.
While I doubt the hexapod code will be useful, I'll let you make up your own mind about using parts of it or not. I've attached the two archives I use with my hexapod. As I mentioned, I had to load the EEPROM with data in order to fit all the functionality I wanted into the Propeller.
I looked around on my hard drive and I found a couple likely candidates of possibly working code. I've attached two archives I found which look promising.
The main code "HexapodWithLeds", makes use of data stored in the upper EEPROM. I use the program "LoadToEeprom" to load the appropriate data to the upper EEPROM. This of course requires a Propeller board which uses a 64K (or larger) EEPROM. Most of the Propeller boards Parallax sells have 64K EEPROMs so this shouldn't be a problem.
While I think these two archive belong with each other but I'm not absolutely sure. The version dates are about a week apart. I think the reason the "LoadToEeprom" code is dated a week later is because I cleaned up the code a bit in order to post it to the forum (in February of 2015). I assume (I hope correctly) since these two programs were in an archived state on my hard drive, they work reasonably well.
I believe the eye related code is in the methods with "Eye" or "Blink" in the name. You might be able to find some helpful code in these methods but it might be easier to come up with your own code.
The eye control code doesn't shouldn't very complicated but the code I wrote sure looks complicated. I think a lot of what you'll want the eyes to do will depend on your robot's control system. I had the eyes look towards the direction of travel. It looks like I had more than one sort of control strategy I used with the eyes. I remember having the eyes look towards the direction of travel but I'm not sure if I fully implemented the other control strategies.
The attached code is in such a disorganized state I don't want to leave it here on the forum for very long. I'll likely delete the attached code in a day or two.
I tried this again, with both drivers, and got the same type of results - a lot of flashing and partial display of letters. I guess I have some bad modules with cheapo clone chips.
I tried this again, with both drivers, and got the same type of results - a lot of flashing and partial display of letters. I guess I have some bad modules with cheapo clone chips.
What sort of power supply are you using?
It might help if you posted a photo of your setup.
I'm betting the displays I'm using have cloned chips. There'are likely some differences between the real and fake chips but the fake chips should at least work.
I couldn't find a post with information about what sort of displays you're using. Are they like the ones Mike has or like this one from ICStation.
Without knowing more details, my first guess is it's a power supply issue.
OK, I got it working. There was a bad connection in one of the wires. Aaargh.
I have the cheap ebay models. Some of them came without the electrolytic cap installed! I had extras so that was fixed easily.
And I realized I had too small a power supply, and swapped in a 5V 1A supply. Both demos now work well.
Duane - is yours set up to have the four modules in a square instead of a line? I notice if you set it to four modules, the effect seems to break in the middle and wrap around to the right side.
Duane - is yours set up to have the four modules in a square instead of a line? I notice if you set it to four modules, the effect seems to break in the middle and wrap around to the right side.
No, it should be one continuous line. I posted a video earlier in this thread showing four arrays in use.
You need to make sure you have the constants Mike mentioned earlier set correctly. There is a constant in both the parent and the child object which needs to be set to the number of arrays being used.
Duane - is yours set up to have the four modules in a square instead of a line? I notice if you set it to four modules, the effect seems to break in the middle and wrap around to the right side.
Don't forget to change the value of 'rotatedFlag := 0' to a '1' in the demo, or the displays will scroll in the wrong direction.
I thought the number of arrays was only set from the parent:
Author: Duane Degn
Date: December 25, 2013
Updated" January 27, 2014
MIT License
An attempt to control an 8x8 LED array with a MAX7219 chip.
The number of arrays used should be set from the parent object.
I can't find 'MAX_ARRAY_ALLOWED =' in the driver. (Max7219MultiArray140128a)
Mike - I've got your version of the demo, which has rotatedFlag set to 1.
Oh, so you're using one version back. A lot of differences in the demo.
Also, as Tom mentioned above, there is a difference in the way the modules are hooked up. Tom's code works with the modules this way, with the Prop connected to module #1, and the MAX chip on the bottom:
1 2 3 4
Duane's works this way:
4 3 2 1
Once I swapped the cables around, Duane's code works fine, but then Tom's doesn't.
@Jeff Haas, Yes the two demo's are different, as for how the boards are oriented, glad you got them going! It's a bummer when you think you bought a piece of junk.
@Duane Degn, Thanks for posting your hexpod's code, and you we're almost right, "complicated" is a mild word for it.
It's interesting to see the different methods used to control your robot. There's more than a few lessons to be learned here. I'm sure between that and your MAX7219 driver, I can get something going, we have been watching grandkids a lot lately, so getting some piece and quiet to concentrate on anything, hasn't been an option.
I'm afraid I didn't really know what I was doing when I wrote the MAX7219 drivers attached to this thread. The order of the arrays is not consistent among all the drivers. I think the later drivers arrange the arrays in a more conventional manner than my first attempt at writing a driver.
Since using these arrays, I've played with some OLED displays. My experience with the OLED display made me realize there are better ways to arrange pixels than the way I arranged them in the boards I made.
I think I used version 140116e when I made the video near the beginning of this thread.
@Duane Degn, Thanks for posting your hexpod's code, and you we're almost right, "complicated" is a mild word for it.
It's interesting to see the different methods used to control your robot. There's more than a few lessons to be learned here. I'm sure between that and your MAX7219 driver, I can get something going, we have been watching grandkids a lot lately, so getting some piece and quiet to concentrate on anything, hasn't been an option.
I'm not at all proud of the code I posted. I'm glad I got the hexapod to walk reasonably well but I think the code is much too convoluted. I hope you don't pick up any bad programming habits from reading the code.
I was a little whiny earlier when discussing how hard it is to cater to various connections of MX7219s. If you think about a linear string of 8x8 modules, there are (I think) 16 possible ways to wire things up:
a write to a mx register can drive a column or a row
bit zero of a mx register can connect to either top or bottom LED or the right/left LED
register 1 can connect to either the top or bottom or (left or right) row or column
the module closest to the computer can be on the left or the right
Now the first (a register is connected to a row or a column) case certainly controls how you arrange the bit map, two drivers of eight cases each certainly should be do-able.
Now the first (a register is connected to a row or a column) case certainly controls how you arrange the bit map, two drivers of eight cases each certainly should be do-able.
The possible ways bits can be mapped to pixels gets even more complicated with more than a single line of arrays are used. When multiple rows of arrays are used, the arrays can either wrap around or zigzag.
For example my 4x4 PCB arranges the arrays in the following pattern.
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
I've seen other arrays arranged this way:
1 2 3 4
8 7 6 5
9 10 11 12
16 15 14 13
The second arrangement is a bit less intuitive but it allows one to use shorter wires/traces between arrays. I'm not sure which option is the best.
Here is a driver that caters to modules connected in a linear stick in either direction. You set SwapModules in the CON area to either 0 or 1
This is all I need for my message board, I just removed a couple things I don't need like the brightness demo and pst, not sure what you used the terminal for, message input or control on the fly?
and I added ten lines of text to scroll, that could be an unlimited amount. I want to be able to swap fonts, I like Duane's "freeDesign" in his spin driver, it gives a nice effect. But that is a 8x8 font, and takes advantage of the full display, it will take some doing.
BTW: your PASM driver is very well commented, and is a great lesson in how you got things done.
I'm not at all proud of the code I posted. I'm glad I got the hexapod to walk reasonably well but I think the code is much too convoluted. I hope you don't pick up any bad programming habits from reading the code
Never apologize, pilgrim. It's a sign of weakness. :thumb:
Duane, I've been reading this forum for six or seven years now and you are among the top three or four people as far as giving unstintingly of your time helping others. Sometime people post code that's not as polished as s/he would like, but by God, at least you post code. That's all I've got to say on that topic. tc
Happy to get eight going, I think if I boost the signals again halfway through the arrays, it will be a stable display. Right now it falls apart adding another module. Time to start building this thing.
Here are some pictures of a Duane 4x4 array of arrays. The test pattern is just incrementing values (makes it easy to see what's going on).
1. Normal is standard display set up for left-to-right scrolling.
2. SwapModule is the modules reversed. Displayed as though top-left module was furthest from computer.
3. SwapColumn is columns within each module are swapped.
4. SwapModAndCol is modules swapped and columns within modules swapped. Note complete left-to-right swap.
5. SwapBits is bits within columns swapped. Upside down by module.
I want formally thank Duane and Tom, for all their help with these displays, I couldn't make a message board without your help. Also I now have some robot eyes for another project.
Comments
I haven't had any time to work on my message board because of babysitting, but it didn't stop me from grabbing a Propeller and display, and mess with Duane's eye methods.
Duane if you have an updated version you would like to share, but maybe that is something you want to keep specific to your Hexbot crawler. I would be happy with a link to a video, that shows off your bots movable eyes. I thought that gave your robot instant personality, really cool!
Here's a dissected version of Duane's demo with his 'Max7219MultiArray140116e' driver, don't forget to specify how many arrays your set-up has, that is: 'ARRAYS_IN_USE =' in the demo, and 'MAX_ARRAY_ALLOWED =' in the driver. And also include the added resistors so the display doesn't go into test mode.
I was really pleased with how much personality the LED eyes gave my hexapod.
I don't think I specifically documented the eyes anywhere. I got the idea from a friend in Brazil who make amazing robots.
Here's the video he made which inspired me to use these arrays as robot eyes.
I posted some photos and a video showing the gimbals I used in erco's $300 robot arm thread. These gimbals can be found for less than $3 on ebay. Adafruit sells these gimbals both with and without servos. They're generally sold without servos. I used HobbyKing's HXT900 servos but I used a black Sharpie to turn the blue servo black.
IIRC, ICStaion sold this gimbals with black horns. Not all the gimbals being sold include black servo horns. This isn't really big deal but it saves one the hassle of trimming other servo horns to the correct size and coloring them black (if desired).
Here's a photo of the gimbals without the LED arrays.
I used the arrays sold by ICStation. IIRC, I cut a notch (maybe one or two millimeters deep) in the PCB in order to fit the PCB inside the plastic clips of the gimbals. I wrapped a piece of black Gorrilla Tape around the edge of the array and PCB to hide the electronics and wires.
I didn't use header pins on the LED PCBs since there really wasn't room for a proper connector. I just soldered wires directly to the PCB.
To cut down on the number of wires going to the eyes, I modified the servo wires so the two servos and the LEDs shared a single set of power lines. Each eye had 5V, ground, two servo signals and the three LED control lines. One eye also had a data return line which was fed back up to the other eye.
Here is a driver I did for Duane's 4x4 array (32 x 32) which scrolls text. It includes a 5x7 font with descenders and a few pithy sayings.
I did have to go to PASM to get acceptable scrolling. The fastest SPI interface I could manage in SPIN was less than 30 kB/sec; it took 100 mSec to update the screen. In PASM, it takes about 1 mSec.
I was really interested in your code for eye animation, I wondered if you had a tweaked version? Your demo has a lot going on, with menus and display adjustments. It is a little confusing for me, but that's easily done.
EDIT: BTW I will re-map the eyes, don't want to steal your bots individualism.
I tried your driver this morning, the first thought that came to mind was: 'Times Square', that really moves the information around.
Thanks Tom for the help.
I'm afraid the eye animation code isn't very well compartmentalized from the other code. I'm not sure, but I think the eye patterns are stored in upper EEPROM. I don't mind sharing my hexapod code which includes the eye animation code but I'd be surprised if you find it useful.
While I doubt the hexapod code will be useful, I'll let you make up your own mind about using parts of it or not. I've attached the two archives I use with my hexapod. As I mentioned, I had to load the EEPROM with data in order to fit all the functionality I wanted into the Propeller.
I looked around on my hard drive and I found a couple likely candidates of possibly working code. I've attached two archives I found which look promising.
The main code "HexapodWithLeds", makes use of data stored in the upper EEPROM. I use the program "LoadToEeprom" to load the appropriate data to the upper EEPROM. This of course requires a Propeller board which uses a 64K (or larger) EEPROM. Most of the Propeller boards Parallax sells have 64K EEPROMs so this shouldn't be a problem.
While I think these two archive belong with each other but I'm not absolutely sure. The version dates are about a week apart. I think the reason the "LoadToEeprom" code is dated a week later is because I cleaned up the code a bit in order to post it to the forum (in February of 2015). I assume (I hope correctly) since these two programs were in an archived state on my hard drive, they work reasonably well.
I believe the eye related code is in the methods with "Eye" or "Blink" in the name. You might be able to find some helpful code in these methods but it might be easier to come up with your own code.
The eye control code doesn't shouldn't very complicated but the code I wrote sure looks complicated. I think a lot of what you'll want the eyes to do will depend on your robot's control system. I had the eyes look towards the direction of travel. It looks like I had more than one sort of control strategy I used with the eyes. I remember having the eyes look towards the direction of travel but I'm not sure if I fully implemented the other control strategies.
The attached code is in such a disorganized state I don't want to leave it here on the forum for very long. I'll likely delete the attached code in a day or two.
What sort of power supply are you using?
It might help if you posted a photo of your setup.
I'm betting the displays I'm using have cloned chips. There'are likely some differences between the real and fake chips but the fake chips should at least work.
I couldn't find a post with information about what sort of displays you're using. Are they like the ones Mike has or like this one from ICStation.
Without knowing more details, my first guess is it's a power supply issue.
I have the cheap ebay models. Some of them came without the electrolytic cap installed! I had extras so that was fixed easily.
And I realized I had too small a power supply, and swapped in a 5V 1A supply. Both demos now work well.
Duane - is yours set up to have the four modules in a square instead of a line? I notice if you set it to four modules, the effect seems to break in the middle and wrap around to the right side.
No, it should be one continuous line. I posted a video earlier in this thread showing four arrays in use.
You need to make sure you have the constants Mike mentioned earlier set correctly. There is a constant in both the parent and the child object which needs to be set to the number of arrays being used.
Don't forget to change the value of 'rotatedFlag := 0' to a '1' in the demo, or the displays will scroll in the wrong direction.
I can't find 'MAX_ARRAY_ALLOWED =' in the driver. (Max7219MultiArray140128a)
Mike - I've got your version of the demo, which has rotatedFlag set to 1.
Also, as Tom mentioned above, there is a difference in the way the modules are hooked up. Tom's code works with the modules this way, with the Prop connected to module #1, and the MAX chip on the bottom:
1 2 3 4
Duane's works this way:
4 3 2 1
Once I swapped the cables around, Duane's code works fine, but then Tom's doesn't.
@Duane Degn, Thanks for posting your hexpod's code, and you we're almost right, "complicated" is a mild word for it.
It's interesting to see the different methods used to control your robot. There's more than a few lessons to be learned here. I'm sure between that and your MAX7219 driver, I can get something going, we have been watching grandkids a lot lately, so getting some piece and quiet to concentrate on anything, hasn't been an option.
Yeah, that's my fault. I didn't know what I was doing when I first wrote my driver.
Since using these arrays, I've played with some OLED displays. My experience with the OLED display made me realize there are better ways to arrange pixels than the way I arranged them in the boards I made.
I think I used version 140116e when I made the video near the beginning of this thread.
I'm not at all proud of the code I posted. I'm glad I got the hexapod to walk reasonably well but I think the code is much too convoluted. I hope you don't pick up any bad programming habits from reading the code.
I have a bad memory.
Now the first (a register is connected to a row or a column) case certainly controls how you arrange the bit map, two drivers of eight cases each certainly should be do-able.
The possible ways bits can be mapped to pixels gets even more complicated with more than a single line of arrays are used. When multiple rows of arrays are used, the arrays can either wrap around or zigzag.
For example my 4x4 PCB arranges the arrays in the following pattern.
I've seen other arrays arranged this way:
The second arrangement is a bit less intuitive but it allows one to use shorter wires/traces between arrays. I'm not sure which option is the best.
This is all I need for my message board, I just removed a couple things I don't need like the brightness demo and pst, not sure what you used the terminal for, message input or control on the fly?
and I added ten lines of text to scroll, that could be an unlimited amount. I want to be able to swap fonts, I like Duane's "freeDesign" in his spin driver, it gives a nice effect. But that is a 8x8 font, and takes advantage of the full display, it will take some doing.
BTW: your PASM driver is very well commented, and is a great lesson in how you got things done.
Mike Y.
Never apologize, pilgrim. It's a sign of weakness. :thumb:
Duane, I've been reading this forum for six or seven years now and you are among the top three or four people as far as giving unstintingly of your time helping others. Sometime people post code that's not as polished as s/he would like, but by God, at least you post code. That's all I've got to say on that topic. tc
http://forums.parallax.com/discussion/164759/hexapods-dance#latest
1. Normal is standard display set up for left-to-right scrolling.
2. SwapModule is the modules reversed. Displayed as though top-left module was furthest from computer.
3. SwapColumn is columns within each module are swapped.
4. SwapModAndCol is modules swapped and columns within modules swapped. Note complete left-to-right swap.
5. SwapBits is bits within columns swapped. Upside down by module.
Thanks again guys.
Mike Y.