I'm trying to use the Maple board for SPI on the CAN shield from sparkfun, and also another device called an IVT board (current/voltage/temperature sensor board).
Anywho, I've rifled through the spi and hardwareSpi libraries and still am not sure if I need to setup the NSS function manually. If so, is it already implemented in the library(s) to do so:
example:
hardwareSpi spi(1);
digitalWrite(spi.NSS,LOW);
spi.write(0);
digitalWrite(spi.NSS, HIGH);
I am hoping this has a simple answer.
robodude666
Member
Yup. Hardware SPI will configure the GPIO as input/output for you, but it does not handle the select pin so that you can configure it to whichever one you wish to use. Checkout the example on the github repo.
Keep in mind that HardwareSPI will automatically always configure the SPI's default NSS/CS as an output - if you plan to use it as an input for something else, make sure to set the pinMode after SPI is configured.
I'm having an issue actually controlling the SS pin (pin 10). It seems that all use of this pin is diabled after using the function spi.begin(). Here is the code:
HardwareSPI spi(1);
int slaveselectpin = 10;
void setup()
{
pinMode(slaveselectpin, OUTPUT);
digitalWrite(slaveselectpin, HIGH);
//delay(3000); I used this function so I could use a multimeter to witness pin 10 actually being set HIGH.
spi.begin(SPI_281_250KHZ, MSBFIRST, 0); // As soon as this function is used, pin 10 goes low and never goes high during the loop sequence
}
void loop()
{
digitalWrite(slaveselectpin, LOW);
//delay(1);
spi.write(255);
digitalWrite(slaveselectpin, HIGH);
delay(1000);//used this delay so I could see if pin 10 was going high at all
}
Any suggestions? It seems I lose control over pin 10...
robodude666
Member
I experienced similar issues before -- no matter what you did, the NSS pin never changed it's state after SPI was enabled. Unfortunately, I do not remember what I did to fix the issue.
I believe in the end, I had the pinMode set AFTER spi.begin was called, and I used GPIO_OUTPUT_PP instead of OUTPUT. Give it a try, maybe?
-robodude666
gbulmer
Moderator
bdwyer - Please try robodude666 suggestion first.
If that doesn't fix it, the RM0008 manual, section 25.3.1 "General description", talks about the NSS pin being controlled by the SPI hardware when the SSOE bit is set.
Would you print out the SSOE bit, which lives in the CR2 register:
USBSerial.println((SPI1_BASE->CR2) & 0b100, HEX);
You are looking to see what value the SSOE bit has. The SSOE bit is bit 2 (counting from bit 0), hence the & 0b100.
My reading is, when the SSOE bit is clear, the SPI hardware doesn't use it, so
SPI1_BASE->CR2 = SPI1_BASE->CR2 & ~0b100;
should clear it.
robodude666
Member
I honestly find this very interesting. The HardwareSPI class actually CONFIGURES the default NSS pin as an output for you, but it goes on with using software control (giving you control over it). It would be nice to see an update to HardwareSPI so you can give it the right to control NSS if your only planning on communicating to one device.
gbulmer
Moderator
robodude666 - Interesting. I guess it reduces the permutations of pins created by initialisation; it is always the same four pins effected.
Try manipulting the SSOE bit. If that does what is needed, then a little warpper function would give that flexibility, and hide the mechanism.
manitou
Member
On an RET6 with IDE 0.0.12, I have been experimenting with setting NSS for external SPI device. Ye ol arduino sketches and even the libmaple/examples/spi_master.c have pinMode(NSS,OUTPUT) and pull it high before invoking spi.begin. But after the spi.begin, the NSS is no longer HIGH, and looking at the the port config registers, spi.begin has set the NSS pin to OUTPUT "alternate function output push-pull". And setting the NSS pin high/low seems to have no effect (scope shows no activity). The only way I got the SPI sketches to work was to move the pinMode AFTER the spi.begin()
Is there some other way one is supposed to control the NSS to activate SPI peripheral???
poslathian
LeafLabs
hmm, seems like gbulmer might have figured this out finally. Spi.begin is obviously stealing NSS from you, and switching the output mode to alternate function output, which means the output is being controlled by a different peripheral from GPIO, in this case the SPI. Why the SPI peripheral is not controlling the pin properly is perhaps what gbulmer suggested, the SSOE bit is malconfigured.
This could be a HardwareSpi bug...
Either way, the workaround for now is to call pinMode on your NSS pin *after* calling spi.begin, and then toggling it manually.
You must log in to post.
