Async SPI on GO!

I have a timing critical application built on the GO! platform. One of the bottle necks I'm running into is communicating with my modules via SPI. I'm using the "old-fashioned" STM8S where an interrupt handler processes the slave's incoming SPI, not one of those "new-fangled" STM32F0 chips with DMA and megabit SPI. Anyway, I might have some possibilities to tune the interrupt handler but it seems like if I run SPI faster than 166KHz, I'm getting corrupted messages. One of my modules sends about 120 characters to be relayed via WiFi, this is taking 3.5ms. Since I'm assuming that the processor really isn't needed full time to send out these characters, I'm wondering if there is any sort of async way to queue up and send a byte buffer to a module. In this case, it could be fire-and-forget, however it also might be nice to get a call back for some other things I'm doing with the response buffer. This would also get interesting since from what I understand there are to SPI channels, each serving 4 GO! bus modules. I love the module approach with the GO! platform, but for communicating in a real-time basis with the modules is starting to seem like it's becoming neck. Thoughts? -twb

Hi Kevin, Just to confirm...you're trying to reduce the amount of time that SPI blocks the rest of your NETMF code while transmitting data to your module, correct? We have some enhancements along this line with the new GoBus 1.5 spec, and more coming next spring with GoBus 2.0. You have PM Chris

Kevin, For what it's worth, I was able to get ~2.5 MHz SPI transmissions on the STM8S but avoided interrupts to do so. The method I used was to put the STM8S into a 'wait for interrupts' mode, waiting for SPI NSS to be asserted, and then retrieved / sent the bytes in a loop using the SPI registers. While the GoBus 1.5 spec will go a long way in simulating asynchronous SPI, it is not designed for 'real-time' communication scenarios. -Fabien.

Hi Fabien -

The method I used was to put the STM8S into a 'wait for interrupts' mode, waiting for SPI NSS to be asserted, and then retrieved / sent the bytes in a loop using the SPI registers.

Hmmm...sounds interesting, perhaps we can chat about it sometime . It sounds like when the SPI commo is happening, not much else can happen as well?

Guess I'm not so much looking for "real-time" as "real-fast" or even "non-blocking". Just seems sort of a bummer putting the fast processor on hold while the SPI peripheral is doing it's thing.

Very anxious to see the 1.5 stuff...hope it isn't too difficult to retro-fit, I can see the finish line of stable flight with my quad and wanna stay focused!

-twb

Hi ByteMaster,

Very anxious to see the 1.5 stuff...hope it isn't too difficult to retro-fit, I can see the finish line of stable flight with my quad and wanna stay focused!

With GoBus 1.5, we've moved all the communication over to standard profiles. You can still use SPI as before but it will be a "virtual SPI bus" that's wrapped up in frames. Or you can move to "Stream" if what you really want is async messages.

One of the things that this allows us to do is send all the frames in the background. So you can simply write data and move on with your code. Over time we'll be moving it all to DMA (both the underlying SPI transport and the hardware CRC) so performance is really going to scream

Chris

Hi Chris,

Over time we'll be moving it all to DMA (both the underlying SPI transport and the hardware CRC) so performance is really going to scream

For those of us already using DMA with SPI, I am very concerned about the transition path. One thing that I would like to see preserved is 100% backward compatibility with today's synchronous SPI, available side-by-side with GoBus 1.5 asynchronous methods.


-Fabien.

Hi Chris,

For those of us already using DMA with SPI, I am very concerned about the transition path. One thing that I would like to see preserved is 100% backward compatibility with today's synchronous SPI, available side-by-side with GoBus 1.5 asynchronous methods.


-Fabien.

There are no plans today to discontinue support for synchronous SPI and custom SPI messaging. GoBus 1.0 devices will continue to live alongside GoBus 1.5 devices when plugged into Netduino Go.

That said, the new methods will provide for much better overall performance. It's a bit like moving from cooperative multitasking to preemptive multitasking...

We're also adding some features to GoBus which will result in more sales for GoBus 1.5+ modules. We'll be happy to work with you to evaluate GoBus 1.5 for your existing modules. I'd be really surprised if the benefits didn't far outweigh any possible downsides.

Chris