Yes that was my intention. Also maybe a blocking call for short messages and a non blocking call for my 512 bytes that you need to poll for completion.Fred wrote: Hmmmm, I spent some time with Peter working towards an SPI library setup, he said he sent you it. What I'd like to see is an SPI libary that is generic and that the SD/FAT stuff can use, same for any other code setup. Maybe the lib will be pretty thin, or maybe it'll have three or four arguments and handle interoperation:
libcall(settingsPointer, statusPointer, returnBufferPointer, bufferSize)
With a return type of unsigned char or short that could carry the error code, zero being all OK. Or whatever else that makes the specific code a simple client of a lib with minimum knowledge of low spi stuff.
SPI Bus Sharing Stategies
- Spudmn
- LQFP112 - Up with the play
- Posts: 232
- Joined: Thu Feb 10, 2011 12:27 am
- Location: Auckland, NZ
Re: SPI Bus Sharing Stategies
Re: SPI Bus Sharing Stategies
Great! :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: SPI Bus Sharing Stategies
About which devices to use SPI... basically, you want to keep SPI devices within the ECU enclosure. For remote equipment you'd want to use RS-485 or CAN.
I had the idea about SPI addressing using a demux and buffer chips. What it'd do is you'd enter the bus address with an SPI message to the handler, which then sets the address pin low. It would save a bunch of pins on the MCU. It would also offer flexibility with additional hardware. SPI is a really really fast bus (for our purposes) so the extra latency isn't an issue.
I had the idea about SPI addressing using a demux and buffer chips. What it'd do is you'd enter the bus address with an SPI message to the handler, which then sets the address pin low. It would save a bunch of pins on the MCU. It would also offer flexibility with additional hardware. SPI is a really really fast bus (for our purposes) so the extra latency isn't an issue.