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

Async SPI on GO!


  • Please log in to reply
6 replies to this topic

#1 ByteMaster

ByteMaster

    Advanced Member

  • Members
  • PipPipPip
  • 76 posts

Posted 03 September 2012 - 02:54 PM

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" B) 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
Kevin D. Wolf
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 September 2012 - 05:46 PM

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

#3 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 03 September 2012 - 05:56 PM

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.

#4 ByteMaster

ByteMaster

    Advanced Member

  • Members
  • PipPipPip
  • 76 posts

Posted 03 September 2012 - 08:03 PM

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
Kevin D. Wolf
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL

#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 September 2012 - 08:22 PM

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

#6 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 03 September 2012 - 08:27 PM

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.

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 September 2012 - 08:39 PM

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




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.