Hi.
I've recently tried to use this library with a RFM69HCW. Sadly, the communication just did not work and even the read_all_regs
call resulted in all registers having the same values (sometimes depending on the SPI speed setting). Also, manually write
and read
to the registers wouldn't work, as their values always stayed "the same".
~6 hours later ~
There is a mistake inside here:
|
let mut operations = [Operation::Write(&write), Operation::Write(data)]; |
|
let mut operations = [Operation::Write(&read), Operation::Transfer(buffer)]; |
|
self.write(&[reg.write()])?; |
|
self.write(&[reg.read()])?; |
This library performs separate SPI operations to first write the operation + register-index and then the padding bytes to transfer
the data back from the chip (or in case of write
the data is just being written). Why is this fatal? Let's have a look into the datasheet, page 44...
The chip expects the CS
to be low during the data-transfer (which is implemented correctly), but will instantly answer with the requested data back to the host - our sample chip does not even wait for the padding byte of the master. In case of the two separate write
calls, this just leads to rubbish being written.
Solution?
A proof of concept to fix the single-byte communication can be found here: https://github.com/simonmicro/rfm69/tree/bug/rfm69hcwSerialCommunication. It allows to set and get a register, but will still fail on the read_all_regs
call. A janky solution to fix the multi-byte communication can be found here https://github.com/simonmicro/rfm69/tree/bug/rfm69hcwSerialCommunicationWithStd - but as I'm no Rust-pro I was forced to remove the nostd
limitation and to use a buffer-copy with allocation to get it working.
I hope this can be merged / ported to properly fix this, including the nostd
-requirement.
Greetings!
Also I would recommend implementing something like this: https://github.com/jgillula/rpi-rfm69/blob/44ed86d9e70e7d1010d41ce6386c709d9d7d1689/RFM69/radio.py#L117. This will allow developers to more quickly discover problems with their SPI setup, as well as properly syncing with the chip.