lejibxl wrote: ↑Fri Apr 24, 2020 9:24 am
The first one is why Damien P. George created a repository for the card "B-L072Z-LRWAN1".While it seems impossible to make the micropython work (you still have to add a LoRaWAN stack with all dependencies (float, ...) and a phyton program for the application). I understand that the internal flash is too small, but why didn't you provide a possibility to add an SPI Flash? When I see the quality of this whole project, there is certainly a goal, but this is something I don't understand.
Perhaps that was (or is) on the TODO list, but there are lots of other priorities. Compared to getting MicroPython running at all on the STM32L0 family, these are all relatively minor things that need to be done. At least what's there is a good base for open source contributors to build on (who might not have been as comfortable doing the initial L0 port themselves). And I guess it's just a case of "it's valuable as a base for other people to work on, so might as well share it".
Edited to add: Another interesting piece of background -- MicroPython works on a lot of different devices, which means a lot of development boards for the maintainers to own. And so if you're going to buy development boards (which are almost as expensive to ship as the boards themselves) you might as well get interesting ones (which this one certainly is). I believe this board was used to develop the L0 port (which is useful for far more devices than just the LRWAN1 board).
The other thing (that already works on this board) is to use frozen modules. It means you can still write your code (and the LoRa driver) in Python, but the bytecode is compiled into the firmware.
I actually have one of these boards, and would be keen to get it working myself but have too many other things to do! Would be interested to hear if you make any progress.
lejibxl wrote: ↑Fri Apr 24, 2020 9:24 am
I saw that CircuitPython has finalized the use of a Flash SPI with a Cortex-M0:
https://github.com/adafruit/circuitpyth ... m0_express
but they don't seem to use storage.c which seems to be a combination of internal flash and external SPI flash.
CircuitPython and MicroPython only really share the core VM -- all the hardware drivers and peripheral support is completely reimplemented from scratch in CircuitPython.
The background here about what's happening in storage.c is that, in MicroPython, it periodically flushes the block cache out to the flash. It uses the flash IRQ to do this at low priority. This is why it's using the NVIC->STIR register to do a software triggered interrupt. (This works on everything except M0, but I think the alternative I suggested might work).
I imagine CircuitPython have done something similar, but I'm not familiar enough with their hardware drivers to know off the top of my head.
lejibxl wrote: ↑Fri Apr 24, 2020 9:24 am
Your proposal to do this in python, does this mean I have to modify the boot.py to include the SPI mount command (
https://docs.micropython.org/en/latest/ ... re-spi-bus) and da run main.py on this SPI-FLASH?
You could write a block device in Python (that uses machine.SPI, yes), and then mount it with os.mount.
See
https://docs.micropython.org/en/latest/ ... ystem.html for all the info about this.
lejibxl wrote: ↑Fri Apr 24, 2020 9:24 am
Your other proposal to use NVIC_SetPendingIRQ(FLASH_IRQn) do I have to do this in the bdev.c file? ??
Nope, this replaces the line that you had the compile error on in storage.c:
NVIC->STIR = FLASH_IRQn;