Is there anyway to tell the SPI interface to ignore or shift over the bits coming in?
I have a sensor that is a simple two wire SPI style interface. The arduino feeds it a clock signal, and the sensor feeds back data, one bit per clock tick
the problem is, the sensor sends back data in the format
- device is settling in and getting data to send
<a random number of 0xff bytes> - device about to send data
- start the header, always the same
- always the same
start the cycle again...
....
I've been using the SPI fuction, but finding that I have a problem with the data.
Is there anyway to tell the SPI interface to ignore or shift over the bits coming in
In short no.
- device is settling in and getting data to send
Are you sure this is correct? It doesn't seem like the intended behavioured of a device. Make sure you have set the SPI to shift in the data on the edge of the clock that the device is expecting it to use.
What happens if you bit bang until you get your 0xAA and then use the SPI for speed?
Is the thing true SPI? Which SPI mode does it want (clock polarity and clock phase setting combine to give 4 different SPI modes)? What is its max clock rate?
this partiular device is a camera module, that pumps out the pixel data one bit at a time. Orginally designed to work at a 1MHz clock, I've seen some mention that it's been tested up to 1.5MHz. The nice thing is that it handles slower clock cycles as well, down into the 50KHz range.
The problem is that the device sends out a random number of "1"s (but no less than 500+ bytes worth) between each image. then it comes back to the 0xaa header.
The device updates on the rising edge of the clock, so read on the falling edge. I didn't find any info on if the clock should be high or low during idle, and I've been keeping it low and that seems to work.
testing has shown that the average for one picture is approx 178K bits, give or take 1K. of that, the actual data is 172800 bits with the remaing 5 to 6K bits the header/filler. That is a lot of manual bit banging. I'm trying to offload as much as possible to the hardware SPI.
Hoping to make a blob tracker with it. Heh. Might be stressing the little arduino a bit much for that. Normally you would write comething like this in pure "C" and hand optimize the the resulting assembler. If I can get it working at 500KHz, that would be a bit under 3 frames a second. a bit slow but still amazing for this little guy.
So the current plan is that when I'm in the startup phase, bit bang each bit individually until I get to the known header data. once I'm there, figure out where I am (with lots of bitwise math) and once I know that the next bit is the start of a known header byte, fire up the SPI and let it pull the bytes until I reach the end of one picture dataset, a known number of bytes at that point. meanwhile while that's going on process the incoming data and track those blobs.