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