SPI Bus Sharing Stategies

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

SPI Bus Sharing Stategies

Post by Fred »

I have very little to say here, except that Peter and Dan said they did have things to say, and my little bit of investigation turned up something that we don't have.

1) Don't share, one device per SPI, live happily
2) Share, what about clock speed, what about CS pins, what about bandwidth and blocking other applications? Can you interleave comms with two chips a bit at a time to each or do they have to be done in batches without deselecting using CS?

I don't know the answers to these questions, hopefully someone else does.

At the moment we have Peter Knocking and Spudmn SDcarding and Dan telling us he has ideas and that he'd post this thread up, cough :-)

What else might we like to pin on an SPI, and are there legit reasons for not sharing the bus, or am I being silly?

Discuss! :-)

Fred.
Last edited by Fred on Thu Apr 05, 2012 1:04 pm, edited 1 time in total.
Reason: Fixed! :-)
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!
Peter
LQFP144 - On Top Of The Game
Posts: 268
Joined: Tue Dec 27, 2011 5:37 am

Re: SPI Bus Sharing Stategies

Post by Peter »

I don't have anything to say about SPI right now, but I got out of bed in my drunken/hungover state to quote this, because I feel that Fred doesn't make mistakes very often.
Fred wrote:1) Don't sure, one device per SPI, live happily


Also we probably need to talk about the three paragraphs of legal crap I didn't agree to this morning, because I found them on my phone with one eye open, and a bladder full of cheap wine. I didn't want to read them on my phone, so I didn't agree to them, and now they seem to be gone.
:-p
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: SPI Bus Sharing Stategies

Post by Fred »

LOL, you got me, I fixed it in purple! :-)

What legal crap are you talking about? It's news to me.
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!
Peter
LQFP144 - On Top Of The Game
Posts: 268
Joined: Tue Dec 27, 2011 5:37 am

Re: SPI Bus Sharing Stategies

Post by Peter »

Fred wrote:and are there legit reasons for not sharing the bus, or am I being silly?
From the way I understand it you can hook them up in parallel with the slave select pins hooked up to different ports, and see the same performance as you would if one was on SPI0 and one was on SPI1. If you hook them up in a round robin style I'm sure we would see some performance losses.
Fred wrote:LOL, you got me, I fixed it in purple! :-)
I feel like maybe I've made a mistake, and brought the wrath of Fred down on every one of my sentences. :-)
Fred wrote:What legal crap are you talking about? It's news to me.
Apparently my "smart" phone got me into the Terms of Use page. It's strange, because I could of sworn it gave me a "I Agree" and " "I do not Agree" option. At any rate I thought it was something new when I saw it this morning, because I thought I had hit the Login button.
:-p
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: SPI Bus Sharing Stategies

Post by Fred »

Oh, the forum default terms of use thing? LOL. I thought you only got that when signing up? :-/

I understand the bus sharing the same way. It was the finer points that I wanted to understand with relation to how it will affect the software, or not.

The wrath of Fred is reserved for arseholes, of which you are not one! :-p

Fred.
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!
User avatar
Spudmn
LQFP112 - Up with the play
Posts: 232
Joined: Thu Feb 10, 2011 12:27 am
Location: Auckland, NZ

Re: SPI Bus Sharing Stategies

Post by Spudmn »

My first question would be, What other SPI devices do you want on the bus? At the moment there is a Knock Sensor and the SD card.

+1 for parallel with the slave select pins. Round robin is not the answer and you would still need slave select pins.

I think that it will come down to the available bandwidth of the bus. I am going to need to send at least 2 x 512 bytes (maybe more) for every 512 bytes we want to store on the SD card. I haven't worked out the current rate of data from the serial port is yet, but I guess that we would want to at least match it or better yet exceed it.

Peter, How often do you need to access the knock chip? Is it polled or can you get it to interrupt when there is a knock is detected?

I think that we should keep them (Knock and SD card) on separate buses and make the SPI pins available on a header, along with some extra slave select pins for expansion.
Peter
LQFP144 - On Top Of The Game
Posts: 268
Joined: Tue Dec 27, 2011 5:37 am

