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 »

It's not a matter of "if" it's a matter of "how much" ie, it's linear, you have to configure it and then read the value and use your own guidelines to decide if that level is knock or not, and how bad of a knock it is/was.
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
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: SPI Bus Sharing Stategies

Post by SleepyKeys »

Spudmn wrote: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.
That might not be out of the question.
You snooze, you lose!
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 »

You wanna tell us something that the datasheet doesn't know? :-p LOL, come on, spill the beans!
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
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: SPI Bus Sharing Stategies

Post by SleepyKeys »

I was thinking you could condition the ADC ouput and tie it to an interrupt generating pin on the mcu.
You snooze, you lose!
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, so create some complex circuitry that requires hand tuning to use an Integrated Circuit in a way it wasn't intended to be used? I see! :-)
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
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: SPI Bus Sharing Stategies

Post by SleepyKeys »

Fred wrote:Ahh, so create some complex circuitry that requires hand tuning to use an Integrated Circuit in a way it wasn't intended to be used? I see! :-)
LOLyes
To each his own(own mess). I was merly stating that it was possobile, that was all :-)
You snooze, you lose!
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 »

In my opinion, we have many busses to utilise so I think that each device should be on its own bus and not share any of them.

If an IC on a bus ever dies for whatever reason we dont want it potentially dragging down the bus and rendering other devices sharing the bus inoperable either.
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 recommend that we stay as it is now. One bus for Knock and one for SD Card.

I think that both buses should go to the output header and some chip select IO. That way people that want to add some SPI device later, can make a daughter board and sort out the bus sharing in software. They may not want to use Knock and therefore they can use that bus. Or they may want to share with the SD Card.

I will write the SPI code to allow a number of different SPI devices. As long as they use the SPI the same way as the SD Card does. I don't really want to be changing Bus settings each time I want to talk to the SD Card.

Another option for expansion is the CAN bus. I intend to build a CAN daughter board and all sorts of CAN enabled devices.
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 »

Spudmn wrote:I recommend that we stay as it is now. One bus for Knock and one for SD Card.
No one was trying to suggest we change the current hookups. It was more about whether it was possible to move things around to suit future use cases. Looks like it's probably not going to be, though.
I think that both buses should go to the output header and some chip select IO.
Sure, good idea.
I will write the SPI code to allow a number of different SPI devices. As long as they use the SPI the same way as the SD Card does. I don't really want to be changing Bus settings each time I want to talk to the SD Card.
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.

In any case, the SPI code (or I2C or CAN etc), if possible, shouldn't be use specific. Maybe it's not possible or practical, but we should aim for it. We wouldn't want a shit-house mess like MegaHack with 4 different implementations for the same table lookup and so on :-/

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: a shit-house mess like MegaHack with 4 different implementations for the same table lookup
ROFL! :-)
Post Reply