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 Pin confusion


  • Please log in to reply
12 replies to this topic

#1 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 14 October 2011 - 11:18 PM

After a bit of wrangling, I finally have my Netduino set up and I am able to write programs and deploy to them. I am writing a program that outputs data via SPI MOSI, and whenever I try to debug the program, it crashes at initialization of my SPI object. Here is the code below:

 // Create a new SPI device
            _data = new SPI(new SPI.Configuration(
                Pins.GPIO_PIN_14,                 
                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
                2000,                   // 2MHz clock rate (allows for 500µs between writes)
                SPI.SPI_module.SPI1     // SPI device 1
                )
            );

I presumed that GPIO_PIN_14 was for SPIO_MOSI, as it is listed as pin 14 on the Netduino Mini schematic. I think the program is crashing because this pin is not available for data writing, and that it is not SPIO_MOSI. Seeing as how the PIN enumerations go from 5 to 20, I am even more confused. What GPIO_PIN corresponds to SPIO_MOSI? How does one know what line up with what? Can SPIO_SPCK be deduced in the same fashion? Thanks!

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 15 October 2011 - 12:28 AM

Hi iukpo, With the SPI protocol, a single pin can be used to "select" the device you're communicating with. That pin is called the "chip select" (cs) or "slave select" (ss). The MOSI pin is the pin that is used to communicate from master (Master Output) to slave (Slave Input). MISO is used to communicate from slave to master. The first parameters is for the optional "chip select" line. If you try to use the MOSI pin as a chip select, it won't work...since the mosi pin is required for data transmission. Can you try using pin 13 or setting the parameter to GPIO_PIN_NONE instead? Chris

#3 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 02:25 AM

I switched the pin to Pins.GPIO_NONE, and the program didn't crash! However, nothing happened either...:P It looks like I have some debugging to do. In the meantime, thank you Chris! :)

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 15 October 2011 - 02:35 AM

Hi iukpo, Does the component you're interfacing with need a chip select line? [For that, try using any other pin than 13-16 when you're just starting out.] Chris

#5 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 02:45 AM

Well, actually, let me describe it this way...I am beginning to suspect no data is being read by the interfacing device, one of these...

1) The device has a CLK and Data input lines, which I have connected to SPIO_SPCK and SPIO_MOSI (Pins 16 and 14 respectively) on the Netduino.
2) There is no selection being made on the device as far as I know, and I presumed that the device would be "listening" on those pins. It does not need a chip select line I believe...I think simple output pins could work (heck, that's what most people seem to be using).

If what I believe is true (device does not need nor use a chip select line), I think I will fall back to OutputPins. However, if this is the case, should I switch over to something else, like AD0-AD3 or PWM0-PWM3?

#6 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 15 October 2011 - 04:24 AM

Iukpo, you are right. The chips chain automatically detects the beginning of the frame by "seeing" a 500us blank. So, no SS is involved. However, that's uncommon in the SPI world, which consider a SS for the slave device. You may set to any free output (that you must avoid to use for other purposes). Anyway, I'd worried for another aspect. The strip chips are probably powered at 5V, and the minimum high-level voltage seems at 0.8*Vdd=4V, which is higher than the capability of the Netduino. Could you check this point?
Biggest fault of Netduino? It runs by electricity.

#7 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 04:59 AM

Mario, thank you for the reply. :)

I am actually powering the strip chips separately with an adapter, and yes, they are powered at 5V. The only interface between the strip and the Netduino is the CLK and Data cables.

However, I am a little confused though. You say

You may set to any free output (that you must avoid to use for other purposes).


Should I avoid using SPIO_MOSI and SPIO_SPCK? If I set to something else (AD0-AD3, PWM0-PWM3), do I have to specify the GPIO Pin, like how I was doing earlier, and will the pin numbers be correct (Ex.: Pins.GPIO_PIN_6=6th pin=AD1)?

#8 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 15 October 2011 - 05:13 AM

You can't avoid using the clock the the data (i.e. SPIO_SPCK and SIPO_MOSI, respectively). Probably you must set the SS (=slave select) pin on any of the free outputs (e.g. AD1). That's for the SPI configuration itself, nothing else. However, once you fixed such that pin (e.g. AD1), hardly you may reuse for other purposes. So, you should consider to "waste" an output (being so precious, especially for the Mini). Cheers PS: the SS pin (e.g. AD1) will be left open, though.

Edited by Mario Vernari, 15 October 2011 - 05:14 AM.

Biggest fault of Netduino? It runs by electricity.

#9 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 05:38 AM

Ok, so those are presumed to be correct...ok. However, I am a little confused as to why I would set the slave select pin. Does this merely "remap" the slave select pin to AD1, while the outputs continue through SPCK and MOSI? If so, why?

#10 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 15 October 2011 - 06:32 AM

Yes, you must assign a SS line to the SPI controller: that's the SPI standard working in that way. Now, I'm still unsure whether it should be the possibility to define SS=none. Well, it should be available in the cases where is much useful to manage the SS "manually" by code, though... Bah.
Biggest fault of Netduino? It runs by electricity.

#11 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 07:09 AM

Yes, you must assign a SS line to the SPI controller: that's the SPI standard working in that way.
Now, I'm still unsure whether it should be the possibility to define SS=none. Well, it should be available in the cases where is much useful to manage the SS "manually" by code, though...
Bah.


Ok, now here's another wrinkle to this. According to the completed source of a project for NetduinoPlus (the original link is here...I've attached the source for your immediate perusal), it seems that UART TX, RX pins are used to drive the clock and data pins, not SPIO_MOSI and SPIO_SPCK. This leads me to believe that it does not matter what pins are used, as long as they are properly set and used. This leads me to more questions:

1) I would like to use SPI to write the data, instead of using OutputPort to bit banging it out (as the attached code does). Can I use the SPI object with ports AD0-AD3?
2) One of the pins will be attached to an SPI object (for data), and the other for an OutputPort (for bringing the clock low and high).

I'll check back tomorrow on this thread. I think this is enough for one night!

#12 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 15 October 2011 - 08:18 AM

Hmmm...Why do you have to bitbang the SPI?
The SPI consists in three signals, plus one or more slave-select (SS) outputs.
Since the SPI is hardware managed by the Netduino microcontroller, their basic pins are fixed. You can't swap them in any way.
What you may choose is the SS, which could be almost any other available output. However, you won't use this signal for the led strip purpose.

So, to answer to your first question, YES you should use the SPI object and NO you can't use the ADx as SPI signals.
The second question for me has no sense to be applied.

Please, check the Mini schematic in the "download" section. There is the upper-view pinout of the socket.
For your purpose, the only useful signals are on pins 14 and 16.
As stated, the SS could be configured on any spare pin. Since the primary SS is designed as to be the pin#13, why not use it?
Biggest fault of Netduino? It runs by electricity.

#13 iukpo

iukpo

    Advanced Member

  • Members
  • PipPipPip
  • 85 posts

Posted 15 October 2011 - 07:13 PM

I took a look at the schematic and read your reply and I think I understand now the part about the SS. I've set it now to Pin 13. And I figured out the problem.... I was connecting data read to the wrong end of the LED strip! Now it is connected properly, things seem to be working: data is getting out. Thank you all (esp. you Mario!) for your help. :)




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.