15 replies to this topic

[iukpo]

Hello! I came upon this forum and, specifically, SirPooga's thread here on programming these LED strips with a Netduino. I searched to see if I could find anything more on the Netduino Mini and the strip, but could find no other information, so I created this post.

I am still a novice when it comes to electronics, and while the code part seems well and done in that thread, what I don't understand are the pin connections between the Netduino and the strip. Specifically, I don't know what pins on the Netduino Mini, connect to the SDI and CKI pins on the strip. Am I correct in presuming that for CKI I can use the SPCK pin? Am I also correct in presuming that I would use the SPI MOSI pin, even though I am not going to be receiving or analyzing any information from the strip?

Thanks for your time!

[Stefan W.]

The code example uses GPIOs to bit-bang the data out, so you could use any pin for it. But after having a quick glance at the arduino code (no guarantee though), it looks as the protocol was compatible enough with SPI that you should indeed be able to use SPI to push the data out, using only the clock pin and the MOSI pin and leaving the other pins unconnected, and using the clock idle state as low (=false) and ClockEdge=true (data is valid on rising edge of clock). Downside of that is that there's no slave select, so you can't use SPI for anything else while you use this (unless you add additional circuitry). This would also solve the speed problem that is mentioned in the other thread.

[Nevyn]

I am still a novice when it comes to electronics, and while the code part seems well and done in that thread, what I don't understand are the pin connections between the Netduino and the strip. Specifically, I don't know what pins on the Netduino Mini, connect to the SDI and CKI pins on the strip. Am I correct in presuming that for CKI I can use the SPCK pin? Am I also correct in presuming that I would use the SPI MOSI pin, even though I am not going to be receiving or analyzing any information from the strip?

Welcome to the community,

Looking at the code you should be connecting to D2 and D3 although this code is written for a Plus and not a Mini. I also note from the thread that it looks like a special version of the firmware is required to use this hardware and this may not exist for the Mini.

Regards,
Mark

[Stefan W.]

You could try something like this (copy&pasted from the web&adapted to act like the referenced arduino code, likely contains errors, don't have VS here - also not 100% sure on the clock edge, try out different settings):

// Create a new SPI device
SPI SPI_Out = new SPI(new SPI.Configuration(
    null,                 //no ss - this is from memory, don't know if this is right
    false,                  // SS active-low (irrelevant)
    0,                      // No SS setup time(irrelevant)
    0,                      // No SS hold time(irrelevant)
    false,                  // Clock low on idle (so it will be low for 500µs after transmission, which triggers the output of the leds)
    true,                  // Data valid on rising edge
    1000,                   // 1MHz clock rate
    SPI.SPI_module.SPI1     // SPI device 1
    )
);
 
// Create and fill write buffer
byte[] WriteBuffer = new byte[3];
WriteBuffer[0] = 0xFF; // full red
WriteBuffer[1] = 0x7F; // half green
WriteBuffer[2] = 0x00; // no blue

// Transfer data
SPI_Out.Write(WriteBuffer);

This should let the first RGB led light up in orange (wire SPCK to the clock input and MOSI to data input of the led strip)

[iukpo]

Thank you both for your replies: they've both shed some much needed light on this matter.

I have some more points though:

@Stefan W.: I will take a look at your code snippet, though I am looking to use Sir Poonga's adapted C# as a base. I can't tell though if this is C# or C++...what software package contains the definition for the SPI object?

it looks as the protocol was compatible enough with SPI that you should indeed be able to use SPI to push the data out, using only the clock pin and the MOSI pin and leaving the other pins unconnected, and using the clock idle state as low (=false) and ClockEdge=true (data is valid on rising edge of clock).

That's what I was thinking. I would just use SPCK for clock (CKI), and I would SPI MOSI to send data out (I chose those two because they seem, according to their description, the best pins for the job). Sir Poonga's code seems to use some kind of low level C# library, so I need to see how that all fits in.

@Nevyn:

I also note from the thread that it looks like a special version of the firmware is required to use this hardware and this may not exist for the Mini.

Quite true. Not only may not exist, but if the output pins on the Mini are fast enough, it may not even be relevant. The only thing that worries me is the reported C# overhead.

[Nevyn]

Quite true. Not only may not exist, but if the output pins on the Mini are fast enough, it may not even be relevant. The only thing that worries me is the reported C# overhead.

I think that you will need a version of the firmware which supports the code you were looking at using. The SPI approach may be the best option to investigate.

Regards,
Mark

[Stefan W.]

Thank you both for your replies: they've both shed some much needed light on this matter.

I have some more points though:

@Stefan W.: I will take a look at your code snippet, though I am looking to use Sir Poonga's adapted C# as a base. I can't tell though if this is C# or C++...what software package contains the definition for the SPI object?



That's what I was thinking. I would just use SPCK for clock (CKI), and I would SPI MOSI to send data out (I chose those two because they seem, according to their description, the best pins for the job). Sir Poonga's code seems to use some kind of low level C# library, so I need to see how that all fits in.

Why?

Option a)

