DIYEFI.org Forum

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.

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

"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.

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.

Ahh I see! :-)

Pics eventually, maybe soon while avoiding typing.

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

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.

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.

Just teasing! :-)

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.