I am investigating the possibility of porting MicroPython to STM32F0 and STM32F1. I would like to know whether it is conceptually feasible. I do know this would be very close to (if not over) the lower limit of MicroPython.
The particular processor I am looking at is STM32F060CB, with a M0 48MHz core, 128kB Flash and 16kB SRAM.
Compromises I am happy to make:
- Python scripts would be limited to simple/small/few.
- Remove some of the code emitters. Compressed bytecode alone would be enough, although it would be nice to have native code emitter as well.
- Reduce/remove non-core Python library support
Looking forward to hear your thoughts on this.
Thank you,
Stephen
Porting to STM32F0 and F1
Re: Porting to STM32F0 and F1
I think that getting it downto 128K flash will be the challenge, since the current image is about twice that.
If you dropped USB support, that would probably take a big chunk away.
If you dropped USB support, that would probably take a big chunk away.
Re: Porting to STM32F0 and F1
Thank you for your inputs.
Would you mind sharing a linkmap so I can get a better idea which part of MicroPython takes up the most space?
Also is 16kB memory realistic? How small a stack can we use realistically?
Thank you.
I read somewhere that the minimum requirement is 128kB flash and 8kB RAM. Is that now obsolete?dhylands wrote:I think that getting it downto 128K flash will be the challenge, since the current image is about twice that.
By taking USB away, does that implies taking MSC and file system away?dhylands wrote:If you dropped USB support, that would probably take a big chunk away.
Would you mind sharing a linkmap so I can get a better idea which part of MicroPython takes up the most space?
Also is 16kB memory realistic? How small a stack can we use realistically?
Thank you.
Re: Porting to STM32F0 and F1
Taking away USB would take away MSC (also known as USB Mass Storage). It wouldn't necessarily take away the flash filesystem.
The current pyboard is 256K + 112K for the flash file system.
If you want to use a flash filesystem, you'll need to reserve as much RAM for the flash file system as the size of the largest block contained in the file system (on the pyboard the 112K is made up of 3x16K flash blocks and 1x64K flash block, so it needs 64K of RAM for that.
You can still use frozen modules to hold your python source code without having to use a file system at all.
I think that 128K is a goal, but until somebody actually does a port that works in that size, it's still theoretical.
The size of your stack will largely depend on the type of python code you run. I'm going to guess that it could be as small as 1-2K. The pyboard allocates 16K.
I copied a firmware.elf https://www.dropbox.com/s/t65ugu8gbff9v ... e.elf?dl=0 and firmware.map https://www.dropbox.com/s/90q5ld609wsi4 ... e.map?dl=0 to my dropbox account. These are for the pyboard.
The current pyboard is 256K + 112K for the flash file system.
If you want to use a flash filesystem, you'll need to reserve as much RAM for the flash file system as the size of the largest block contained in the file system (on the pyboard the 112K is made up of 3x16K flash blocks and 1x64K flash block, so it needs 64K of RAM for that.
You can still use frozen modules to hold your python source code without having to use a file system at all.
I think that 128K is a goal, but until somebody actually does a port that works in that size, it's still theoretical.
The size of your stack will largely depend on the type of python code you run. I'm going to guess that it could be as small as 1-2K. The pyboard allocates 16K.
I copied a firmware.elf https://www.dropbox.com/s/t65ugu8gbff9v ... e.elf?dl=0 and firmware.map https://www.dropbox.com/s/90q5ld609wsi4 ... e.map?dl=0 to my dropbox account. These are for the pyboard.
Re: Porting to STM32F0 and F1
Thank you Dave. Most appreciated for the linkmap.
What is the smallest successful port you know of?
I have no problem taking away the MSC and the file system. There is already a very primitive pseudo file system. There would be no need for floating point support, and I am happy to prune away 80% of the python library support, with only the core, string manipulation and basic arithmetic left. However given the current size I would still say it would be a stiff challenge with my proposed compromise.
What is the smallest successful port you know of?
I have no problem taking away the MSC and the file system. There is already a very primitive pseudo file system. There would be no need for floating point support, and I am happy to prune away 80% of the python library support, with only the core, string manipulation and basic arithmetic left. However given the current size I would still say it would be a stiff challenge with my proposed compromise.
Re: Porting to STM32F0 and F1
I compiled the "minimal" port using the ARM compiler and it came in around 78K.
The teensy port (which has USB serial but no UMS) is around 190K.
The teensy port (which has USB serial but no UMS) is around 190K.
-
- Posts: 33
- Joined: Wed Sep 07, 2016 10:46 am
Re: Porting to STM32F0 and F1
Just saw these posts _after_ posting a question myself re an F1 port (DOH!!)
I have a board with an STM32F103VE MCU (512KB Flash, 64KB RAM). Plenty of resources for MP
Dave, do you still have your F1 port ?
If so, are you able to commit that to MP git repo ?
Thanks, Brendan.
I have a board with an STM32F103VE MCU (512KB Flash, 64KB RAM). Plenty of resources for MP
Dave, do you still have your F1 port ?
If so, are you able to commit that to MP git repo ?
Thanks, Brendan.
Re: Porting to STM32F0 and F1
I haven't started anything on the f0/f1 front.
Starting with something based on minimal is probably the best way to become familiar. Then throw that away and do it properly inside stmhal.
Starting with something based on minimal is probably the best way to become familiar. Then throw that away and do it properly inside stmhal.