Rationale for selecting this core vs stm32duino

[joseangeljimenez]

I have been doing some serious prototyping, for months, with all these boards: B-L072Z-LRWAN1, GrassHopper and a custom board with a Murata module. I have mostly used your core but also the "official" STM32duino core.

It'll be of great help for me and surely for others if you can share your thoughts on why/when should one choose your core, specifically, at least in my case, with these requirements:

1. Mostly point to point LoRa communication (not LoRaWan),
2. Low power applications (battery powered devices).

Some comments on the rationale about your core will also do. IMHO, it'll be also a nice addition to the README of the project repository.

Thanks for your great work! Jose

[GrumpyOldPizza]

Loaded questions. Tricky to answer.

First off the platform is meant to be as low power as possible. It's not really geared towards the various NUCLEO boards (or B-L072Z-LRWAN1), as they per definition are not low power, nor do they really support USB in any meaningful way.

In general, most other ArduinoCore implementations try to get away with the minimum possible, disregarding performance and stability. Often that means that things are fragile, like UART works nicely at 9600, but not anymore at 115200 under heavy load.

What this code here does well is to integrate USB, a DOSFS filesystem on a SDCARD or SFLASH and the Radio layer in a stable way, at the lowest power possible. A classic sensor node on the edge.

So just a few quick examples ... Do other cores support a "TimerMillis" facility that can be used to wakeup from STOP (not just a single RTC Alarm) ? Is there support for a GNSS that will sync time via PPS (and deal with UTC vs. GPS time, leap seconds and such) ? Is the core virtually tickless, or is there an ISR that fires every 1ms and hence makes SLEEP mode virtually pointless ? Does the core do proper clock gating, so that when you are done with your I2C transfer the peripheral does not consume power anymore ? Does the UART code properly use circular DMA, so that for higher baudrates you do not drop data on the receive part ? Does the code deal with parity errors and BREAK conditions on UART receive part ? Is there a proper FTL ontop of the SFLASH, so that you can use USB/MSC to get data from your sensor node, efficiently ? Does the SPI code use DMA, so that you can do writes to your ePaper/eInk display in the background ? Does your core use WFE to avoid busy waits in say "delay()" ? Do the other cores allow control over what wakes your "loop()" up from STOP mode, or does every single interrupt wake up, and causes extra code in "loop()" to execute, consuming power ?

What I am getting at is that there are soo many details under the hood ...

[joseangeljimenez]

Thanks for your prompt and clear response!

Now I have a more precise understanding of the direction and goals of your implementation. The examples you indicate are great pointers to certain code drivers/source files, for me or anyone interested in getting into the details. I had been studying the USB integration code and low power mode tricks, but many other things got under my radar.

Again, thank you for your great work. I still think it'll be a great addition to the README of the project to include a brief statement (or maybe a list?) with the most relevant features of the core, compared to a "barebones" core. It is difficult to communicate, but will make it stand from the crowd out there, on your own merits.