SPI with MountaineerEth board and RGB 595 board

Archive
#1

I am new to the .NETMF and Gadgeteer. I am trying to run some LEDs using the following parts:

MountaineerEth Board - http://www.mountaineer-boards.com/home/ethernet-mainboard/#cc-m-product-5788636181

RGB DMX 512 / SPI (TTL) Decoder - http://usledsupply.com/shop/rgb-32-spi-dmx-decoder.html

I have some code written but nothing is working so far. I would love some help verifying that my wiring is correct and that my code is right also. My wiring is as follows.

MOSI -> 1D
MISO -> Not connected
SCK -> 1C
GND -> 1G

I have only one light strip connected right now. I am not using the a CS signal from the Mountaineer board. I am not sure what to do with the 1L on the decoder (595). I can’t seem to find any documentation on this decoder. I am glad to post my code but my gut tells me that the code is not my main problem. I do, however, get some unexpected results when I use a loop back cable too. I think the 1L pin needs to be used but I am not sure how.

I also don’t understand how the data needs to be formated when using the Microsoft.SPOT.Hardware.SPI libraries. I have looked at some quick start guides and sample code and so far I am still lost. Can anyone help?

Thanks!

#2

Hi Darbyln, welcome to the forum!

The CS line is “Chip Select”, which in SPI terms tells a device on the bus that it is required to listen to the bus and is permitted to output to the bus, so I would expect that you need to connect that.

Looking around on the device’s webpage I can’t really find a good description of the connector, can you point out a better connection diagram or take some shots of it? Did you get any documentation ? Can you also confirm what the “595” you mention is? Do you mean it has a 74HC595 chip on the board? If so, then the 1L is “Latch”, and that actually will need to be connected to the SPI Clock pin (the 74HC595 uses this to sample the bit that is present on the data line, and move it into the register). Try moving your connection from 1C over to CS, and 1L to SCK.

#3

Sorry for the lack of detail. Yes the 595 reference is a shift register. This board has 12 TPIC6B595N chips and two 74HC245N chips (for the SPI interface). I have zero documentation on the LED driver board. I was told by the vendor that you just treat it like a 595 shift register.

I think I might have figured out the basics. I had a difficult time figuring out how to define the CS in C#. I was trying to use pin 6 of socket 2 (the SUX socket). I ended up with the following line and I connected the CS pin to the 1L pin and it started working:

ConfigStrip1 = new SPI.Configuration((Cpu.Pin)25, false, 0, 0, false, true, 1000, SPI.SPI_module.SPI1);

Now I have the RGB working for all 32 channels on this board. My next step is to use PWM to get more colors. I am not sure the best way to do this. I see references to PWM over SPI but it is not yet clear to me how this is done. Any tips would be nice. Thanks!

#4

Great to hear you have it working.

There’s nicer ways than using (cpu.pin)25, but in general that’s what you end up with - the device’s cpu.pin enumerations usually make this a lot easier to make sure you know what pin is what from code when trying to match it to the hardware. And Gadgeteer introduces another layer - where you reserve sockets and pins rather than worrying about the pin number underneath that.

As to your PWM point… sorry, not going to work in an SPI connected device scenario. The point of PWM is that instead of turning the signal to a “device” (LED) on or off, it turns it on or off fast enough that it appears to the human eye to be scaled down from full on. So for example a red LED turned on at 50% PWM duty cycle appears 50% dimmer than if it was just turned on. To use PWM, the actual LED would need to be controlled by the PWM pin, so unless the module itself can do this you’re out of luck.

#5

Weird. I guess I have misunderstood a bunch of examples that I have stumbled across. Here is an example of using PWM over SPI on Arduino. Maybe I misunderstood what he was doing here but It looks like he is doing what I want to do.

http://forum.arduino.cc/index.php?topic=38155.0

Is he doing something different?

#6

he is doing SOFTWARE PWM, not hardware PWM. Don’t expect that level of control in a netmf world, you can’t control the latency of the pin actions as you can in “bare metal” arduino world.

edit: so you could potentially still do this, by just sending values to the shift register “fast” that give you an artificial duty time, but whether you have the speed and control to be able to do that isn’t clear. You can try of course, since it’s not likely to cause any problem, it just might not work…

#7

Thanks. I wonder if someone out there has ever tried this? Anyone?

I will play with this but I am not an expert so any tips would be nice. I will report back with my results.

Thanks for your comments Brett!

#8

In all applications like this, the two common reasons for choosing netmf typically is “speed to get working” (because of higher level language) and functionality requirements (more complex capability in simpler code). This type of reliable timing requirement is not well serviced by netmf, but having said that you can be sure you can achieve something close, depending on how complex you want the changes in PWM rate to be (ie if a small fade from red to green is all that’s needed, that’s easier than 256^3 colour fading) as well as how much the rest of your code needs to achieve (ie you’re going to be doing lots of continuous cycles in software PWM, so you may not have many cycles to complete other tasks)

Having said that, give it a try ! pump out data to the shifty and see how quickly you can get it to change.