search

Lora-net / llcc68_driver

Driver for LLCC68 radio
BSD 3-Clause Clear License
59 stars 24 forks source link

BUSY signal handling #1

Closed pkral78 closed 3 years ago

pkral78 commented 3 years ago

Hello,

it seems that some write command trigger BUSY signal while some does not. For example:

// this command assert and deassert BUSY 
llcc68_set_standby(NULL, LLCC68_STANDBY_CFG_RC);
// this command does not
llcc68_set_dio_irq_params(NULL, LLCC68_IRQ_ALL, LLCC68_IRQ_ALL, 0, 0);

In current API HAL definition it is then difficult to distinguish if it is neccessary to wait or not. While it is possible to pass such information using context parameter, it delegates such responsiblity to caller. I would like to see that this kind of information is handled inside HAL itself. Also defining maximum timeout for command would be usefull.

matthieuantoine commented 3 years ago

Hello,

Why would you need to wait AFTER you send the command? You can deal with this behavior by adding a check on BUSY signal state at the very beginning of your implementations of both llcc68_hal_write and llcc68_hal_read so you wait for the chip to be ready before you start sending data over SPI.

Note that if the chip is in sleep mode, BUSY is asserted until you wake the chip up (with toggling NSS).

pkral78 commented 3 years ago

Hello,

you're right, maximal Tsw is under 600ns what is neglible (until transaction is queued and driven by DMA which is not my case), so there is zero chance to outrun BUSY before next transaction. So checking BUSY before transaction is right approach.

Thank you. I close this issue.