RFM69 Library - Manual Pin Assignments?

[ItzGenX]

I have several Moteino M0's working as nodes just great.  However, I have a different MCU that I want to use for my gateway since it will be handling other tasks as well as run a shield CAN bus and display module.  The other MCU in question is still a SAMD21, but it is mated to a Sparkfun Redboard Turbo.

Aside from the usual SPI bits like MISO, MOSI, SCK, 3.3v, and GND, are there ways to change the pin assignments for NSS/CS/SS and interrupt/DIO0?  Is there a couple lines of code I can throw in my sketch to change the pin assignments without digging into the library.

Additionally, the library has a lot of MCU defines, but I am not sure if mine defines correctly when leaving the library to do its own thing. (ARDUINO_SAMD_ZERO)?.  Hence, I'd rather have full control over it in the specific sketch if possible.  If modifying the library, could I just add the board's name to the list? Or, would I need to use the chip ID?  How would I find this information?

[Felix]

Recently there was a contribution to the library to support custom SPI classes (full commit here). Here's the constructor prototype allowing you to pass in your own SPI class with whatever pins you want to define in your sketch, as well as the interrupt pin you want to use, note that the interrupt pin has to be able to be setup as a hardware interrupt:

Code Select Expand

RFM69::RFM69(uint8_t slaveSelectPin, uint8_t interruptPin, bool isRFM69HW, SPIClass *spi)

************************************
My initial thought (too early in the morning!) - this would only apply if you want to tailor the library to another default hardware SPI:
The SAMD family of chips AFAIK all have the same pinouts, except the smaller chips don't have some of the pins broken out physically.
The SAMD21 definition for MoteinoM0 is in the variant.h/cpp files in the MoteinoM0 board definition.
This is then matched with the SPI pin macros in the RFM69.h definitions.

Are you trying to use another SPI port on the SAMD21?

If you define your own board as a new variant in Arduino, then you dont need any changes to the library. Follow the pattern you see in the MoteinoM0 variant.h/cpp files - you would only basically need to remap the SPI to another port on your particular SAMD21.
Otherwise you have to change the library to define a custom board with custom pins. Either way you will need to reference some kind of board definition.

[ItzGenX]

Felix,

Thanks for the great response.  My main issue is that I can't quite decipher how the RFM69 library identifies Sparkfun's board and ultimately sets the pins from there.  It could be assigning different pins than I am expecting.  On top of that, I do not know if Sparkfun's variant using "SerialUSB" would affect the operation.  Within the sketch, you can get around it with the tried and true usage of "SERIAL" to be defined as "SerialUSB" like so:

Code Select Expand

#ifdef ARDUINO_SAMD_VARIANT_COMPLIANCE
    #define SERIAL SerialUSB
#else
    #define SERIAL Serial
#endif

However, that doesn't fix issues that refer to the standard "Serial" call inside libraries themselves, and it does cause random issues with some libraries.  This is something the Moteino M0 does very well by seamlessly using "Serial" as normal which wouldn't ever require the above in your sketch.  The way Moteino's handle sketches seems a lot more universal and compatible, and the M0 makes the unsuspecting user not even know they're on a SAMD21 board.  Sure, I can dig and dig in Sparkfun's board files and try to tune it out if I ever got around to understanding it all, but it is a huge undertaking as I don't quite fully understand it all just yet.  Maybe some day!  Too bad you guys don't make Moteinos in Uno or bigger form factors.  Otherwise, I wouldn't have had this issue in the first place  .

Now here's what I've done for now.  I uploaded the sketch using "Moteino M0" as my selected board in Arduino IDE, and it works the same.  As you have mentioned, the pin outs should be more or less the same, and I did confirm that prior to uploading different board definitions.  So it works so far with a CANbus shield (CS on 10) and RFM69 using the standard MISO/MOSI/SCK pins with NSS on A2 and DIO on 9 without touching the radio library internally.  I'll probably end up running it this way permanently if I never resolve Sparkfun's board definition variant files.

There's a few features I am losing from the Sparkfun board that I would have preferred to retain.  One is the super bright RGB LED onboard, and the other is the 4MB external flash the board uses with emulated EEPROM.

Other than that, the two boards work the same when being defined as the same board lol.  Here's the only pin difference I was able to dig up from comparing the schematics:
ATSAMD21G18 Pad <-> Board
PB03 <-> FLASH MISO (Mote M0 has this as the RX LED)
PA13 <-> FLASH CS (Not pinned on Mote)
PA30 <-> LED or SWCLK (Mote has it as only SWCLK, otherwise both are same)
PA31 <-> RX LED or SWDIO (Mote has it as only SWDIO, otherwise both are same)
PB22 <-> FLASH MOSI (Mote uses as Serial0 TX)
PB23 <-> FLASH SCK (Mote uses as Serial0 RX)

So to get everything working as it should on the board itself, I'll likely need to go back to the Sparkfun board files.  All I would have to fix is how they handle the whole SerialUSB thing to make it handle Serial the same way the Moteino M0 does.  From there, I'll just need the RFM69 library to allow me to select the DIO0 and NSS pins manually within the sketch, have it properly automatically select it, or figure out which ones it actually auto selects at the least so I can jumper accordingly.  That of course would be the optimal solution, but as always, Murphy's Law tends to lurk nearby.