Feature request: selecting lorawan region configuration at runtime instead of at compile time.

[HouzuoGuo]

Is your feature request related to a problem? Please describe.

I am working on an experimental IoT device targeting users of both North America and Europe. The device offers a "first-boot" user experience to collect locale and other mandatory app-specific settings before it transmits over lora for the very first time.

For the convenience of logistics and distribution I'd like to configure the lorawan region as part of the first-boot experience, instead of making two distinct batches of devices each compiled with a distinct CFG_xxxx.

Describe the solution you'd like

Ideally, I'd like to invoke a new library function to set the lorawan region at runtime. It is OK to require a hardware reset when changing the region.

Describe alternatives you've considered

Making two distinct batches of devices using two distinct software versions.

[terrillmoore]

@HouzuoGuo this is definitely needed. I've wanted this for a while; as have others (see #651). However, it's a heavy lift, and MCCI can't fund me to do it at the moment. (MCCI can accept commissions to do this work, and other work; but MCCI is not in a position to self-fund it.) It's such major work that I don't see how it can be done by someone else without the same kind of fork that happened when I started making the changes here for compliance and US support. But open to suggestions.

[mrx23dot]

The region/frequency selection is highly convoluted, spans over multiple files. There must be an easier, more elegant way.

There are only 16slots of frequencies, SF/duty cycle for each. like: setRegion(&freqMap, REG_EU868)

[terrillmoore]

It's more complicated than that. Look at the differences between EU and US. I inherited the architecture, after EU and US had been implemented with conditional compiles; sorry for the defects added. Feel free to submit a PR, or to organize a way to fund the work required to unify this.