Closed ghost closed 9 years ago
Have a look in the cascaded branch: https://github.com/rm-hull/max7219/tree/cascaded
I never got it properly working though - it should be straightforward, but I put it down to a fault with the hardware / wiring - the 7219 chips I was using were cheap Chinese copies
ahh! I gotcha, I have 3 more 8 digit 7 segment displays on the way so I'll let you know how it goes when I get them! Building one of these: http://www.kotaku.com.au/2014/09/guy-3d-prints-actual-working-flight-computer-for-kerbal-space-program/
Already have one display working correctly(spitting out altitude)
Also could I just treat them as one long display and send a really big integer to them?
Yeah the cascaded branch is for the led matrix, i meant 7 segment
Ah, sorry assumed you were using the matrix. Never tried the 7 segment: someone else committed the code in the sevensegment directory.
How many digits have you got working?
AFAIK a single max7219 should be able to drive 8 digits - have you seen the datasheet: https://github.com/rm-hull/max7219/blob/master/doc/MAX7219-datasheet.pdf?raw=true ?
I have all 8 working on one. I will have 1 max per 8 digit display, so there will be enough there..Do the max chips have some kind of specific id to them? Yes I've looked at the datasheet. a lot of stuff I dont quite understand. New to this and new to python and still somewhat of a beginner programmer.
There's no ID; as far as i was aware, just the DOUT of the first chip should be connected to the DIN of the second chip, and it should just cascade the data out.
So now you got me interested again .... gonna buy a few of these and try it out again http://www.ebay.co.uk/itm/291289907453 :-)
Nice! when you say cascade, do you mean you would just send a 32 digit integer to the display and it would display across the 4?
if you send data through SPI to the first device, as each bit is clocked on the data in line, the previous bit should be pumped out on the data out, so that the second device 'sees' that data, one clock cycle later.
Try and picture it as a continuous stream of bits flowing through each device, and for every 8 bits that flows through, the chip interprets that 8 bit number as a command or data and do whatever
Say you have 4 devices cascaded, so what you would do is send some command and data bytes in sequence: 0xAA 0xBB 0xCC 0xDD :
0xAA 0xBB 0xCC 0xDD passes through the first chip, with 0xDD being the last thing it saw 0xAA 0xBB 0xCC passes through the second chip with 0xCC being the last thing it saw 0xAA 0xBB passes through the third chip with 0xBB being the last thing it saw 0xAA passes through the fourth chip with 0xAA being the last thing it saw
We intend 0xAA for the fourth chip, 0xBB for the third, 0xCC for the second and 0xDD for the first (basically in reverse order), and ignore the fact that the 0xAA, 0xBB, 0xCC flowed through earlier chips to get to their intended destinations.
That makes sense. Could you still use segment.writeInt() with a 32 digit int?
Browsing the datasheet, and it is a 16-bit latch, not 8 as i said earlier.
That segment.writeInt()
just sends tuples of (command, digit) eight times, once for each digit, but uses the low level led.send_byte(register, data)
, so fundamentally, you should be able to have the following python code display separate values on 4 different devices:
segment.writeInt(2343)
segment.writeInt(143395)
segment.writeInt(9815540)
segment.writeInt(60021199)
and it should just clock the values out
Brilliant! thanks for the help! I'll let you know how it goes whenever my extra displays come in!
Say I want to lead some of them with 0's. Is there a way I can do that with segment.writeInt? I can't seem to figure out a way to lead an integer with 0's that works. Also when using sebment.writeDigit could you use that to write to a 9th digit? If its not possible to writeInt with leading zeros, I could use writeDigit if I can figure out how I would cascade.
Haven't forgotten about this issue - just received 3 seven segment devices in the mail (took a while to arrive from China), so hopefully I'll be able to start experimenting a bit in the next few days
Sweet!
On Sat, Feb 7, 2015 at 12:22 PM, Richard Hull notifications@github.com wrote:
Haven't forgotten about this issue - just received 3 seven segment devices in the mail (took a while to arrive from China), so hopefully I'll be able to start experimenting a bit in the next few days
— Reply to this email directly or view it on GitHub https://github.com/rm-hull/max7219/issues/6#issuecomment-73376038.
My name is matthew, I am awesome and so is this signature.
-Matthew
Have you had any luck? Also if you try and run all 4, the last one is a little dim. Do you know a solution for that? I know very little about that.. edit: nevermind, just plug in the 3rd display in the chain into the other 5v rail on the pi! On Sat, Feb 7, 2015 at 2:49 PM, Akira akiraotomo@gmail.com wrote:
Sweet!
On Sat, Feb 7, 2015 at 12:22 PM, Richard Hull notifications@github.com wrote:
Haven't forgotten about this issue - just received 3 seven segment devices in the mail (took a while to arrive from China), so hopefully I'll be able to start experimenting a bit in the next few days
— Reply to this email directly or view it on GitHub https://github.com/rm-hull/max7219/issues/6#issuecomment-73376038.
My name is matthew, I am awesome and so is this signature.
-Matthew
My name is matthew, I am awesome and so is this signature.
-Matthew
Still haven't had a chance to look yet.
The datasheet mentions something about different brightness levels:
The example in Figure 3 drives 16 digits using a 3-wireµP interface. If the number of digits is not a multiple of 8, set both drivers’ scan limits registers to the same number so one display will not appear brighter than the other. For example, if 12 digits are need, use 6 digits per display with both scan-limit registers set for 6 digits so that both displays have a 1/6 duty cycle per digit. If 11 digits are needed, set both scan-limit registers for 6 digits and leave one digit driver unconnected. If one display for 6 digits and the other for 5 digits, the second display will appear brighter because its duty cycle per digit will be 1/5 while the first display’s will be 1/6. Refer to the No-Op Register Section for additional information.
See my edit..
On Thu, Feb 12, 2015 at 4:15 PM, Richard Hull notifications@github.com wrote:
Still haven't had a chance to look yet.
The datasheet mentions something about different brightness levels:
The example in Figure 3 drives 16 digits using a 3-wireµP interface. If the number of digits is not a multiple of 8, set both drivers’ scan limits registers to the same number so one display will not appear brighter than the other. For example, if 12 digits are need, use 6 digits per display with both scan-limit registers set for 6 digits so that both displays have a 1/6 duty cycle per digit. If 11 digits are needed, set both scan-limit registers for 6 digits and leave one digit driver unconnected. If one display for 6 digits and the other for 5 digits, the second display will appear brighter because its duty cycle per digit will be 1/5 while the first display’s will be 1/6. Refer to the No-Op Register Section for additional information.
— Reply to this email directly or view it on GitHub https://github.com/rm-hull/max7219/issues/6#issuecomment-74164996.
My name is matthew, I am awesome and so is this signature.
-Matthew
Have a look in the cascaded
branch now (https://github.com/rm-hull/max7219/tree/cascaded) - I rewrote the main LED driver, so it properly supports cascaded devices & there's a sevensegment helper class that does all the number formatting you could ask for: zero-padding, left/right justify, support for floats & decimal points, negative numbers, octal, hex...
See the example: https://github.com/rm-hull/max7219/blob/cascaded/examples/sevensegment_test.py
I've not done the matrix work yet, but that shouldn't take too much longer. When it is, I'll push it into master. Any bugs you find, please raise a new issue rather than tacking them on here.
Excellent! I accidentally fried 2 of my displays trying to solder them together with wires but I'll try and play with them. I actually started using a node module as I've been wanting to play around with node and have been able to get the to work that way!
On Fri, Feb 13, 2015 at 7:48 PM, Richard Hull notifications@github.com wrote:
Have a look in the cascaded branch now ( https://github.com/rm-hull/max7219/tree/cascaded) - I rewrote the main LED driver, so it properly supports cascaded devices & there's a sevensegment helper class that does all the number formatting you could ask for: zero-padding, left/right justify, support for floats & decimal points, negative numbers, octal, hex...
See the example: https://github.com/rm-hull/max7219/blob/cascaded/examples/sevensegment_test.py
I've not done the matrix work yet, but that shouldn't take too much longer. When it is, I'll push it into master. Any bugs you find, please raise a new issue rather than tacking them on here.
— Reply to this email directly or view it on GitHub https://github.com/rm-hull/max7219/issues/6#issuecomment-74355845.
My name is matthew, I am awesome and so is this signature.
-Matthew
max7219.led.sevensegment
class now in master. The old sevensegment/ directory is now deprecated and will be removed at some point in the future.
How would one go about writing to multiple max7219's daisy chained together?