Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

another SPI speed rant

  • Please log in to reply
2 replies to this topic

#1 FelixEmman



  • Members
  • PipPip
  • 25 posts

Posted 04 February 2011 - 10:15 PM

While I still eagerly wait for my netplus to arrive... I was speding a lot of time in the forums trying to figure out what the capabilities of the SPI port are, speedwise. And I get mixed impressions, there's a lot of discussion about bit banging, using native code to speed up things and Corey's Fluent Interop which I acually really like (haven't tried it cause .. doh .. I don't have the board yet but to me it looks like a very elegant solution to the problem, maybe because I'm not annoyed by lambdas). But rather than explaining what I think is possible let me explain what I need to do with SPI and then maybe someone can confirm or point me in the right direction. BTW.. I come from coding in Arduino for hardware where certain things are easy, but not having the real IDE power of VStudio makes other things painstakingly slow to debug. Hence my decision to try Netduino.

I will need to use my NetduinoPlus to control 8 LCDs over SPI. They can go up to 10MHz but have some specific timings, for instance a 15us interbyte delay.

These LCDs work with arrays of bytes as commands (a few command bytes in the header and then the data). For instance, a clear screen would be a very short command, just a command, no payload. But a display text command would be a few command bytes, a 2 byte length, and then the actual text which could be several bytes. Or even more complicated, I can send display image commands which have the command header, but the payload can get real big real quick depending on the resolution and color depth of the image displayed (several thousand KBs for a full screen). So for displaying an image I would have to be able to read that from say the ethernet, and flush it down the SPI to be displayed on one of the N LCDs, of course... as fast as possible.
I saw a post where a guy was having trouble with his SPI DAC not being nearly as fast as he needed it, but in other places I saw ChrisW saying that not even native code can beat the .netmf SPI implementation (which i assume is whatever is available in the firmware?).

Let me summarize what I need to do:
  • Talk to these LCDs individually, FAST
  • Control 8 LCDs with 3 wires (was thinking of using a 74hc138 3-to-8 decoder), and possibly 16 of these LCDs in the future. Not sure if this is doable given the signature of that SPIConfiguration class that I've seen around in other posts, but I need to be able to control as many SPI LCDs as I want (16 would seem tops for my needs right now).
  • Set my SPI speed as close as possible to 10MHz to gain as much throughput as possible while staying within spec. Is this doable, or is it always going to be a divider of 48mhz?
  • Make sure I respect their spec timings, specifically: when i send several bytes for a command, i need to leave a 16us delay between bytes.
  • I constantly have to check the MISO byte as I send the MOSI byte for status bits (BUSY, ACK, DATAOK, etc) in case I need to resend a byte, so I don't think an alternative bitbanged SPI version would work for me in case the netduino SPI isn't fast enough.
So hopefully this gives a good feel of my application needs and any comments/clarification/suggestion/insight are welcome.

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 04 February 2011 - 11:35 PM

Hi Felix, If you're sending large streams of data via SPI, you'll get really good performance in managed code (C#). If you need to send/receive a byte at a time, then you're limied to the KHz range rather than MHz due to the overhead of interpreting each of your code statements. All of that can be solved with native code (including possibly Corey's interop) if necessary. I'll be waiting closely as your project develops. We'll be here to pitch in with advice as well. And I'm looking forward to your input as we create native code interop hooks in the core firmware. Chris

#3 Corey Kosak

Corey Kosak

    Advanced Member

  • Members
  • PipPipPip
  • 276 posts
  • LocationHoboken, NJ

Posted 05 February 2011 - 12:18 AM

maybe because I'm not annoyed by lambdas

At last! You are my hero :lol:

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.