I understand that work is ongoing on branch stm32wl for STM32WL MCUs, but currently the size of the binary is ~140% of the maximum available flash size for said MCUs (256KB), thus it cannot yet be used.
I have a nooby question about the architecture, apologies in advance. So, apart from the above issue, is the architecture fully supported? So if we could shrink the binary somehow, would it be “done”, or there are still unimplemented stuff that need attention? If there are any, and you could direct me to them, I’d be grateful.
I’ve had it running without file system using this branch, but that means you have to configure it (like setting your region) at compile time.
An attempt was made to get the file system working, which seems to reserve a considerable amount of the flash now. I’m afraid getting it to work with file system is still a long stretch and is of low priority at least for me.
Thanks! My understanding is, for some platforms like ESP32, littlefs is being used underlyingly, hidden behind an arduino-based abstraction like LittleFS_esp32. Is that correct?
I have managed to compile the firmware using the stm32wl branch after slight modifications, but it’s still 360-ish KB without file system.
My ultimate goal would not be using a premade board like E5, but to design my own using a low-power STM32 MCU (enough flash for the firmware) and an external LoRa chip like SX1262. If I get things correctly, once/if I get the FS working (that is, I implement it ), it should be pretty straightforward to set up the firmware for a custom board.
Yes, LittleFS is used for ESP32, but it uses the library provided by the Arduino core of ESP32.
The Arduino core for the STM32 doesn’t provide this unfortunately. An attempt was made to create an emulated EEPROM using the flash. That seems to be the most viable option, but it wasn’t successful yet.
), it should be pretty straightforward to set up the firmware for a custom board.