mysensors / MySensors

MySensors library and examples
https://www.mysensors.org
1.31k stars 895 forks source link

radio abstraction #370

Closed trlafleur closed 8 years ago

trlafleur commented 8 years ago

The fix for the long term, is radio abstraction...

ie: radio = rfm69c, or radio = rfm69w, or radio = rfm69hw, or radio = nRF24 or radio = xyz This should allow using the RadioHead lib in the future... ie: any radio...

with some layer of abstraction for radio options like the ones below...

radio.set_freq= 912650000 ( this could imply the band also)
radio.set_band= 915MHZ
radio.set_channel = 72

#define MY_RFM69HW true
#define MY_RFM69_FREQUENCY RF69_915MHZ
#define RFM69_FREQUENCY 912650000
#define RFM69_NETWORKID 120
#define RF69_SPI_CS 10
#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 0

all items like this should be abstracted to the radio level...

for now, it would be nice to have a guide for using each type of radio, with documentation on all known options...

(By the way, MY_RFM69_FREQUENCY should be MY_RFM69_BAND, as it selects the freq band the radio is in, not its (exact) frequency)

Thanks... my two bits...

fallberg commented 8 years ago

I'm not sure you can abstract the pin definitions. They are hw specific and not necessarily the same for all that uses a particular radio.

trlafleur commented 8 years ago

the driver can take care of this for each device type if needed... if RFM69 has a CS pin: radio.set_CS_PIN = 5 will work, ie: it can over-ride the pre set's made in the code. another radio without the pin, will ignore it or flag a compile error documentation in the manual or RFM69_drive.h file will define each of these... common ones will be the same for all radios and used by all drivers

my two bits...

fallberg commented 8 years ago

Ok, you mean renaming the existing definitions in MyConfig.h to be less radio specific. We do not want c++ code in the core. In fact we are working on purging that crap out. It just bloat the code and increase the memory footprint.