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:

Re: SPI Bus Sharing Stategies

Post by Fred »

Peter wrote:
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.
I mean, the SD stuff will likely be busy for long periods, and in any case, could be busy at any time, so if you want to take a "NOW" reading, you need it to be 100% free. I guess you could share interrupts, but there is no good way that you could trigger it if you don't know it's free.
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)?
Correct. EDIT: I have that in the SCIBD register, I guess that's your typo this time? :-) What goes around comes around, right? LOL.
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:Correct. EDIT: I have that in the SCIBD register, I guess that's your typo this time? :-) What goes around comes around, right? LOL.
:-) lol SPIBR is the band speed register for the SPI module. SCIBD is for the SCI stuff. According to this block diagram: http://www.technologicalarts.com/myfile ... 2block.jpg I think I've been working on the correct interface if Ravage is hooked to the right pins. Speaking of the SCI I do get some strange activity out of PS1 on the LA for some reason. Plus I make mistakes all the time, so it's no where near as exciting as when you make a mistake. :-p
:-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 »

"What was the value you had in the SPIBR(SPI Baud Rate Register)?"

I've never had any values in such a register, hence typo question ;-)

LOL @ "Plus I make mistakes all the time, so it's no where near as exciting as when you make a mistake. :-p" wife agreed LOL... :-/

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 »

I see where the miscommunication happened. I was asking DaWan what he had in the SPIBR, because he said that it worked up to 15MHz.

LOL at your wife's reaction.

I'm still looking forward to the pictures of whatever you did to the toaster oven.
:-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 »

Ahh I see! :-)

Pics eventually, maybe soon while avoiding typing.
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!
DaWaN
QFP80 - Contributor
Posts: 62
Joined: Thu Oct 30, 2008 10:35 am
Location: Benschop, Netherlands

Re: SPI Bus Sharing Stategies

Post by DaWaN »

Peter wrote: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.
You are wrong, the knock sensor ignores the SPI transfers during integration.

The knock sensor is a nothing more than a sensor amplifier with a digital block with a bandpass filter and an integrator.
The INT/hold pin is used to define a window for the integration, you only want to integrate during the potential knock window.

The knock sensor can be read in 2 ways: through SPI and through the analog output.
Realtime SPI access is not really needed for the knock IC; you can use the INT/Hold pin combined with the analog output.
If you go the INT/hold + DAC pin way, you only need SPI to configure the IC once. You could only use one channel of the knock IC this way, as channel switching is done through SPI.
If you do not use the DAC pin but SPI, you need realtime SPI access to read the integration value
You would always need the INT/HOLD pin as that feature cannot be controlled through the SPI connection
Fred wrote:In that case it would be asynchronous which I would expect would rule out shared mode.
It does not rule out shared mode; some devices could be paused so in asynchronous mode it would only generate a delay of one SPI transfer (one byte)
It all depends on the used devices on the bus, some devices could not be paused and require complete SPI transfer (like address + data etc.)

If the knock sensor is used in INT/hold + DAC mode with only one channel, SPI sharing would be fine as you only need to configure the knock IC once
I do not know how smart it is to do SPI transfers in interrupts, as it would create quite long interrupts. Waiting for one SPI transfer and reading the integration value would require a 4 byte SPI (one wait byte + 3 bytes transfer for the sensor) transfer. At 15MHz bus speed the most optimistic time would be 2.13 microseconds
Peter wrote: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)?
The 15MHz SPI stuff was not with the FreeEMS Freescale micro but with a NXP LPC2148, electrical those I/O pins should roughly be the same. The register setup is a different story so you will have to work the speed out yourself with the Freescale documents
Peter wrote: 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.
Yes Honda does it with an extra crank sensor, so that might require an extra sensor. Interesting stuff but out of scope of this topic I guess :)
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 »

Thanks for pointing out that it wasn't the same type of reg setup, I meant to, and forgot.

2.13us is not too bad, I'd take that on the chin provided it was 100% deterministic.

Re ruling out async, it does IMO:

1) if the bus is deemed GP and ICs exist that can't be paused, then you can't guarantee that you'll have access when you need it.
2) Even if you can pause the other, that's extra overhead that we don't want in a critical section.

Knock sensors are useless enough at the best of times. Doing knock sensing without some type of windowing is borderline useless. IE, windowing = all setups. Thus we have to read it from an interrupt to guarantee that the interrupt driven window is not enabled. I didn't realise that you can't read it while it's recording, so to speak. That's a bit average.

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
Dan
LQFP144 - On Top Of The Game
Posts: 1204
Joined: Tue Mar 02, 2010 2:33 pm
Location: Australia

Re: SPI Bus Sharing Stategies

Post by Dan »

Fred wrote:and Dan telling us he has ideas and that he'd post this thread up, cough :-)
My bad, I forgot about it and havent had much spare time lately.
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 »

Just teasing! :-)
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 »

I was hoping that the Knock chip was a bit smarter. Set it up and have it interrupt when a knock is detected. I guess they don't work that way.
Post Reply