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:

• rfm69/src/rw.rs

  Line 29 in cfc53c9

  let mut operations = [Operation::Write(&write), Operation::Write(data)];

• rfm69/src/rw.rs

  Line 35 in cfc53c9

  let mut operations = [Operation::Write(&read), Operation::Transfer(buffer)];

• rfm69/src/rw.rs

  Line 48 in cfc53c9

  self.write(&[reg.write()])?;

• rfm69/src/rw.rs

  Line 54 in cfc53c9

  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.

This is more of a support request than a bug, let me know if there's a more appropriate place to ask.

I'm trying to get this working with an Adafruit RFM69 bonnet on my Raspberry Pi 4. For a start I'm trying to run the receive example included with the crate.

According to the pinout, RST is connected to GPIO 25 and CS to CE1, so I changed the example to use /dev/spidev0.1 (which from what I understand will result in CE1 being pulled high while communicating). I don't understand why the example also sets up a SysfsPin for CS. What is this supposed to do, given that spidev is already managing the CS line? I tried commenting out the code in lib.rs which uses CS, and changing receive.rs to set_direction(Direction::Low) so it isn't holding RST high, but it's still not working; it reports every register value as being 0x00 and then panics on the recv call.

Any idea what I'm missing here? And why does Rfm69::new take a separate pin for CS?

It would be nice to send larger packets than the FIFO. As far as I understand, we could use RegFifoThresh and read out the FIFO while still receiving a packet. Have you already tried anything like that, @almusil? Otherwise I'll give it a try.

The examples don't build on a clean checkout. It looks like it may have been because linux_embedded_hal made some breaking changes in 0.3.1.

• Support high power variant
• Support power level settings by user

• Add examples for generic usage
• Add examples for usage with LowPowerLab compatible RFM69