Warning when regenerating code
jpmeijers opened this issue · comments
I get this warning when I save changes to the .ioc file:
This is related to two missing button configurations under the LoRaWAN middleware:
Is there a way in which we can remove these two unused buttons so that this warning doesn't occur?
I think there is but it means more user code. See answer from IREM.1 (3rd from last in thread) here. It seems to indicate that defining 1 led and 1 button should be possible with this "system", and it is, but it gives the warning. I find it acceptable to "ok" the warning as it permits adding more buttons/leds easliy for other boards later on.
One could however try to find a new place (somewhere where it is not overwritten) for the generated functions in board_resources.c and stop to use this feature. But it would make the setup more rigid as adding new buttons would mean adding user code manually somewhere.
A "good" place would probably be in gpio.c.
I started a similar project this week which may be interesting. I started fresh, creating a new CubeMX project specifically for the WLE5JC used in the Seeed LoRa-E5 rather the WL55JC used on the Nucleo.
Using WLxx FW V1.1.0 and CubeMX 1.8.0.
Then I configured all the peripherals/GPIOS/LoRaWAN until I had a clean-building, regeneratable build with no warnings during regeneration. I used GPIOs correct for the LoRa-E5 Mini. Note that I configured to use the WLxx BSP from FW V1.1.0. This was mostly the same as the LoRaWAN_End_Node example for single-core, except the lora_app.c framework only joins, and does not have the functionality of the example other than joining.
I then forked the BSP for the Seeed LoRa-E5 mini, stubbing LED1, LED2, BUT2, BUT3 so they are no-ops.
Finally, I manually merged the ST LoRaWAN End Node lora_app.c, which was trivial since the BSP is present.
This builds without warning, regenerates without warning. Note that I am using #define HYBRID and custom-configured channel map for US915, the channel map is reset when regenerating. There's probably a better API for sub-bands I should use in lora_app.c
You're welcome to peruse this repo, just pushed this morning (it generates, builds, works as I've tested, but it is fresh out of the oven)
@jpmeijers with the solution in the rep of @danak6jq, can we close this issue?
Sure, let's close this issue as it's been fully discussed and a solution provided. I'll be testing @danak6jq's repo soon.