SPI Bus Sharing Stategies
Re: SPI Bus Sharing Stategies
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!
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!
- 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
That might not be out of the question.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.
You snooze, you lose!
Re: SPI Bus Sharing Stategies
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!
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!
- 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
I was thinking you could condition the ADC ouput and tie it to an interrupt generating pin on the mcu.
You snooze, you lose!
Re: SPI Bus Sharing Stategies
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!
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!
- 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
LOLyesFred 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!
To each his own(own mess). I was merly stating that it was possobile, that was all
You snooze, you lose!
Re: SPI Bus Sharing Stategies
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.
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.
- Spudmn
- LQFP112 - Up with the play
- Posts: 232
- Joined: Thu Feb 10, 2011 12:27 am
- Location: Auckland, NZ
Re: SPI Bus Sharing Stategies
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.
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.
Re: SPI Bus Sharing Stategies
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.Spudmn wrote:I recommend that we stay as it is now. One bus for Knock and one for SD Card.
Sure, good idea.I think that both buses should go to the output header and some chip select IO.
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: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.
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!
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
ROFL!Fred wrote: a shit-house mess like MegaHack with 4 different implementations for the same table lookup