PIN „Database“

[Velocet]

In the wake of more people using LoRa modules the lack of a reliable source for PIN mappings becomes obvious. A lot of projects have to maintain their own set of configurations.

Proposal

A config "database" for LoRa modules with a sane naming scheme so we can all benefit from it.

LoRa32

This is something i put together but i would move this little "lib" into its own project (maybe under the new RadioLib-Org?) and incorporate ideas and configs from @matthias-bs plus some vendor/architecture specific extensions. The name was chosen because most modules come on the back of the ESP32 platform. Happy to change it to something more descriptive.

• Vendor/Architecture specifics should be kept in separate files like lora32_heltec.h or lora32_rp2040.h
  • The same rule should be used for libs
• lora32_*.h files should always be optional
  • Included by default
  • #define guards make sure the right ones are loaded
  • Configurable in the main lora32.h file or project itself

Benefits

• Same sane PIN naming for different boards across different vendors and platforms
• Possibility to only use the bare minimum for projects like RadioLib
• Vendor/Architecture specific extensions
  • Bugs (eg.: set pinMode to INPUT on GPI only pins used for interrupts)
  • Deep Sleep
  • Display config (nothing i care about..)
  • Battery measurement
• ???

This is just a proposal and my "code" isn't that great but it could be a starting point.

[HeadBoffin]

Happy to change it to something more descriptive.

You could start with the description of the repro &/or pull it out to its own repro.

[Velocet]

There you go: LoRa32

[Velocet]

Updated the project so it can be used with PlatformIO:

lib_deps = https://github.com/Velocet/LoRa32

#include <LoRa32.h>

[jgromes]

Thanks for sharing this @Velocet, here's my couple of cents on the issue:

• IMHO consistent database like this is very useful. Absent any existing one, projects that need to deal with multiple LoRa boards just roll their own (see e.g. tinyGS). In RadioLib development, when dealing with multiple hardware platforms, I ended up having to save the example sketches modified for a specific platform into a dedicated folder, so I end up with e.g. SX126x_Transmit_Artemis, SX126x_Transmit_Lolin, SX126x_Transmit_Nucleo, SX126x_Transmit_Uno which only differ in pin and SPI setup ... it's workable, but cumbersome.
• additional features like OLED pins are nice, but come with significant risk of feature creep - you will find that there are boards with OLEDs, GPS modules, on-board sensors ... it's nearly certain that this "configuration management" library will always be somewhat incomplete. If that doesn't bother you, then you can declare that the only thing your library will ever be dealing wiht are the radio pins.

[Velocet]

You are totally right when it comes to things like display, battery, etc. Those are things which could be considered later. I already changed the scope of the project and by default there will only be the bare minimum, which is validated pin configs. I am aware of the fact that this will be an incomplete lib as its the nature of such a "database".

[matthias-bs]

@Velocet Thanks for starting this project, which is indeed very helpful. It wouldn't be needed if the definitions in pins_arduino.h (arduino-esp32 etc.) were more consistent.

Do you have any idea how to support FeatherWings / FireBeetle Covers with their user-defined wiring between radio chip and GPIO pins?

[Velocet]

I had a look at the information provided by DFRobot and Adafruit:

• Adafruit Feather M0 Radio PinOut
  • Everything predefined. Nothing to do.
• Adafruit FeatherWing Radio PinOut
  • Only SPI predefined. I would suggest taking the KISS approach and use the pin definitions from the M0/RPi/etc. Feather. We simply define the configs for the user. He can still change it but at least there are sane defaults.
• FireBeetle Covers-LoRa Radio 868MHz
  • Same situation as with the Featherwing: Only SPI predefined.

Please see the additional explanation below...

[Velocet]

Hi and thanks for all the responses!

I dug through code from meshtastic, ExpressLRS, tasmota, and other ESP32 based projects which gave me a lot to think about. They all go different routes with some neat ideas.

One question that came to mind: Is there any way to determine the (additional) PINs used by the radio if we only have access to SPI (as stated in my answer to @matthias-bs, SPI is always predefined)???

The only "solution" i can think of is to try standard version registers to see which radio we are dealing with.
Let's say we have a SX1262: Configure the DIO pins and run the radio in Rx to trigger interrupts. Then poll a pin (or set a interrupt function) and see if we get an interrupt. This interrupt should be for something which always works (receive noise as data which fills the buffer in any case). If not: Next pin. This can be implemented as special mode which tries to determine the configuration and writes out the LoRa32 config. It would not matter if this would take some time as it would be run once to get the initial config.

Realistically this is nothing serious but the only idea i can think of to solve this problem.

One other major concern is the PIN naming itself. A lot of libs use PIN_*. Since LoRa32 should not override/interfere settings the LoRa32_ prefix is used. Maybe some kind of compatibility mode (which strips the prefix) is the right way to go.

The posted tinyGS example from @jgromes is great! Looks way better than my approach. I think this will be adopted.