2 replies to this topic

[FelixEmman]

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.

[Chris Walker]

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

[Corey Kosak]

maybe because I'm not annoyed by lambdas

At last! You are my hero