I'm looking at the datasheet, and it looks like the nIRQ pin is active low. Furthermore, in the case of a power-on reset, it sounds like the nIRQ should be reset by simply reading the status:
• POR: both the nIRQ pin and status bit can be cleared by the read status command
As I interpret that, you're getting correct behavior, so far. nIRQ starts out getting pulled low, then you read the status, which clears the interrupt, and IRQ goes high again. It wasn't clear to me that a RFM12B that's just sitting there will generate IRQ activity - especially when all the radio-related functionality was just turned off (with 0x8205)
Why aren't you recording what the RFM12B is sending back? You should certainly be getting data back when you send 0x0000. I think looking for this would be a better way of seeing whether you're communicating with the device.
function XFER(cmd) {
console.log(SPI1.send([cmd>>8,cmd], B8));
}
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I'm looking at the datasheet, and it looks like the nIRQ pin is active low. Furthermore, in the case of a power-on reset, it sounds like the nIRQ should be reset by simply reading the status:
• POR: both the nIRQ pin and status bit can be cleared by the read status command
As I interpret that, you're getting correct behavior, so far. nIRQ starts out getting pulled low, then you read the status, which clears the interrupt, and IRQ goes high again. It wasn't clear to me that a RFM12B that's just sitting there will generate IRQ activity - especially when all the radio-related functionality was just turned off (with 0x8205)
Why aren't you recording what the RFM12B is sending back? You should certainly be getting data back when you send 0x0000. I think looking for this would be a better way of seeing whether you're communicating with the device.