For v1.28 I've already started porting machine_pin.c and machine_cpu.c files into P2LLVM based MicroPython and have had some success compiling them in. Still working on the SDCard which has changed a bit since 1.13, along with VFS stuff. There is a useful machine_sdcard.c file in the ESP32 ports folder which I'm using as a template to try to enable the SDCard using this newer interface scheme. This variant uses ESP32 HW controllers and supports having multiple bus "slots" as different SPI buses but I'm customizing it for the P2 IO. For the P2 I want to provide 3 slots and also enable the optional power and card detect pins on more advanced setups if I can get that far. Something like this:
slot 0 - first SD card interface using fixed P58-P61 pins (SPI mode) - based on existing bit bang IO code from 1.13
slot 1 - second SD card interface on other pins (SPI mode), enable optional power control/card detection, same bit bang IO code as above on different pins
slot 2 - third SD card interface on other pins (1,4 bit SD mode) using a future more capable driver (eg. something based on @evanh work) with both power control and card detection. This requires C code not SPIN2, but can use some inline PASM2, maybe not fully in Fcache though. Or alternatively some mailbox based driver to to talk to another COG. The SD card work being done by Stephen Moraco looks good, but we don't really need another FAT32 interface, just raw block transfers would suffice as MicroPython already does the high level stuff in its own VFS layers. Also that is SPIN2 based and needs to be C/C++ unless we bundle it as a blob run on another COG. Memory management is then an issue.
In MP there are also VFS filesystem interfaces to Flash chips now (vfs_rom.c) and drivers to access the flash including Winbond 128Mbit devices we typically use with P2's. So a lot of the work is done.
It'd be good if I could try to co-ordinate the flash and SD card slot 0 use so they don't break each other. I know this is still limited/confusing so not sure how well it can work. Probably far better if you have boot flash to just put the SD card on a different interface.
@Rayman said:
@rogloh Fixed up LLVM with your files and downloaded Micropython.
It's been a moment since compiled Micropython, and that was with RISCVP2...
Do you have any tips on doing this?
LOL, it's a bit of messing about setting up tool paths etc and I'm not going to be able to hold your hand for all of that. But to get started you could try using the zipfile contents "p2-mp-minimal.zip" I posted in this post above https://forums.parallax.com/discussion/comment/1572778/#Comment_1572778
and reading what I posted on it (partial snippet reproduced below), that should get your going. You will also want those fixes for the P2LLVM toolchain so it doesn't crash with CORDIC stuff etc.
Attached is a p2-mp-minimal.zip file containing source files to apply over the files in the "minimal" ports folder in the MicroPython project tree. Or better yet you can copy these into a newly created native "p2" ports folder. Type "make run" in that folder after that with a P2 plugged in and LLVM & loadp2 tool locations setup appropriately in the Makefile.
@Rayman said:
Ok I’ll try it. I looked at that zip earlier and didn’t look like enough files there to be enough…
It's only enough for a proof-of-concept minimal build to load and run. But it won't do much as it doesn't have any special P2 pin IO or COG stuff included. I'm working on the porting of those components from our older v1.13 builds into a v1.28 build of MP. I've already done the machine_pin and machine_cpu files which compile (but are barely tested). Currently I'm trying to rewrite the SD card stuff by retargeting some ESP32 SD card framework to allow both SD and SPI interfaces to control the card. Eventually I hope to get @evanh SD code in this to get some faster SD card transfer vs the bitbang SPI. His code is already in C plus has some inline PASM2. Mostly seems like it will map over but I need to figure out an Fcache solution with P2LLVM which inherently doesn't support that right now, however I expect should be possible to include some initial loader code in the read/write routines that need to run in Fcache so that the streamer can be used, assuming this inline code addressing can be made to run at COG location 0. May need a bit of tweaking for that and add a few extra P2 instructions to P2LLVM which C doesn't yet require...
@Rayman said:
@rogloh Ok, I'm seeing now that your files are a patch to the "minimal" port, so it needs to compile a lot of files...
Attempting to compile in Windows, but looking pretty futile...
I sort of wonder if Windows can even compile MicroPython given it uses Makefiles. Without "make" present it'd be tricky. @Tubular and I actually spoke about this yesterday and he's going to ask the local MP guys here at their meetup this upcoming week about that. Perhaps they need to install the GNU make utility for this.
@Rayman said:
@rogloh Ok, I'm seeing now that your files are a patch to the "minimal" port, so it needs to compile a lot of files...
Attempting to compile in Windows, but looking pretty futile...
I sort of wonder if Windows can even compile MicroPython given it uses Makefiles. Without "make" present it'd be tricky. @Tubular and I actually spoke about this yesterday and he's going to ask the local MP guys here at their meetup this upcoming week about that. Perhaps they need to install the GNU make utility for this.
To install make on Windows, open a command line or terminal window and enter:
Did install some kind of make and that helped. Also installed some things like mkdir because works different. But the build still doesn’t work and it’s too many levels deep to figure out…
Today I was able to get the SD card on a P2-EVAL board activated while running v1.28 native P2 MicroPython using the framework I ported over from ESP32 that is intended to support multiple device instances with both SPI and SD bus interfaces. The original port v1.13 was limited to just one SDCard device. We can now use the slot parameter to setup different SPI or SD buses according to:
slot=0 being the default boot SD card in SPI mode (shared with flash) with pins fixed on P58-P61
slot=1 being another SPI interface on arbitrary pins and supports optional poweron/off and card detection and write protect pins
slot=2 being a (future) SD card interface on arbitrary pins (data on 4-pin boundary) and supports optional poweron/off and card detection and write protect pins
Here's a log of what I'm seeing when I plugged in some random (Raspi) card and booted up this customized MicroPython. It's very early days as it's only just showing life signs and I'm yet to port evanh's SD bus driver so I'm still using bit banged SPI for now. But the framework is in place to support multiple cards and buses and seems to be all compiling okay now.
@Rayman said:
Nice work. Will be good to have this going again…. What else is needed after uSD?
I already have added in the machine_cpu and machine_pin stuff so we should have Smartpin control and cog control back (needs more testing to validate). With some of the SD card back in and running the only other major missing part to link in when compared to 1.13 is the floating point math assuming that is required. Most of getting that back in should be a matter of collecting the required suite of floating point functions from various math library routines already supplied or in P2's libc/p2lib files. Once we add floating point there will be some further heap size reductions. Right now it should be possible to fit as well but I know there are other optional modules that can be built into it like regular expressions and uctypes etc. They also eat into the HUB space available. MP currently reports that the heap starts at $405a8 (just over the halfway point of HUB) and goes up to $70000 or 448kB, making ~190kB or so to eat into, but the stack doesn't need 64kB so we have a bit more room than that.
I wonder about frozen modules being stored in the flash. It'd be neat if there was a way to get things like my video driver stored in there that could be imported on demand and assigned to a cog if video apps are needed for example. These frozen modules get stored as byte code so I'm not entirely sure how to get the actual cog code in there as well, but hoping there is a way. I know I could do it with python source file and byte arrays way back when it was being tested out initially.
Another thing that could be good would be a way to sort of implement "HW" SPI/I2C buses via mailbox driver cogs that could act on behalf of the MP client and manage multiple pins separately avoiding the need for slow software bit banging. Given we still have a bunch of free cogs we may as well try to put them to good use, but we'd not want to consume too much HUB RAM.
Eg. we could have cogs like this:
the main MP cog for your application, including SD & flash access functionality
a full duplex serial cog - makes sense to include a good buffer for pasting code blocks given no flow control on the serial port
a video cog perhaps for VGA/HDMI output
external PSRAM driver cog allowing framebuffers
maybe the USBnew cog - for a local USB keyboard or other device(s) using Dupterm for achieving parallel terminal interface to the standard serial port IO
a graphics rendering cog that micropython could control to draw primitive shapes/text elements in the framebuffer (optional)
some custom IO pin control cog for "programmable DMA" i2/spi bus control for decoupling MP from bit banging IO pins
a spare cog for other stuff, eg. network comms, wifi
@Rayman said:
Nice work. Will be good to have this going again…. What else is needed after uSD?
I already have added in the machine_cpu and machine_pin stuff so we should have Smartpin control and cog control back (needs more testing to validate). With some of the SD card back in and running the only other major missing part to link in when compared to 1.13 is the floating point math assuming that is required. Most of getting that back in should be a matter of collecting the required suite of floating point functions from various math library routines already supplied or in P2's libc/p2lib files. Once we add floating point there will be some further heap size reductions. Right now it should be possible to fit as well but I know there are other optional modules that can be built into it like regular expressions and uctypes etc. They also eat into the HUB space available. MP currently reports that the heap starts at $405a8 (just over the halfway point of HUB) and goes up to $70000 or 448kB, making ~190kB or so to eat into, but the stack doesn't need 64kB so we have a bit more room than that.
I wonder about frozen modules being stored in the flash. It'd be neat if there was a way to get things like my video driver stored in there that could be imported on demand and assigned to a cog if video apps are needed for example. These frozen modules get stored as byte code so I'm not entirely sure how to get the actual cog code in there as well, but hoping there is a way. I know I could do it with python source file and byte arrays way back when it was being tested out initially.
Another thing that could be good would be a way to sort of implement "HW" SPI/I2C buses via mailbox driver cogs that could act on behalf of the MP client and manage multiple pins separately avoiding the need for slow software bit banging. Given we still have a bunch of free cogs we may as well try to put them to good use, but we'd not want to consume too much HUB RAM.
Eg. we could have cogs like this:
the main MP cog for your application, including SD & flash access functionality
a full duplex serial cog - makes sense to include a good buffer for pasting code blocks given no flow control on the serial port
a video cog perhaps for VGA/HDMI output
external PSRAM driver cog allowing framebuffers
maybe the USBnew cog - for a local USB keyboard or other device(s) using Dupterm for achieving parallel terminal interface to the standard serial port IO
a graphics rendering cog that micropython could control to draw primitive shapes/text elements in the framebuffer (optional)
some custom IO pin control cog for "programmable DMA" i2/spi bus control for decoupling MP from bit banging IO pins
a spare cog for other stuff, eg. network comms, wifi
Isn't there any chance to make available the other cores to be used in Micropython? Having 8 cores is what sets P2 apart from other processors after all. Can't the _threads module somehow be used or modified for this? I don't have any insights into how Micropython works, but I think, that for some makers the ease to use Micropython is key. If they have to recompile for other combinations of firmware, it's no go.
Cheers Christof
@"Christof Eb." said:
Isn't there any chance to make available the other cores to be used in Micropython? Having 8 cores is what sets P2 apart from other processors after all. Can't the _threads module somehow be used or modified for this?
Still looking into what possibilities MP's threading can have with what a P2 and its multiple cores can offer. It's still considered experimental at this stage but the RP2 Pico can apparently launch thread(s) on its second core. I'll need to study how that works and need to see if/how the P2 locks could be used as part of any mutexes required. The RP2 code I saw initially seems to be hard coded to just work with two cores, not necessarily something readily scaleable to more than that. If it makes sense and can work on a P2 it's probably good to have it, along with the possibilities of running independent Cogs as well (ideally from code stored in frozen modules dynamically available in the flash or SD card for example so the storage overhead is removed from the MP application itself).
I don't have any insights into how Micropython works, but I think, that for some makers the ease to use Micropython is key. If they have to recompile for other combinations of firmware, it's no go.
Cheers Christof
Possibly for some it wouldn't be software they'd want to recompile but Micropython's capabilities and included modules is something that you can fully customize for your application via settings in the mpconfigport.h file. Hub RAM is constrained on the P2 and so what goes into this build is something needing to be managed. Now who decides what to enable or disable in this key MP configuration file? IMO it would ultimately be the developer deploying an application on a microcontroller. Of course someone simply wanting to see how Python can control IO pins using MicroPython might be happy with some default build to play with but in the end if the target is some useful product/device then the build would ultimately get customized for that if the default was not sufficient.
Does pye work yet? That would be something… seem to remember it being a little flakey with large files with othe upy…
Also just noticed this himem=flash option that would I guess put static data onto the flash chip allowing much larger builds. Only problem is can’t use usd because share same pins on parallax boards…
Comments
For v1.28 I've already started porting machine_pin.c and machine_cpu.c files into P2LLVM based MicroPython and have had some success compiling them in. Still working on the SDCard which has changed a bit since 1.13, along with VFS stuff. There is a useful machine_sdcard.c file in the ESP32 ports folder which I'm using as a template to try to enable the SDCard using this newer interface scheme. This variant uses ESP32 HW controllers and supports having multiple bus "slots" as different SPI buses but I'm customizing it for the P2 IO. For the P2 I want to provide 3 slots and also enable the optional power and card detect pins on more advanced setups if I can get that far. Something like this:
slot 0 - first SD card interface using fixed P58-P61 pins (SPI mode) - based on existing bit bang IO code from 1.13
slot 1 - second SD card interface on other pins (SPI mode), enable optional power control/card detection, same bit bang IO code as above on different pins
slot 2 - third SD card interface on other pins (1,4 bit SD mode) using a future more capable driver (eg. something based on @evanh work) with both power control and card detection. This requires C code not SPIN2, but can use some inline PASM2, maybe not fully in Fcache though. Or alternatively some mailbox based driver to to talk to another COG. The SD card work being done by Stephen Moraco looks good, but we don't really need another FAT32 interface, just raw block transfers would suffice as MicroPython already does the high level stuff in its own VFS layers. Also that is SPIN2 based and needs to be C/C++ unless we bundle it as a blob run on another COG. Memory management is then an issue.
In MP there are also VFS filesystem interfaces to Flash chips now (vfs_rom.c) and drivers to access the flash including Winbond 128Mbit devices we typically use with P2's. So a lot of the work is done.
It'd be good if I could try to co-ordinate the flash and SD card slot 0 use so they don't break each other. I know this is still limited/confusing so not sure how well it can work. Probably far better if you have boot flash to just put the SD card on a different interface.
@rogloh Fixed up LLVM with your files and downloaded Micropython.
It's been a moment since compiled Micropython, and that was with RISCVP2...
Do you have any tips on doing this?
LOL, it's a bit of messing about setting up tool paths etc and I'm not going to be able to hold your hand for all of that. But to get started you could try using the zipfile contents "p2-mp-minimal.zip" I posted in this post above
https://forums.parallax.com/discussion/comment/1572778/#Comment_1572778
and reading what I posted on it (partial snippet reproduced below), that should get your going. You will also want those fixes for the P2LLVM toolchain so it doesn't crash with CORDIC stuff etc.
Ok I’ll try it. I looked at that zip earlier and didn’t look like enough files there to be enough…
It's only enough for a proof-of-concept minimal build to load and run. But it won't do much as it doesn't have any special P2 pin IO or COG stuff included. I'm working on the porting of those components from our older v1.13 builds into a v1.28 build of MP. I've already done the machine_pin and machine_cpu files which compile (but are barely tested). Currently I'm trying to rewrite the SD card stuff by retargeting some ESP32 SD card framework to allow both SD and SPI interfaces to control the card. Eventually I hope to get @evanh SD code in this to get some faster SD card transfer vs the bitbang SPI. His code is already in C plus has some inline PASM2. Mostly seems like it will map over but I need to figure out an Fcache solution with P2LLVM which inherently doesn't support that right now, however I expect should be possible to include some initial loader code in the read/write routines that need to run in Fcache so that the streamer can be used, assuming this inline code addressing can be made to run at COG location 0. May need a bit of tweaking for that and add a few extra P2 instructions to P2LLVM which C doesn't yet require...
@rogloh Ok, I'm seeing now that your files are a patch to the "minimal" port, so it needs to compile a lot of files...
Attempting to compile in Windows, but looking pretty futile...
Maybe I should try to twist the Windows port into a P2 port, but not sure that would work either...
I sort of wonder if Windows can even compile MicroPython given it uses Makefiles. Without "make" present it'd be tricky. @Tubular and I actually spoke about this yesterday and he's going to ask the local MP guys here at their meetup this upcoming week about that. Perhaps they need to install the GNU make utility for this.
To install make on Windows, open a command line or terminal window and enter:
winget install ezwinports.makeRoss.
Did install some kind of make and that helped. Also installed some things like mkdir because works different. But the build still doesn’t work and it’s too many levels deep to figure out…
Today I was able to get the SD card on a P2-EVAL board activated while running v1.28 native P2 MicroPython using the framework I ported over from ESP32 that is intended to support multiple device instances with both SPI and SD bus interfaces. The original port v1.13 was limited to just one SDCard device. We can now use the slot parameter to setup different SPI or SD buses according to:
Here's a log of what I'm seeing when I plugged in some random (Raspi) card and booted up this customized MicroPython. It's very early days as it's only just showing life signs and I'm yet to port evanh's SD bus driver so I'm still using bit banged SPI for now. But the framework is in place to support multiple cards and buses and seems to be all compiling okay now.
❯ make run ( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. ) ################################# # Native P2 MicroPython (P2LLVM)# # Heap Size: 128 kB # ################################# Heap ptr = 0x405a8, Stack ptr = 0x70014 MicroPython v1.28.0-dirty on 2026-04-20; P2-EVAL with Propeller2-cpu Type "help()" for more information. ❯ import machine, os ❯ sd=machine.SDCard(slot=0) ❯ os.mount(sd, '/sd') ❯ os.listdir() ['sd'] ❯ os.chdir('/sd') ❯ os.listdir() ['README', 'BCM271~1.DTB', 'BCM271~2.DTB', 'BCM271~3.DTB', 'BCM271~4.DTB', 'BCM271~5.DTB', 'BCM271~6.DTB', 'BCM271~7.DTB', 'BCM271~8.DTB', 'BCM283~1.DTB', 'BCM283~2.DTB', 'BCM283~3.DTB', 'BCM283~4.DTB', 'BOOTCODE.BIN', 'CMDLINE.TXT', 'CONFIG.TXT', 'FIXUP4CD.DAT', 'FIXUP4X.DAT', 'FIXUP_X.DAT', 'FIXUP_CD.DAT', 'OVERLAYS', 'START4.ELF', 'START4DB.ELF', 'START_CD.ELF', 'START_DB.ELF', 'UBOOT_~1.BIN', 'UBOOT_~2.BIN', 'UBOOT_~3.BIN', '~1.TRA', 'TRASHE~1', 'SPOTLI~1', 'FSEVEN~1', 'VMLINUZ.BAK', 'VMLINUZ', 'INITRD~1.BAK', 'INITRD.IMG', 'UBOOT_~1.BAK', 'UBOOT_~2.BAK', 'UBOOT_~3.BAK', 'BOOTSC~1.BAK', 'BOOT.SCR', 'FIXUP4~1.BAK', 'FIXUP4.DAT', 'START4~1.BAK', 'START4CD.ELF', 'FIXUP_~1.BAK', 'FIXUP_~2.BAK', 'START_X.ELF', 'START_~1.BAK', 'START.ELF', 'START4~2.BAK', 'FIXUP4~2.BAK', 'STARTE~1.BAK', 'FIXUP4DB.DAT', 'START_~2.BAK', 'FIXUP4~3.BAK', 'FIXUP_DB.DAT', 'FIXUP_~3.BAK', 'START4X.ELF', 'START4~3.BAK', 'FIXUP.DAT', 'FIXUP4~4.BAK', 'BOOTCO~1.BAK', 'START4~4.BAK', 'FIXUPD~1.BAK', 'START_~3.BAK', 'BCM283~1.BAK', 'BCM271~1.BAK', 'BCM271~2.BAK', 'BCM271~3.BAK', 'BCM271~4.BAK', 'BCM283~2.BAK', 'BCM271~5.BAK', 'BCM283~3.BAK', 'BCM271~6.BAK', 'BCM271~7.BAK', 'BCM271~8.BAK', 'BCM283~4.BAK'] ❯ sd.info() (63831015424, 512, True) <----- total size (64GB), sector size and if the card is SDHC/XC ❯ sd.present() TrueNice work. Will be good to have this going again…. What else is needed after uSD?
I already have added in the machine_cpu and machine_pin stuff so we should have Smartpin control and cog control back (needs more testing to validate). With some of the SD card back in and running the only other major missing part to link in when compared to 1.13 is the floating point math assuming that is required. Most of getting that back in should be a matter of collecting the required suite of floating point functions from various math library routines already supplied or in P2's libc/p2lib files. Once we add floating point there will be some further heap size reductions. Right now it should be possible to fit as well but I know there are other optional modules that can be built into it like regular expressions and uctypes etc. They also eat into the HUB space available. MP currently reports that the heap starts at $405a8 (just over the halfway point of HUB) and goes up to $70000 or 448kB, making ~190kB or so to eat into, but the stack doesn't need 64kB so we have a bit more room than that.
I wonder about frozen modules being stored in the flash. It'd be neat if there was a way to get things like my video driver stored in there that could be imported on demand and assigned to a cog if video apps are needed for example. These frozen modules get stored as byte code so I'm not entirely sure how to get the actual cog code in there as well, but hoping there is a way. I know I could do it with python source file and byte arrays way back when it was being tested out initially.
Another thing that could be good would be a way to sort of implement "HW" SPI/I2C buses via mailbox driver cogs that could act on behalf of the MP client and manage multiple pins separately avoiding the need for slow software bit banging. Given we still have a bunch of free cogs we may as well try to put them to good use, but we'd not want to consume too much HUB RAM.
Eg. we could have cogs like this:
Isn't there any chance to make available the other cores to be used in Micropython? Having 8 cores is what sets P2 apart from other processors after all. Can't the _threads module somehow be used or modified for this? I don't have any insights into how Micropython works, but I think, that for some makers the ease to use Micropython is key. If they have to recompile for other combinations of firmware, it's no go.
Cheers Christof
Still looking into what possibilities MP's threading can have with what a P2 and its multiple cores can offer. It's still considered experimental at this stage but the RP2 Pico can apparently launch thread(s) on its second core. I'll need to study how that works and need to see if/how the P2 locks could be used as part of any mutexes required. The RP2 code I saw initially seems to be hard coded to just work with two cores, not necessarily something readily scaleable to more than that. If it makes sense and can work on a P2 it's probably good to have it, along with the possibilities of running independent Cogs as well (ideally from code stored in frozen modules dynamically available in the flash or SD card for example so the storage overhead is removed from the MP application itself).
Possibly for some it wouldn't be software they'd want to recompile but Micropython's capabilities and included modules is something that you can fully customize for your application via settings in the mpconfigport.h file. Hub RAM is constrained on the P2 and so what goes into this build is something needing to be managed. Now who decides what to enable or disable in this key MP configuration file? IMO it would ultimately be the developer deploying an application on a microcontroller. Of course someone simply wanting to see how Python can control IO pins using MicroPython might be happy with some default build to play with but in the end if the target is some useful product/device then the build would ultimately get customized for that if the default was not sufficient.
Does pye work yet? That would be something… seem to remember it being a little flakey with large files with othe upy…
Also just noticed this himem=flash option that would I guess put static data onto the flash chip allowing much larger builds. Only problem is can’t use usd because share same pins on parallax boards…