Skip to content

Velocet/LoRa32

Repository files navigation

LoRa32

In the wake of more and more people using LoRa the lack of a reliable source for PIN mappings became obvious. A lot of projects need to maintain their own set of configurations which leads to inconsistencies and the need to maintain this data.

Proposal

A config "database" for radio modules with a sane naming scheme so we can all benefit from it: LoRa32

This incorporates ideas and configs from RadioLib, @matthias-bs (BresserWeatherSensorReceiver) plus some vendor/architecture specific extensions.

The name stems from the fact that most boards are based on an ESP32 with a LoRa capabale radio module.

  • File Naming Scheme
    • LoRa32.h - Main include file
    • Vendor/Architecture specifics should be kept in separate files like LoRa32_HelTec.h or LoRa32_RP2040.h
      • vendor/LoRa32_*.h - Vendor/Board specific files
      • arch/Lora32_$Architecture.h - Architechture specific files
      • Lora32_$Library.h - Library specific files that could by used by all (or most) implementations
  • LoRa32.h should only contain the bare minimum which are the board configs
    • Needs to be usable without any specific includes: Easier to include into other projects. Just copy&paste and adopt to your own needs instead of using a lib.
    • Because of this a version number (incl. date + git revision) needs to inside every file
    • #define/#if are used to take care of the flow
  • LoRa32_*.h files are optional but:
    • Included by default
    • Configurable in the main LoRa32.h file or from the project itself
      • Project settings always overwrite lib settings
      • LoRa32.h settings always overwrite LoRa32_*.h settings
  • PIN Naming Scheme ($prefix_$group_$function)
    • All uppercase to differentiate from other settings
    • $prefix
      • Standard is LORA32_
      • Compatability mode removes prefix
      • Can be changed if needed (eg. adopt to own project)
    • $group
      • Undefined if a function (RADIO, I2C, etc.) is not defined/used
      • Example: A board without a radio module has its $prefix_RADIO undefined
      • Can hold additional config data
        • Example: LORA32_RADIO = SX1276 defines RadioLibs RADIO_TYPE (LORA32_RADIO radio = new Module(...)).
      • Predefined $groups
        • PINS (eg. $prefix_PINS_SPI): Defines a group of PINs for the same functionality (eg. SPI) with the PIN definitions as array data
        • PIN (eg. $prefix_PIN_MOSI): Compatability mode only: Additional definition of the PIN name
          • LORA32 definition: LORA32_SPI_MOSI
          • Compatability mode: PIN_MOSI
        • SPI: SPI name (HSPI/VSPI)
        • DISPLAY: Display geometry information
        • RADIO: RadioLib RADIO_TYPE
        • TBD: ... TBD ...
  • Targets
    • Tool: VSCode with PlatformIO / Arduino
    • Framework: Arduino
    • Main Platform: ESP32(S2/S3)
      • Other:
        • ESP8266
        • RPi
        • Arduino Mega
        • TBD

Features

  • Same & Sane PIN naming for boards from different vendors and platforms
    • PIN definitions for/from some common libs (#define esphome)
    • Sane standard PIN definitions for DIY builds based on already established standards
  • Workaround for Bugs (eg. set input only PINs to input which could cause radio interrupt errors)
  • Deep Sleep Support
  • Persistant Storage support
  • Battery measurement
  • Basic Display config (nothing i care about..)
  • Optional Automatic Lib Configs based used defines
    • RadioLib module configuration
    • Some standard display lib setups
  • TBD

Ideas / Notes / Status

Original Discussion: PIN „Database“ @ RadioLib