Definitely is possible. Connect them so they are "daisy-chained" and you can program them with different patterns. Duane wrote drivers that are mentioned earlier in this thread.
Hai everyone , is possible two set module max7219 running with different pattern on LED dot matrix at the same signal line?
For example, one of dot matrix scrolling "L" to left another one dot matrix just display 'G' only.
The arrays don't scroll on their own. You have tell each array which LEDs to light with each new "frame" of a scroll.
I recently added a pair of arrays to my Halloween Hex and found the early code (which I wrote) very inconsistent in the direction of scroll and the orientation of the arrays.
I add a date stamp to the names of the code I write. There's two digits for the year, two digits for the month, two digits for the day of the month and the last character of the name is a version letter for the day. The later versions of my code should be more consistent than the earlier versions.
I'm trying to recall if there are any methods in the code I wrote which would make the task of scrolling just one array easier. I can't think of any. It's not an exceptionally difficult task once one understands how to shift bits in memory.
I plan to revisit my version of code soon in order to get to work better for my hexapod. I'll try to keep in mind a way to scroll just a portion of an array. I think it would be a useful feature.
I have wired up 4 of these displays and was really amazed at the brightness they give out...... even @3.3V supply to them
In the datasheet I read:
Logic High Input Voltage VIH 3.5 Volts
I was suspecting this being the cause of the intermittend problems I have,
running it from 5V and using Prop 3.3V directly as driver (OUTA)
(instead of pullup and driving with DIRA).
I have it just wildly wired on breadboard, maybe tis is the problem?
Thanks,
Markus
I think the "140128d" version is the latest and hopefully the best. The various versions of this code vary a lot. The way the arrays are arranged in memory in the Propeller has changed as I've updated the code. Depending on which LED arrays you use, the text could be displayed sideways.
Either way, the code should at least get the LEDs to turn on. I take it they're not? I'm powering my LEDs with 5V and using the Prop's 3.3V logic to drive the lines. According to Gareth, the arrays can be powered by 3.3V.
Just a quick question, if I may. Does this look doable? I will probably need a bigger motherboard, for future add-on's, one of them would be a barometer. I would appreciate your opinion.
Just a quick question, if I may. Does this look doable? I will probably need a bigger motherboard, for future add-on's, one of them would be a barometer. I would appreciate your opinion.
Thanks, Mike
Yes, that should work. You might what to use Tom's PASM driver to update the all the MAX7219 chips quickly. I found my Spin only driver a bit too slow when I attempted to scroll text or images with my 16 array board. I think Tom posted his driver in a different thread but I'm pretty sure I posted a link to his driver in this thread.
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.
I like the arrays from ICStation better than the arrays which use a DIP MAX7219 chip. While it's nice to have a socketed DIP chip, the socket and chip take up a lot of room and don't easily allow one to use 2 dimensional layouts of the arrays.
A couple of other things I want to include are the little audio amp on the left, it ran on 4.5V, but the chip may be rated @5V. Also I need a time reference, a DS1302 and a GPS initialized just for updating the time chip maybe once a month. And of course emic2, to get your attention. I was planning on FM radio, but I wonder if the RGB LED can somehow be updated to reflect the Terror Level Alert.
If the audio chip is rated for 4.5V that is probably because it was intended to run from three 1.5V batteries in series. It should run just fine from the 5V supply.
If the audio chip is rated for 4.5V that is probably because it was intended to run from three 1.5V batteries in series. It should run just fine from the 5V supply.
Yes, it uses the LM4871 which has a supply range from 2V-5.5V. From what I remember, it should have enough volume and clarity for this purpose. Thanks for the input.
The driver I wrote was specific to Duane's 32 x 32 array daisy-chained the way he did and oriented the way he did. It would not apply to a linear string like you have. That said, if you want to look at it as an example of initializing MAX7219's and rotating a data array to make the bits map onto the correct LED's here it is. tc
The driver I wrote was specific to Duane's 32 x 32 array daisy-chained the way he did and oriented the way he did. It would not apply to a linear string like you have. That said, if you want to look at it as an example of initializing MAX7219's and rotating a data array to make the bits map onto the correct LED's here it is. tc
That sounds like what I need, and I can learn a little PASM too.
I think I'd better swap side's with the motherboard and power board, as to have the Propeller closer to the MSD. What suffers with having ten arrays in series? If it was the constant scroll speed, could I just build a line at a time, with a pause in between?
By scrolling, I'm thinking you are talking about a Times Square display where a message moves from right to left across the display. Like this, except just one row.
The only down-side of having the arrays in series is that you might have a case where you need to send a bunch of no-ops in order to address the array you want. But if you update the entire ten arrays at once (as in the case of scrolling), even that won't happen. Also, if you update all ten arrays at once, it really doesn't matter which digit is closest. And, If you use PASM, scroll speed is not going to be an issue.
Yes that's the the way, from right to left. I never hooked up more than one of these at a time, till now. Duane's driver worked fine For up to four arrays, any more than that just don't synch properly. It will take me awhile to figure out your PASM driver, if I can. It should be a good learning experience, to try to come up with something to run ten of these in series, your driver should give me a good start, four of these just aren't enough information, if you don't catch it from the beginning.
You are referring to your driver, which I hadn't tried yet, this is a shot of Duane's MAX7219 spin demo, somewhat altered. I think I am going to mount these arrays before I go any farther, they are too frustrating to keep corralled loose on the table.
In the case of the data register question, I was asking about how the 8 x 8 matrix is wired. The Max has eight 8-bit data registers, a total of 64 bits for 64 LEDs. I was wondering whether each register was "wired" to a column or a row. I never knew how Duane's font was organized; my driver just took a 32 x 32 bit-map and mapped it onto the pixels. It all has to do with the most efficient way to organize the frame buffer.
Hey Mike, which version of the driver are you using? The limit of four arrays can likely be changed with a constant.
When I started writing drivers and layout circuit boards for these sorts of arrays, I didn't know what the common practice was. I used "horizontal bytes" since this is what made sense to me at the time. I have since come to understand why "vertical bytes" are so common.
If/when I ever layout another PCB, I'll likely rotate the way the array is addressed to use vertical bytes. OLED displays (at least the ones I've used) use vertical bytes.
@Tom, I'd love to hear any suggestions you may have on how I could have done things differently.
Hey Mike, which version of the driver are you using? The limit of four arrays can likely be changed with a constant.
I am using your Max7219MultiArray140116e. Which is the only version # I could find, outside or inside the document. I did change the constant (Arrays In Use) in the demo spin accordingly. I'm not seeing a CON statement in the driver that might refer to the number of arrays in use.
Wow thanks Duane, I am going to lay out and drill the wood tomorrow, I know I have enough of the same size and type screws, but I will have to make a trip to the hardware store for spacers, to mount the arrays. I'm not sure the PPDB will handle ten arrays on its five volt regulator, but I have other options for the short term. As far as scrolling speed, it isn't critical, unless it is annoyingly slow.
I couldn't wait to try the changes in the demo and driver, still anything over four arrays produced erratic results, I am going to work on the software end of this first, want to make sure it is a valid concept before I get too involved with the hardware end.
Does it still work reliably with four arrays? What happens when there are five arrays?.
There are several things I can think of which would cause problems with longer rows of arrays. One problem is providing enough power to all the arrays but another problem is driving the clock and latch lines on lots arrays. You might need some sort of hardware buffer to drive the clock and latch lines.
The data line shouldn't cause you a problem with multiple arrays since the MAX7219 chip drive the data line to the next array in the row.
I'm pretty sure I've driven the clock and latch lines on I've driven 96 MAX7219 chips with a Propeller. I have six of my 16 small array PCBs wired together to make a display of a total of 96 arrays. I'm pretty sure the Prop was able to drive all these chips just fine. I did have to be careful about what power supply I used.
I think you should try two different experiments.
1. What happens when you use software for four arrays with five arrays? The fifth array should repeat the output of the first array but one frame later.
2. What happens when you use software for five (or more) arrays with four arrays? If only four arrays are connected with software intended for a larger display, the four arrays should still behave correctly.
I will try both of the experiments you recommended, I started out hooking up all ten to the PPDB five volt supply, in the test mode, all LED's turned on, but somewhat dimmed, monitoring the temperature of the on board regulator, it heated up pretty quick, so I didn't leave it in that configuration very long. With five arrays and programmed for five, I did see a copy of the second array in the chain.
I don't have that chip on hand, this could be substituted?
@Tom, I'd love to hear any suggestions you may have on how I could have done things differently.
I was mostly thinking about how to organize the buffers. In the case of your 32x32 array, there is really no question; just a regular bit map of 32 longs. Now that does mean some serious re-organizing in the driver because each bit in a MAX7219 data register comes from a different long but the propellor is very good at shuffling bits. If the Max7219 had been wired so that each Max register controlled a line other than a column, it would have matched the bit map a little better.
In Mike's case, IF each data register in the MAX controls one column (that depends on how the MAX is wired to the LEDs) then it might make more sense to organize the buffer as a string of columns. It could either be a circular buffer or you can shift it in memory. Now if your font is also organized by column (and I ave one that is), everything lines up perfectly. You shift the buffer (either physically or by pointer), stick the new column in at the right "end", and re-write the matrix. I got a perfectly acceptable scroll speed on a 64-column display with a BS-2 (px?), so I'm pretty sure one could do 80 columns in SPIN.
1. What happens when you use software for four arrays with five arrays? The fifth array should repeat the output of the first array but one frame later.
2. What happens when you use software for five (or more) arrays with four arrays? If only four arrays are connected with software intended for a larger display, the four arrays should still behave correctly.
1. It does work reliably with four arrays, but hot swapping the fifth into the circuit, produces garble on all but the first, same after power down and back up.
2. Software for five or more works fine for four arrays.
It seems like the problem could be the latch and clock lines, are just too weak to run more than four.
Comments
The arrays don't scroll on their own. You have tell each array which LEDs to light with each new "frame" of a scroll.
Make sure and check out Tom's code in the other thread about these arrays. The code attached early in this thread is not consistent with the order or orientation of the arrays.
I recently added a pair of arrays to my Halloween Hex and found the early code (which I wrote) very inconsistent in the direction of scroll and the orientation of the arrays.
I add a date stamp to the names of the code I write. There's two digits for the year, two digits for the month, two digits for the day of the month and the last character of the name is a version letter for the day. The later versions of my code should be more consistent than the earlier versions.
I'm trying to recall if there are any methods in the code I wrote which would make the task of scrolling just one array easier. I can't think of any. It's not an exceptionally difficult task once one understands how to shift bits in memory.
I plan to revisit my version of code soon in order to get to work better for my hexapod. I'll try to keep in mind a way to scroll just a portion of an array. I think it would be a useful feature.
I was suspecting this being the cause of the intermittend problems I have,
running it from 5V and using Prop 3.3V directly as driver (OUTA)
(instead of pullup and driving with DIRA).
I have it just wildly wired on breadboard, maybe tis is the problem?
Thanks,
Markus
I think the "140128d" version is the latest and hopefully the best. The various versions of this code vary a lot. The way the arrays are arranged in memory in the Propeller has changed as I've updated the code. Depending on which LED arrays you use, the text could be displayed sideways.
Either way, the code should at least get the LEDs to turn on. I take it they're not? I'm powering my LEDs with 5V and using the Prop's 3.3V logic to drive the lines. According to Gareth, the arrays can be powered by 3.3V.
Just a quick question, if I may. Does this look doable? I will probably need a bigger motherboard, for future add-on's, one of them would be a barometer. I would appreciate your opinion.
Thanks, Mike
Yes, that should work. You might what to use Tom's PASM driver to update the all the MAX7219 chips quickly. I found my Spin only driver a bit too slow when I attempted to scroll text or images with my 16 array board. I think Tom posted his driver in a different thread but I'm pretty sure I posted a link to his driver in this thread.
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.
I like the arrays from ICStation better than the arrays which use a DIP MAX7219 chip. While it's nice to have a socketed DIP chip, the socket and chip take up a lot of room and don't easily allow one to use 2 dimensional layouts of the arrays.
Sometimes all the stuff erco has made me buy makes me laugh at loud as well. Usually it just makes me cry out loud. COL
At least I was able to resist purchasing the "space station."
A couple of other things I want to include are the little audio amp on the left, it ran on 4.5V, but the chip may be rated @5V. Also I need a time reference, a DS1302 and a GPS initialized just for updating the time chip maybe once a month. And of course emic2, to get your attention. I was planning on FM radio, but I wonder if the RGB LED can somehow be updated to reflect the Terror Level Alert.
Thanks for the help.
Mike
erco needs to sell a t-shirt on these forums that says, "erco made me buy it!"
Yes, it uses the LM4871 which has a supply range from 2V-5.5V. From what I remember, it should have enough volume and clarity for this purpose. Thanks for the input.
The driver I wrote was specific to Duane's 32 x 32 array daisy-chained the way he did and oriented the way he did. It would not apply to a linear string like you have. That said, if you want to look at it as an example of initializing MAX7219's and rotating a data array to make the bits map onto the correct LED's here it is. tc
That sounds like what I need, and I can learn a little PASM too.
Thanks Tom.
Like this, except just one row.
The only down-side of having the arrays in series is that you might have a case where you need to send a bunch of no-ops in order to address the array you want. But if you update the entire ten arrays at once (as in the case of scrolling), even that won't happen. Also, if you update all ten arrays at once, it really doesn't matter which digit is closest. And, If you use PASM, scroll speed is not going to be an issue.
Thanks Tom.
And when you retrieve an element from your font, do you get a column or row?
When I started writing drivers and layout circuit boards for these sorts of arrays, I didn't know what the common practice was. I used "horizontal bytes" since this is what made sense to me at the time. I have since come to understand why "vertical bytes" are so common.
If/when I ever layout another PCB, I'll likely rotate the way the array is addressed to use vertical bytes. OLED displays (at least the ones I've used) use vertical bytes.
@Tom, I'd love to hear any suggestions you may have on how I could have done things differently.
I am using your Max7219MultiArray140116e. Which is the only version # I could find, outside or inside the document. I did change the constant (Arrays In Use) in the demo spin accordingly. I'm not seeing a CON statement in the driver that might refer to the number of arrays in use.
You should be able to change this to any reasonable value. A larger value will likely slow down the maximum scroll speed.
There are several things I can think of which would cause problems with longer rows of arrays. One problem is providing enough power to all the arrays but another problem is driving the clock and latch lines on lots arrays. You might need some sort of hardware buffer to drive the clock and latch lines.
The data line shouldn't cause you a problem with multiple arrays since the MAX7219 chip drive the data line to the next array in the row.
Here's an example of a buffer chip you could use.
I'm pretty sure I've driven the clock and latch lines on I've driven 96 MAX7219 chips with a Propeller. I have six of my 16 small array PCBs wired together to make a display of a total of 96 arrays. I'm pretty sure the Prop was able to drive all these chips just fine. I did have to be careful about what power supply I used.
I think you should try two different experiments.
1. What happens when you use software for four arrays with five arrays? The fifth array should repeat the output of the first array but one frame later.
2. What happens when you use software for five (or more) arrays with four arrays? If only four arrays are connected with software intended for a larger display, the four arrays should still behave correctly.
I don't have that chip on hand, this could be substituted?
I was mostly thinking about how to organize the buffers. In the case of your 32x32 array, there is really no question; just a regular bit map of 32 longs. Now that does mean some serious re-organizing in the driver because each bit in a MAX7219 data register comes from a different long but the propellor is very good at shuffling bits. If the Max7219 had been wired so that each Max register controlled a line other than a column, it would have matched the bit map a little better.
In Mike's case, IF each data register in the MAX controls one column (that depends on how the MAX is wired to the LEDs) then it might make more sense to organize the buffer as a string of columns. It could either be a circular buffer or you can shift it in memory. Now if your font is also organized by column (and I ave one that is), everything lines up perfectly. You shift the buffer (either physically or by pointer), stick the new column in at the right "end", and re-write the matrix. I got a perfectly acceptable scroll speed on a 64-column display with a BS-2 (px?), so I'm pretty sure one could do 80 columns in SPIN.
1. It does work reliably with four arrays, but hot swapping the fifth into the circuit, produces garble on all but the first, same after power down and back up.
2. Software for five or more works fine for four arrays.
It seems like the problem could be the latch and clock lines, are just too weak to run more than four.