Done some more test on the heater controller today and finally I got it working. My conclusions:
- Yes, the AVR can be a SPI slave running at 4 MHz. Since there is also a few us delay between incoming bytes on the controller that I'll monitor you can also do some processing on the incoming bytes before storing them in an array for printing.
- A logic level converter is necessary - otherwise clock line is lost, I used a 78HC08 running av 5V. I also inverted the CS line from the controller and used that signal as the other AND input. In that way the clock line is low
- The clock is, of course, running also when data is transfered from slave to master. When a slave is eavesdropping only one line (MOSI) on the SPI traffic this results in lots of $FF. A large buffer wouldn't even get me half the way to the data I'm after.
- After analyzing output from the SPI line, dropping the $FF's and being careful on what to print out on serial I found that the data I was after was found on position 549 and onwards. This does not include the $FF's. The controller was reading two blocks and writing one block of data before writing one block to the textfile.
Here is the code for printing out the useful data:
byte rbuf ;
void setup (void)
Serial.begin (115200); // debugging
// have to send on master in, *slave out*
pinMode (MISO, OUTPUT);
pinMode (SS, INPUT);
// turn on SPI in slave mode
SPCR |= _BV(SPE);
} // end of setup
// main loop - wait for flag set in interrupt routine
void loop (void)
Serial.println ("Starting ...");
rpos = 0;
// wait for SS pin to go low
while(digitalRead(SS) == HIGH)
// data is found at position 549 -1060
while (rpos < 1060)
// wait for a byte
while(!(SPSR & (1<<SPIF)))
// read SPDR
byte c = SPDR;
// filter out 0xFF and store pos 549 - 1060
if(c != 0xFF )
rbuf [rpos-549] = c;
// increment counter
Serial.println ("Printing ...");
for (int i = 0; i < 512; i++)
rbuf[i] = 0;
Serial.println ("Done ...");
} // end of loop
Thanks for the help!
1. Find out if an Arduino Ethernet can be a SPI slave or if the ethernet IC messes up the spi lines. Check if another pin can be CS line
2. Find the last line of text from the rbuf, probably will have to check for $FF since this is 0xFFFF is FAT eof marker.
3. Find out how to implement some kind of watchdog working when interrupts are disabled. Could a ++ counter be enough?