SPI.begin();SPI.setBitOrder(MSBFIRST); // sets SPI data transfer to MSB firstSPI.setDataMode(SPI_MODE0); // sets SPI mode to MODE0SPI.setClockDivider(SPI_CLOCK_DIV8); // sets shared clock rate to 16Mhz / 8 = 2Mhz
// select chipdigitalWrite(chip_select, LOW);// send generic 01 address prefix// send 78H hexadecimal addressSPI.transfer(0x78H);// send parity?SPI.transfer();// send don't care, if needed?// send 8 dummy bits of data
Where is the link to the datasheet?
Did 0x78H actually get past the compiler? It shouldn't My gcc (solaris and linux) dies with "error: invalid suffix "H" on integer constant" when I tried 0x78H.
SPI.transfer returns a byte result, capture those...
a = SPI.transfer (4);// a is now 1b = SPI.transfer (3);// b is now 2
byte ident_reg_contents = B00000000;byte diag_reg_contents = B00000000;SPI.transfer(B01111000);diag_reg_contents = SPI.transfer(B00000000);
If it doesn't, give up
SPI.transfer (4) would send the value of 4, of course - and writing an a = SPI.transfer(4) would capture the data returned as a result of sending a value of 4 out over SPI?
... because the appropriate data is sent back is sent back at the same time as the data going out, let's check I understand this right.
As each bit is sent and received simultaneously it isn't possible for a single transfer to send data and receive a response (to that same data).
Basically, while the master hardware is clocking out bits on the MOSI line (master out, slave in) it is also clocking in bits on the MISO (master in, slave out). Effectively, during one character time, it both sends and receives one byte. Hence the name of the function SPI.transfer.
char a, b;a = SPI.transfer (4);// a is now 1b = SPI.transfer (3);// b is now 2
byte ident_reg_contents = B00000000;SPI.transfer(B01001000);ident_reg_contents = SPI.transfer(B00000000);
SPI.transfer(0); // MS byteSPI.transfer(0x48); // LS bytebyte result1 = SPI.transfer(0);byte result2 = SPI.transfer(0);
Their page seems to suggest the data is in 16-bit lots