• You use his code as a base
• You tamper around with the firmware because of the speed issues
• You have to do the bitbanging yourself

Option

• You use SPI
• Everything for that is already in the netduino firmware
• The bitbanging is done for you, you just specify the bytes

Why are you trying a), which is inferior in (almost) every way? The code i gave you is c# (it can't be c++, it'd be illegal), you don't need a "software package", it's all in the .netmf. If you do the bitbanging yourself, the pins don't matter, all pins are adressable as GPIOs on the netduino. If you use SPI, you have to use the specified pins ...

[iukpo]

Why are you trying a), which is inferior in (almost) every way? The code i gave you is c# (it can't be c++, it'd be illegal), you don't need a "software package", it's all in the .netmf. If you do the bitbanging yourself, the pins don't matter, all pins are adressable as GPIOs on the netduino. If you use SPI, you have to use the specified pins ...

I was going along with his plan because I thought he was writing for a netduino mini: upon closer inspection, that's not what it was-it appears to be some other kind of netduino. I guess what I should do now is get familiar with SPI and the Secret Labs NETMF, which is what seems to be used.

So, as it stands, I will use SPCK and SPI MOSI for clock and output, outputting on each pin where appropriate.

I hope to start playing around with the bitbanging in the next few days: I will base my initial code off of your snippet Stefan-thank you!

If anything else comes up, I will post in this thread or create a new one where appropriate.

[SirPoonga]

I can shed some light on the subject. First, the code should work for any netduino. However, starting on the second page all the code you see if for the Fluent stuff as I found .NET MF is just not fast enough to bit bang this. I am surprised no one suggested using the built in SPI when I was asking that stuff. It could work, just throw in the 500ms delay after each SPI.Write. now I wonder how fast that would be. To test speed since this project is all about appearance I just made some code that cycles the entire strip between red, blue, and green. The arduino with that manual bit bang code was fast enough that the result would be a flickering white. On the netduino I could see each individual color cycle through. Because of that I didn't want to wait for the Fluent stuff to make it into netduino or Corey to get the features I needed into it so I went back to the arduino. I think I am going to use the netduino as a dedicated TCP control server for the arduino. Summer's over, time to get back into this project and hopefully have the LEDs on my motorcycle for next riding season

[Stefan W.]

I am surprised no one suggested using the built in SPI when I was asking that stuff. It could work, just throw in the 500ms delay after each SPI.Write. now I wonder how fast that would be.

Well, it isn't true SPI, but at the line level it should work. Also it's 500µs, not ms (that would be kind of slow) so a sleep for 1ms should suffice (if it is even needed).

[iukpo]

I can shed some light on the subject. First, the code should work for any netduino. However, starting on the second page all the code you see if for the Fluent stuff as I found .NET MF is just not fast enough to bit bang this.

I am surprised no one suggested using the built in SPI when I was asking that stuff. It could work, just throw in the 500ms delay after each SPI.Write. now I wonder how fast that would be.

Sir Poonga! Glad you caught my thread and thank you for your input. I will let you know how the SPI works out for me. What I am doing is not as time dependent: if there's a delay up to three seconds between processing, it does not bother me.

Also it's 500µs, not ms (that would be kind of slow) so a sleep for 1ms should suffice (if it is even needed).

I hope not to have to employ a sleep (outside of timed conditional waits, I feel these should be avoided), but we'll see.


In the meantime, however, I have run into a new issue. I am going to post it in a new thread, as it is wider than this original subject.

[Nevyn]

I hope not to have to employ a sleep (outside of timed conditional waits, I feel these should be avoided), but we'll see.

It looks like you need the clock to be low for 500uS in order for the data to be transferred from the internal registers to the latches (see the greyscale and timing section on page 11). So you will either need to ensure some processing consumes 500uS or use a Thread.Sleep(1) statement to ensure the data is latched.

Regards,
Mark

[SirPoonga]

If you look at my code I have a delaymicroseconds function. It worked. But since you don't need the whole strip to change as fast as possible (solid colors only?) a Thread.Sleep(1) will work. I should have a backup of the code prior to using the Fluent stuff on my home NAS. If I remember I will attach it.

[SirPoonga]

Here's the last bit of code before I started looking at the fluent stuff. It isn't pretty but you should get the idea.

[SirPoonga]

Let's try attaching the file this time.

Attached Files

•  LEDapp.zip   1021.89KB   22 downloads

[iukpo]

Thank you SirPoonga for the code! I will take a look at this when I get the chance and have my FTDI issues sorted.