Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

SPI LED


  • Please log in to reply
4 replies to this topic

#1 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

Posted 12 June 2012 - 10:37 PM

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

#2 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

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:
  • connect the Netduino MOSI to the DATA_IN
  • connect the SCLK to the CLK_OUT
  • connect the DIMM_OUT to any Netduino PWM output
and, of course, be sure to share the ground. Also power the display board with a *separate* supply, instead of taking advantage of the Netduino +5V output. The current required by the displays can be pretty relevant, and the Netduno regulator may get hot. So, please, use a separate +5V power supply for the display.

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 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

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 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 15 June 2012 - 04:35 AM

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
Biggest fault of Netduino? It runs by electricity.

#5 logicalstep

logicalstep

    Member

  • Members
  • PipPip
  • 21 posts

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



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

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.