Hi all,
I'm hoping someone can help, I sourced these great seven segment LED boards form China and am trying to get them working with the Netduino.
It appears to show in the manual they are driven with SPI. But I'm struggling even to find the correct connection for the wires.
I'm hoping someone is willing to help make sense of this display, as I think it could be useful to others as well.
Link to webpage:
http://www.sureelect...oods.php?id=135
Many thanks in advance.
Logicalstep
SPI LED
Started by logicalstep, Jun 12 2012 10:37 PM
4 replies to this topic
#1
Posted 12 June 2012 - 10:37 PM
#2
Posted 13 June 2012 - 04:27 AM
Hello Logicalstep.
If you take a look at the schematic (specs, fig. 4), the circuit is very simple: there are 4 74HC595 chained, plus the led drivers (ULN2003). The same board is also chainable with others boards in cascade.
Well, about the signals, it looks pretty easy:
Please, also note that there's no SS involved in the circuit, so you can't share the SPI with other devices. Basically, the display board will always "listen to" any flowing data through the SPI, and there's no (easy) way to avoid it.
After that, the software should also be easy to write.
Just take advantage by the small program I've used in my article about the noise: http://highfieldtale...igital-signals/
It's curiously related to a display, even the digits pattern is *NOT* the same. However, the 74HC595 SPI configuration, and the data transfer should be already okay.
To send a digit pattern to the first display, you should fill a 7-bits buffer (i.e. just one byte) with the desired pattern: a bit set means the segment lit. For four displays, the buffer has to be 28-bits long (i.e. 4 bytes), but *be careful* they must be "packed". I wonder why they chosen an harder solution for saving just one bit per display.
Finally, don't forget to drive the DIMM_OUT line in some way, otherwise no display will lit.
You can do it in several ways:
Hope it helps.
Cheers
If you take a look at the schematic (specs, fig. 4), the circuit is very simple: there are 4 74HC595 chained, plus the led drivers (ULN2003). The same board is also chainable with others boards in cascade.
Well, about the signals, it looks pretty easy:
- connect the Netduino MOSI to the DATA_IN
- connect the SCLK to the CLK_OUT
- connect the DIMM_OUT to any Netduino PWM output
Please, also note that there's no SS involved in the circuit, so you can't share the SPI with other devices. Basically, the display board will always "listen to" any flowing data through the SPI, and there's no (easy) way to avoid it.
After that, the software should also be easy to write.
Just take advantage by the small program I've used in my article about the noise: http://highfieldtale...igital-signals/
It's curiously related to a display, even the digits pattern is *NOT* the same. However, the 74HC595 SPI configuration, and the data transfer should be already okay.
To send a digit pattern to the first display, you should fill a 7-bits buffer (i.e. just one byte) with the desired pattern: a bit set means the segment lit. For four displays, the buffer has to be 28-bits long (i.e. 4 bytes), but *be careful* they must be "packed". I wonder why they chosen an harder solution for saving just one bit per display.
Finally, don't forget to drive the DIMM_OUT line in some way, otherwise no display will lit.
You can do it in several ways:
- pulling the line to the ground (you'll have the max brightness, but no chance to control it);
- driving with any OutputPort (you'll have the max brightness, or all the displays off);
- driving with any Pwm output (you'll able to tune the brightness using the PWM value, inverted)
Hope it helps.
Cheers
Biggest fault of Netduino? It runs by electricity.
#3
Posted 14 June 2012 - 07:06 PM
Thanks for the reply Mario, as soon as I get a chance I'll try it out. Just a quick question: When you say package the byte;
'but *be careful* they must be "packed"' So they are using 7 bits per byte as opposed to 8 bits in a 'standard' byte?
How would you go about 'packaging' this in a way that can be used on the same way as your shift register example?
Many thanks in advance.
Logicalstep
#4
Posted 15 June 2012 - 04:35 AM
By keeping the bytes "aligned", the task *would have been* relatively easy:
The problem is that they (the Sure designers) chosen to save any remaining unused bit for the adjacent digit. There's no less parts, nor less cost: why they decided to get the implementor's life harder?
Anyway, this time the routine gets more complex. I'd write something like this:
<br class="Apple-interchange-newline">
Maybe could be simplified...any clue?
NOTE: both the above snippets are coming out my mind, and I didn't try them. They're just a trace for a concrete implementation.
Cheers
//define the digits pattern static byte[] pattern = new byte[] { ... }; static void Main() { ... init ... Dump(1234); ... } private void Dump(int number) { //create a buffer to hold the four digits pattern byte[] buffer = new byte[4]; //fill the buffer reversely, because it's more comfortable for (int i = 3; i >= 0; i--) { int digit = number % 10; buffer[i] = pattern[digit]; number /= 10; } spi.Write(buffer); }
The problem is that they (the Sure designers) chosen to save any remaining unused bit for the adjacent digit. There's no less parts, nor less cost: why they decided to get the implementor's life harder?
Anyway, this time the routine gets more complex. I'd write something like this:
<br class="Apple-interchange-newline">
private void Dump(int number) { byte[] buffer = new byte[4]; int temp = 0; for (int i = 0; i < 4; i++) { int digit = number % 10; temp = temp * 128 + pattern[digit]; number /= 10; } for (int i = 3; i >= 0; i--) { buffer[i] = (byte)temp; temp >>= 8; } spi.Write(buffer); }
Maybe could be simplified...any clue?
NOTE: both the above snippets are coming out my mind, and I didn't try them. They're just a trace for a concrete implementation.
Cheers
Biggest fault of Netduino? It runs by electricity.
#5
Posted 18 November 2012 - 11:34 PM
Hi Mario,
After a busy few months and after receiving my new Netduino Plus 2, I'm re-visiting trying to get this LED to work.
I managed to get the SPI working, but I'm stuck on the example code you have given below. Any chance you could clarify it a little for me?
Using the code in your link, it's just rolling around lots of random patterns.
The part where you say 'The problem is that they (the Sure designers) chosen to save any remaining unused bit for the adjacent digit. There's no less parts, nor less cost: why they decided to get the implementor's life harder?'
I'm not that experienced with SPI or Serail data (apart from doing some RS232).
Thanks in advance.
Logicalstep
After a busy few months and after receiving my new Netduino Plus 2, I'm re-visiting trying to get this LED to work.
I managed to get the SPI working, but I'm stuck on the example code you have given below. Any chance you could clarify it a little for me?
Using the code in your link, it's just rolling around lots of random patterns.
The part where you say 'The problem is that they (the Sure designers) chosen to save any remaining unused bit for the adjacent digit. There's no less parts, nor less cost: why they decided to get the implementor's life harder?'
I'm not that experienced with SPI or Serail data (apart from doing some RS232).
Thanks in advance.
Logicalstep
By keeping the bytes "aligned", the task *would have been* relatively easy:
//define the digits pattern static byte[] pattern = new byte[] { ... }; static void Main() { ... init ... Dump(1234); ... } private void Dump(int number) { //create a buffer to hold the four digits pattern byte[] buffer = new byte[4]; //fill the buffer reversely, because it's more comfortable for (int i = 3; i >= 0; i--) { int digit = number % 10; buffer[i] = pattern[digit]; number /= 10; } spi.Write(buffer); }
The problem is that they (the Sure designers) chosen to save any remaining unused bit for the adjacent digit. There's no less parts, nor less cost: why they decided to get the implementor's life harder?
Anyway, this time the routine gets more complex. I'd write something like this:
<br class="Apple-interchange-newline">private void Dump(int number) { byte[] buffer = new byte[4]; int temp = 0; for (int i = 0; i < 4; i++) { int digit = number % 10; temp = temp * 128 + pattern[digit]; number /= 10; } for (int i = 3; i >= 0; i--) { buffer[i] = (byte)temp; temp >>= 8; } spi.Write(buffer); }
Maybe could be simplified...any clue?
NOTE: both the above snippets are coming out my mind, and I didn't try them. They're just a trace for a concrete implementation.
Cheers
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users