I have a nordic radio module http://www.olimex.com/dev/mod-nrf24L.html which I am attempting to create a c# driver for (the device is a Fez Rhino). I've been able to initilize the device and been able to send it data however I'm not sure if the device is receiving the information on the SPI bus. Whenever I send a command down the bus I get back hexadecimal "E". I have been reading the chip specification (NRF24L01) trying to determine if the hexadecimal E response is normal, an error or is an invalid response for this device. All the example code that I've found doesn't seem to care about the response from the device so I don't even know if to expect a response.
My question is: Does the device respond when commands are sent to it, and if so can you point me in the direction of that literature?
Best Answer
A bidirectional SPI port always sends out and receives data simultaneously; bytes are generally sent MSB first(*), and the master will not send out a bit until it has received the previous bit. Consequently, while it is possible for an SPI slave to use the upper bits of a byte received from the master in deciding what to send on the lower bits(#), most addressing scenarios require that the slave send data after the master has sent a complete address. The most common pattern for this is for the master to send out the address while ignoring any data sent by the slave, and then for the master to send out a byte of dummy data for each byte of data it wishes to receive. The slave will typically ignore the actual byte values sent by the master while it is outputting data.
The Nordic chips make a slight improvement to this protocol; since the master will often want to read a status value, the Nordic chips will always send out their status as the first byte in a transaction, before they find out what the master really wants. If it turns out the master was interested in the status, great--it got the information with one transaction rather than two. Otherwise, the master can ignore the first byte returned from the Nordic and look at the second.
Incidentally, the Nordic documentation does not say, so far as I can tell, what any bytes after the second byte will contain. If I had my druthers, the byte sent by the master following a read command would specify an address to be used in case the master sent another byte, thus allowing N registers to be read by exchanging N+1 bytes; I have no idea what the Nordic chip actually does, though.
(*) Some microcontrollers allow data to be sent and received LSB first. This can be useful for communicating with some existing synchronous serial devices which process data in that fashion. Further, in some cases it may be easier to design I/O devices like extended precision multiply units which send/receive data LSB first.
(#) I can't think of any hardware devices which implement such ability, outside my own CPLD designs, but one can design a device to allow multiple types of status readout with a single transaction, based upon the upper bits of the first data from the master. If one were designing a Nordic-style chip from scratch, for example, one could have seventeen different 4-bit status registers; the four upper bits of the first byte received from the slave would be the primary status register; the other four bits would be from a status register selected by the four MSB's supplied by the master.