ST fw update for band selection at runtime

[giulcioffi]

The original version of the fw set the frequency region with a define. If the user had to change it, the firmware needed to be re-compiled and flashed with the new defined frequency.
In order to overcome these steps, the fw has been updated to store the region as a variable. The initial band is set to the European one. Whenever a different band is selected by the user, the Lora state machine is re-initialized and the desired band of frequency is enabled.

Command "+BAND" has been added to the predefined set of AT commands to perform the band update. MKRWAN library has been updated to support this command (arduino-libraries/MKRWAN#78).
The user can change the frequency region by using the funciton bool begin(lora_band band).

A simple test (https://github.com/giulcioffi/tests_MKRWAN) allows to continuously change the desired region, read back the frequency of the RX channel and compare it with the expected one.

[sslupsky]

Can we please add a couple long overdue things to this PR to help with power consumption? The mcu cannot be in a low power sleep state when the module attempts to send a response or downlink data. This issue is somewhat manageable in situations where the module responds immediately to an AT command from the mcu. However, there are a few situations where this cannot be addressed with the current firmware. First is for class B or C device downlinks where the downlink does not correspond to an uplink RX window. Second is where the response is not immediate, such as a join command.

I think these issues could be addressed in one of four ways:

1. Implement the module "IRQ" from the module to the mcu. Activate the IRQ a short time before sending data from the module to the mcu. MCU firmware would need to configure the EIC to wake on interrupt. There would need to be approx 0.5ms delay between activating the IRQ and sending the data to allow time for the mcu to wake up. Perhaps this delay could be configurable with a new AT command.

2. Alternatively, the module "IRQ" could work the other way from mcu to module as a "Clear to Send" function. So, the module only sends data to the mcu when the CTS is active. This way, the mcu can set CTS inactive during sleep to avoid the module sending data during mcu sleep periods. This has the potential of a race condition where the module senses CTS active and initiates the process to send data. Simultaneously, the mcu sets CTS inactive and goes to sleep. This race could be averted by also including a check on the module side that CTS remains active at the completion of the transmit.

3. Implement a serial RX "wake" protocol. That is, toggle the RX pin and then wait a short time before sending serial data. The mcu firmware would require the capability of reconfiguring the RX pin to the EIC and then wake on interrupt when sleeping. When the interrupt is detected, the mcu firmware reconfigures the RX pin to the serial port so it can receive the data. There would need to be approx 0.5ms delay between toggling the RX pin and sending the data to allow time for the mcu to wake up. Perhaps this delay could be configurable with a new AT command. This solution has the advantage of leaving the IRQ function for another use.

4. Alternative to 3, the RX pin is used to indicate a Request to Send and the mcu configures RX to the EIC. When the mcu detects the RTS or otherwise wants to receive data from the module, the mcu reconfigures the RX pin to the serial port and requests the data from the module.

I am prepared to help with this but require some feedback on the suggested solutions from @facchinm and @giulcioffi

[sslupsky]

@facchinm Could you please merge these commits to the master-1.3.1 branch and I can pull them and test this out.

[facchinm]

@sslupsky sure, this is a starting point with minimal functionality (just to test runtime band switching which is the functionality I need to test the most).
Any improvement is very welcome! I like the idea 1; feel free to implement it and I'll be glad to merge 🙂
I'm merging this in the meantime