LeafLabs Garden

A place to share, learn, and grow...

1. 

   pico
   Member

   Just to make sure I understand how 1_NSS is supposed to be handled when using spi channel 1....

   I see in the GPIO pin maps for the Maple 5 that for spi channel 1, the assigned pins are:

   D10 - 1_NSS
   D11 - 1_MOSI
   D12 - 1_MISO
   D13 - 1_SCK

   However, I'm also reading in the threads on SPI in this forum that HardwareSPI does _not_ manage 1_NSS at all, the program has to do that manually. Which is fine, but leads me to wonder: What is the significance of assigning D10 as 1_NSS? If it is an output that has to be managed manually, then _any_ available GPIO pin could be used as NSS?

   Or have I missed something?

   Thanks for any advice.

   Posted 3 years ago #
2. 

   robodude666
   Member

   pico,

   libmaple will automatically configure SPI1's NSS as an output, but will not toggle it for you. You must handle that yourself.

   Is there a significance to using it? Not really, depends on how you handle it. If you pick another pin to act as your NSS, keep in mind that D10 will still be an output by default if you use libmaple or wirish's SPI1 setup.

   That said, if you want, you can reconfigure the SPI interface to automatically toggle it for you; libmaple doesn't set it up by default but you can after the fact.

   With that all said... The beautiful of SPI is you can use one SPI interface with multiple SPI devices each using their own NSS pin. You can use the default one for one device, then pick another pin for another device, etc.

   It all really depends on how you want to write your program.

   -robodude666

   Posted 3 years ago #
3. 

   pico
   Member

   Thanks robodude.

   It's good to know about libmaple setting D10 as an output. I didn't think it was actually doing anything!

   I'm interested in configuring the SPI interface to toggle 1_NSS automatically for me. I haven't seen this documented anywhere though -- is this option available through libmaple?

   Posted 3 years ago #
4. 

   mbolivar
   LeafLabs

   The SPI peripherals do support automatic NSS toggling, but you'd have to do that with the lower-level libmaple spi.h interface (or by setting the control registers directly).

   The HardwareSPI begin() method ends up calling spi_master_enable() with SPI_SW_SLAVE (software slave management) among the configuration flags, which means you have to handle NSS toggling yourself.

   This is basically a bug; we were under time pressure to get v0.0.12 out and didn't get hardware slave management working in time. If you fix it, please send any patches our way, so we can fold them into the next release.

   Be sure to check out ST RM0008, the Maple's chip reference manual, for information on the register bits that need setting. I believe having software slave management disabled and the SSOE bit set (in SPI_CR2) might do the trick, but TBH I haven't touched this in a while.

   Posted 3 years ago #
5. 

   feurig
   Member

   I don't think it can be understated that the libmaple people have also made it convenient to map the slave select pin consistently across multiple processors and multiple spi peripherals using the spiX->nss() mechanism. Even if the library doesn't manage this pin having a way to portably reference it as apposed to hard-coding it should not be understated.

   Especially if you then add the ability to (optionally) have the hardware manage it.

   I am not certain that the library should manage the slave select given the inconsistencies in the ways that peripherals expect the slave select to be used. But the way its written is a win/win regardless.

   Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.