Re: SPI Bus Sharing Stategies

Post by Peter »

Spudmn wrote:What other SPI devices do you want on the bus?
LCD displays, GPS, remote start, keyless entry, and well anything else somebody might want to hook up to the board using SPI.
Spudmn wrote:Peter, How often do you need to access the knock chip? Is it polled or can you get it to interrupt when there is a knock is detected?
Not very often. It's a pretty low priority task. If I turned the knock sensor into the master I could just check the register to see if the engine is knocking. With the knock sensor as a slave I'll have to query it for data.
:-p
DaWaN
QFP80 - Contributor
Posts: 62
Joined: Thu Oct 30, 2008 10:35 am
Location: Benschop, Netherlands

Re: SPI Bus Sharing Stategies

Post by DaWaN »

It all depends on real time constraints and bandwidth I think

Electrical you should not be too worried. I had build some boards stacked together with headers and nasty traces and that SPI bus worked up to 15MHz.
So sharing the pins would be OK I guess.
The only proper way of doing that would be through the CS pins
Some devices could continue their operation while having the bus access interrupted by some other device, but that greatly depends on the used device, I do not know if SD cards support that feature

Also remember that accessing a SD card with a file system generates quite some overhead, keep that in mind
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: SPI Bus Sharing Stategies

Post by Fred »

Well, for the knock thing, we're talking about sampling it once per ignition or fuel event. IE, the input interrupt samples the pins requiring timed sampling and flags new data, the main loop comes around, sees that and runs calcs, part of that would be pulling the knock value out of the external device as often as the calcs are done. I doubt that it would be appropriate to pull the value during the input ISR, but it might be, if the bus rate was high enough. In that case it would be asynchronous which I would expect would rule out shared mode.

The SD thing has a different requirement, and that is to write a significant block of data down each time we have a set of data sampled, calculated and ready to log. That will likely happen synchronously with the serial logging. IE, use the same block of source data triggered from the main loop and only cleared when all users are done with it. If the SD/FS stuff can be done in small blocks with fast interrupts, then it's going to hog the bus for chunks, possibly longer than the period between calculations. If serial logging is off and SD has a free reign on writing, it could write it out even more often, even saturate the SPI with data, if it wanted to.

I guess on the basis of that info, they have to be on separate buses to get good performance from each.

The knock one can likely be done without interrupts, though triggering it to be read in an interrupt from inside the input interrupt could be a nice way to get a synchronous knock value in real time. Knock is most useful at low RPM anyway, so working synchronously up to moderate RPMs is likely a good thing.

My 2c. As you were :-)

Fred.
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!
Peter
LQFP144 - On Top Of The Game
Posts: 268
Joined: Tue Dec 27, 2011 5:37 am

Re: SPI Bus Sharing Stategies

Post by Peter »

DaWaN wrote:Some devices could continue their operation while having the bus access interrupted by some other device
The knock sensor has an Int/Hold pin. In the Int(integration) mode it looks at the knock sensor, and in Hold mode it ignores the sensor to communicate with the MCU. Or at least that's the way I understand it right now, but I could be wrong.
Fred wrote:we're talking about sampling it once per ignition or fuel event.
I was thinking whenever it's convenient, but if you did it that way you could tell which cylinder is knocking. I've read about how they look at micro-decelerations in the crank to see premature predetonation. I imagine you could do it all from the crank and cam position sensor readings if that's true. Depending on if the trigger wheel is fine enough.
Fred wrote:In that case it would be asynchronous which I would expect would rule out shared mode.
You might be right, but I was thinking it would only be asynchronous while the CS is active, and then the chips' communication module would be in wait mode until it's selected again.
DaWaN wrote:Electrical you should not be too worried. I had build some boards stacked together with headers and nasty traces and that SPI bus worked up to 15MHz.
I thought I was having problems at 6.25Mhz, but I just took another gander at the datasheet, and I realized that their table is based on a 25Mhz bus clock. So I'll have to re-figure out where the speed of the clock causes me problems. I assume our bus clock is at 40MHz? What was the value you had in the SPIBR(SPI Baud Rate Register)?
:-p
Post Reply