Closed mharizanov closed 9 years ago
This introduces Arduino-specific code, would it be ok to just fix the RFM_IRQ?
Update: ah, didn't read your comments. I'd prefer to keep this Arduino-independent, if it's easy to do.
The wrong RFM_IRQ issue is just part of the problem, the thing is that there is discrepancy between the RFM12 SPI init and RFM69 SPI Init.
rf12_spiInit uses Arduino code (pinMode, see https://github.com/jcw/jeelib/blob/master/RF12.cpp#L166 ) to init the SPI, thus the SPI pin defines use Arduino pin number rather than port bit.
For direct port manipulation we would need the pin bit within the port, so that _BV would return correct mask:
Copying these defines over to the RF69 init code doesn't work as the RFM69 spiConfigPins uses direct port manipulation with the same pin defines copied over from the RFM12 code which uses pinMode.
This is alternative fix, using the correct defines for direct port manipulation; however this would make RFM12 and RFM69 defines different
static void spiConfigPins () { SS_PORT |= _BV(SS_BIT); SS_DDR |= _BV(SS_BIT); PORTB |= _BV(SPI_SS); DDRB |= _BV(SPI_SS) | _BV(SPI_MOSI) | _BV(SPI_SCK); }
I'll go with your latter suggestion - pulling in the Arduino runtime is not always practical have committed the changes, am cancelling this pull request...
Hi JCW, The pin definitions suppose pinMode usage rather than direct port manipulation, hence the SPI init was failing. One option is to use pinMode and keep the definitions, alternatively the defines may be changed and the direct port manipulation to remain..