Micropython for P2

Rayman · 2024-09-24 17:47

@ersmith The terminal from loadp2 seems to be much better handling the escape sequences than the Flexprop terminal. Is that something that could be added as an option to Flexprop?

Rayman · 2024-09-25 16:44

Was very happy with the loadp2 terminal window for being in color and seeming to work perfectly for pye (editor).
But, was sad to see that backspace key doesn't work. Seems to just be ignored.
Not really sure how that is even possible...

But, fortunately, web search showed me that CTRL-h will do backspace.
This seems odd, but guess it's from ASCII

Hmm seems now that backspace key acts like "DEL" key should...

Electrodude · 2024-09-25 17:03

What's this loadp2 terminal window you speak of? Isn't loadp2 just a command-line program that uses your OS's terminal, or is the Windows version different?

Rayman · 2024-09-25 17:12

IDK, but it's what I get when using loadp2 to launch code.
Maybe because it's the "new console"?

Rayman · 2024-09-25 17:13

@ersmith pye seems to run perfectly when it is the first thing to run.
But, seems to crash sometimes when called later.
Not exactly sure what is going on there, but maybe related to it crashing with HIMEM=flash...

Maybe one just needs to import pye first thing... Trying that now... Yikes, it just erased the whole uSD...

Perhaps my version of pye is broke... Maybe it was me that broke it... Have to try the original again...

ersmith · 2024-09-26 00:56

@Rayman said:
@ersmith Seems that using _execve() is fine, except that uSD doesn't mount. Is there any way to fix that?

I don't know. _execve is a bit dicey for very large programs (like micropython) so I'm actually kind of surprised it works. Do you have any idea (debug messages from upython or anything similar) why the uSD isn't mounting?

ersmith · 2024-09-26 00:57

@Rayman said:
@ersmith The terminal from loadp2 seems to be much better handling the escape sequences than the Flexprop terminal. Is that something that could be added as an option to Flexprop?

loadp2 doesn't have any terminal, it just uses the one the operating system provides.

If you happen to know what escape sequences aren't being handled let me know and I can try to fix them in Flexprop.

Rayman · 2024-09-26 01:35

@ersmith well it’s primarily the foreground and background color ones.

But also, those that pye uses to redraw the screen. Those are not working right.
Especially, when trying to scroll down past the first page of a file…

Rayman · 2024-09-26 15:44

Tried the pye.py from the @ersmith github with HIMEM=flash and it doesn't work either...
So, that is still broke. Was hoping that some change that was made in my version of pye was why it was broke, but no dice...

Better than it was though. At least pye loads. Locks up shortly after loading though.

Rayman · 2024-09-26 21:30

The terminal window launched from Visual Studio Community just got a lot stranger on a very new Win 11 and VS install.
In the pye text editor, CTRL-S stopped working.
This was very odd. Right clicking on top of window showed a whole bunch of new options that weren't there before.
Somehow, was able to click the right thing and now it's back like it was and CTRL-S works again.

Another thing just noticed is that copy and past works with Micropython in this kind of terminal.
Very handy. So that, along with the escape sequences working better has me sold on this.
It's just the strangeness of backspace working like del and ctrl-h needed for backspace this is the downside so far...

Rayman · 2024-09-27 21:33

Learned enough Micropython to create this driver that talks to PASM2 driver that gets loaded into a cog.
It's definitely not as fast as the Spin2 version from whence it came, but this is fun too...

Using "main.py" option saved a ton of typing during testing. This port is rigged to execute this file at startup. Wasn't sure if it would replace the exec(open("main.py").read()) that I was having to type all the time, or if it would act more like import main. The import is no good because what it does goes out of scope when finished. Anyway, it works like "exec", perfect.

Also figured out that the terminal that loadp2 is opening, although doesn't do backspace right, does do backspace like expected with CTRL-backspace. Strange, but I'll take it.

Next, suppose have to see about the I2C touchscreen chip... Could do with machine.I2C, but think will try to stuff into the assembly driver...

One nice thing about this approach is that doesn't need a framebuffer. Still, am thinking about trying to get microgui going with this. Or, maybe better to see about getting PSRAM involved...

Tubular · 2024-09-27 22:38

Great progress, Ray

The backspace thing - i vaguely recall Ozpropdev intercepting the backspace character and replacing it with backspace-space-backspace, but that was taking advantage of a smartpin redirect in between the serial interface and micropython

rogloh · 2024-09-28 02:28

@Rayman said:
Also figured out that the terminal that loadp2 is opening, although doesn't do backspace right, does do backspace like expected with CTRL-backspace. Strange, but I'll take it.

Probably one of those DEL vs BS things, or it's treating BS as non-destructive cursor move only.

Rayman · 2024-09-28 20:22

Think have the touch version of microgui working
Was pretty easy to adapt, except for this:

@micropython.viper
def _lcopy(dest: ptr16, source: ptr8, length: int):

we don't have viper, so it's very slow.
And, the ptr16 thing doesn't work, that tripped me up...
Not sure if touch is working or not.

Think can speed up a lot by pushing to whole screen update routine into the assembly driver.
Hopefully, will be useable then.

Rayman · 2024-09-29 20:59

Ok, got touch working and got the screen update moved to assembly.
So, it is useable now.
Had to add this to mpconfigureport.h to get some of the demos to work:

//RJA for touchgui demos
#define MICROPY_PY_COLLECTIONS    (1)
#define MICROPY_PY_COLLECTIONS_ORDEREDDICT  (1)
#define MICROPY_PY_MATH_SPECIAL_FUNCTIONS   (1)

The one thing that a bit too slow is sliders. Seems they changed it at some point from moving the slider to where it is being touched, to slowly moving toward where being touched.
If this Micropython were about 5X faster would be OK, but a bit too slow as is. So, if using sliders would probably change the code back to moving to where touched.

Rayman · 2024-09-29 21:01

In general, seems this Micropython must be slow, compared to others. But, we have the advantage of spare cogs.
So, for gui type work would probably be better to push more to assembly.
But, this is OK. For a larger screen though, would definitely need more in assembly.

Genetix · 2025-09-05 04:00

Where I work Python scripts are used for testing and mainly communicate with USB devices.

Is there anything that microPython won't do?

rogloh · 2026-04-08 03:41

Sorry to resurrect an old thread but I just sort of got MicroPython working with P2LLVM (with quite some hacks to make it finally build). I just ran a benchmark of that factorial test and obtained the following result which I thought I'd share. I also included this test build in the zip file - you'll need to load it with some extra loadp2 arguments to patch in the frequency/baud rate in order to get it to work.

This initial native P2 image is likely really rough and will probably crash easily as I now don't trust P2LLVM is doing the correct thing for all functions. Right now it also directly accesses the UART without buffering so can get overloaded if you paste in code at high speed. Also the heap is pretty small - might be able to increase it a bit in time. But if we can get Nikita's P2LLVM compiler running reliably there's a chance for more recent MicroPython versions to be compiled - and not necessarily on my custom home grown setup with p2gcc modifications and other scripts etc.

❯ ~/Applications/loadp2/build/loadp2  -t -f 160000000 -b 115200 -PATCH build/python.elf
( Entering terminal mode.  Press Ctrl-] or Ctrl-Z to exit. )
#########################
# Native P2 MicroPython #
#   Heap Size:  96 kB   #
#########################
Heap ptr = 0x56d44, Stack ptr = 0x7a014
MicroPython v1.13-9-gaae68e126-dirty on 2026-04-08; P2 BOARD with Propeller2 P2X8C4M64P
Type "help()" for more information.
 import utime
 def fact(n):
...     if n==0:
...         return 1
...     else:
...         return n*fact(n-1)
... 
 def perfTest4():
...     millis=utime.ticks_ms
...     endTime=millis()+10000
...     count=0
...     while millis() < endTime:
...         count +=1
...         fact(10)
...     print("Count: ", count)
... 
 perfTest4()
Count:  16162

To get to this point I've had to fix/workaround a number of issues including:

missing setjmp/longjmp implementation in C library - I created one for LLVM
some math library routines missing
collision of function names during linking if stdio is included by other library routines (micropython uses its own)
various Makefile tweaks
resolve broken P2LLVM things - cordic, stack frame alignment, modulus operations
memmove/memcpy crashing with zero argument lengths passed by MP
vfs from MP instead of from C library
removal of APIs that include stdio
use fatfs from MP instead of from C library
updating inline assembly for some routines
alter libc.a inclusion, linker flag changes and script

Original result here:
https://forums.parallax.com/discussion/comment/1473939/#Comment_1473939

Rayman · 2026-04-08 06:08

This is great! I’ve got a long list of things that need a simple C++ compiler. Well, simpler than Risc5p2. That works but is many layers deep and hard for me in Linux …

Sounds like this works on PC?

Rayman · 2026-04-08 06:13

This is probably an old version of micro python right ? There have been quite a few changes…

rogloh · 2026-04-08 12:20

@Rayman said:
This is great! I’ve got a long list of things that need a simple C++ compiler. Well, simpler than Risc5p2. That works but is many layers deep and hard for me in Linux …

Sounds like this works on PC?

I did it using a Mac M2.Pro based system but in theory if you can get the github projects and can compile P2LLVM for windows maybe it could work. Not sure if Nikita used a Mac as well (I think so). Linux might be a better option if you don't have a Mac already.

@Rayman said:
This is probably an old version of micro python right ? There have been quite a few changes…

Yeah I used 1.13 which we had built before with p2gcc and I already had the Makefile modified for that but am hoping newer MP versions might also now build with some further effort - they are up to 1.28 and previewing version 1.29 now. I'm still worried about the alignment of local variables on the stack with P2LLVM though - my current "fix" in MP was just to hard code some additional dummy local variables to re-align allocated stack memory to a multiple of 4 bytes for a couple of functions that would crash without that. It's obviously not the actual fix and needs to be resolved in the compiler. That's the only known problem I know about at the moment that likely needs some new P2LLVM code change and I'll try to see where that might be done in the code. My other P2LLVM fixes for the CORDIC seem to work okay (for now).

Rayman · 2026-04-08 13:33

Looks like used clang compiler in visual studio for windows last time to compile…

Rayman · 2026-04-08 15:49

Should this be in it's own thread? Seems like this thread is about the RISC-V P2 version, right?

Think there's another thread about "native" P2 micropython...

rogloh · 2026-04-08 23:41

@Rayman said:
Should this be in it's own thread? Seems like this thread is about the RISC-V P2 version, right?

Think there's another thread about "native" P2 micropython...

Not as far as I know. Both Eric's and native P2 Micropython (p2gcc based) are discussed here historically in this thread, but it's been ages and maybe there are extra threads now...

Also I'm not really planning to post all that much more on this right now until/unless things develop more or there are further breakthroughs. Maybe then it can or should be another thread. But it's probably good to keep this all together for now so people reading through learn what's potentially possible there with respect to running MP on P2.

Rayman · 2026-04-09 13:18

Ok guess fine here then. As said in other post, might try the @ersmith version with LLVM on Windows. Might not work but would be awesome if did….

That Micropython is more up to date I think . They’ve renamed everything to remove the “u” so has same syntax as regular micropython. Also a lot other things got moved around….

rogloh · 2026-04-11 06:48

Using P2LLVM with the latest released MP v1.28:

❯ make clean
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
rm -rf build 
❯ make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
mkdir -p build/genhdr
GEN build/genhdr/mpversion.h
GEN build/genhdr/qstr.i.last
GEN build/genhdr/qstr.split
GEN build/genhdr/qstrdefs.collected.h
QSTR updated
GEN build/genhdr/qstrdefs.generated.h
GEN build/genhdr/moduledefs.split
GEN build/genhdr/moduledefs.collected
Module registrations updated
GEN build/genhdr/moduledefs.h
GEN build/genhdr/root_pointers.split
GEN build/genhdr/root_pointers.collected
Root pointer registrations updated
GEN build/genhdr/root_pointers.h
mkdir -p build/build
mkdir -p build/py
mkdir -p build/shared/readline
mkdir -p build/shared/runtime
Compiling ../../py/mpstate.c
Compiling ../../py/nlr.c
Compiling ../../py/nlrx86.c
Compiling ../../py/nlrx64.c
Compiling ../../py/nlrthumb.c
Compiling ../../py/nlraarch64.c
Compiling ../../py/nlrmips.c
Compiling ../../py/nlrpowerpc.c
Compiling ../../py/nlrxtensa.c
Compiling ../../py/nlrrv32.c
Compiling ../../py/nlrrv64.c
Compiling ../../py/nlrsetjmp.c
Compiling ../../py/malloc.c
Compiling ../../py/gc.c
Compiling ../../py/pystack.c
Compiling ../../py/qstr.c
Compiling ../../py/vstr.c
Compiling ../../py/mpprint.c
Compiling ../../py/unicode.c
Compiling ../../py/mpz.c
Compiling ../../py/reader.c
Compiling ../../py/lexer.c
Compiling ../../py/parse.c
Compiling ../../py/scope.c
Compiling ../../py/compile.c
Compiling ../../py/emitcommon.c
Compiling ../../py/emitbc.c
Compiling ../../py/asmbase.c
Compiling ../../py/asmx64.c
Compiling ../../py/emitnx64.c
Compiling ../../py/asmx86.c
Compiling ../../py/emitnx86.c
Compiling ../../py/asmthumb.c
Compiling ../../py/emitnthumb.c
Compiling ../../py/emitinlinethumb.c
Compiling ../../py/asmarm.c
Compiling ../../py/emitnarm.c
Compiling ../../py/asmxtensa.c
Compiling ../../py/emitnxtensa.c
Compiling ../../py/emitinlinextensa.c
Compiling ../../py/emitnxtensawin.c
Compiling ../../py/asmrv32.c
Compiling ../../py/emitnrv32.c
Compiling ../../py/emitinlinerv32.c
Compiling ../../py/emitndebug.c
Compiling ../../py/formatfloat.c
Compiling ../../py/parsenumbase.c
Compiling ../../py/parsenum.c
Compiling ../../py/emitglue.c
Compiling ../../py/persistentcode.c
Compiling ../../py/runtime.c
Compiling ../../py/runtime_utils.c
Compiling ../../py/scheduler.c
Compiling ../../py/nativeglue.c
Compiling ../../py/pairheap.c
Compiling ../../py/ringbuf.c
Compiling ../../py/cstack.c
Compiling ../../py/stackctrl.c
Compiling ../../py/argcheck.c
Compiling ../../py/warning.c
Compiling ../../py/profile.c
Compiling ../../py/map.c
Compiling ../../py/obj.c
Compiling ../../py/objarray.c
Compiling ../../py/objattrtuple.c
Compiling ../../py/objbool.c
Compiling ../../py/objboundmeth.c
Compiling ../../py/objcell.c
Compiling ../../py/objclosure.c
Compiling ../../py/objcode.c
Compiling ../../py/objcomplex.c
Compiling ../../py/objdeque.c
Compiling ../../py/objdict.c
Compiling ../../py/objenumerate.c
Compiling ../../py/objexcept.c
Compiling ../../py/objfilter.c
Compiling ../../py/objfloat.c
Compiling ../../py/objfun.c
Compiling ../../py/objgenerator.c
Compiling ../../py/objgetitemiter.c
Compiling ../../py/objint.c
Compiling ../../py/objint_longlong.c
Compiling ../../py/objint_mpz.c
Compiling ../../py/objlist.c
Compiling ../../py/objmap.c
Compiling ../../py/objmodule.c
Compiling ../../py/objobject.c
Compiling ../../py/objpolyiter.c
Compiling ../../py/objproperty.c
Compiling ../../py/objnone.c
Compiling ../../py/objnamedtuple.c
Compiling ../../py/objrange.c
Compiling ../../py/objreversed.c
Compiling ../../py/objringio.c
Compiling ../../py/objset.c
Compiling ../../py/objsingleton.c
Compiling ../../py/objslice.c
Compiling ../../py/objstr.c
Compiling ../../py/objstrunicode.c
Compiling ../../py/objstringio.c
Compiling ../../py/objtemplate.c
Compiling ../../py/objtuple.c
Compiling ../../py/objtype.c
Compiling ../../py/objzip.c
Compiling ../../py/opmethods.c
Compiling ../../py/sequence.c
Compiling ../../py/stream.c
Compiling ../../py/binary.c
Compiling ../../py/builtinimport.c
Compiling ../../py/builtinevex.c
Compiling ../../py/builtinhelp.c
Compiling ../../py/modarray.c
Compiling ../../py/modbuiltins.c
Compiling ../../py/modcollections.c
Compiling ../../py/modgc.c
Compiling ../../py/modio.c
Compiling ../../py/modmath.c
Compiling ../../py/modcmath.c
Compiling ../../py/modmicropython.c
Compiling ../../py/modstring.c
Compiling ../../py/modstruct.c
Compiling ../../py/modsys.c
Compiling ../../py/moderrno.c
Compiling ../../py/modthread.c
Compiling ../../py/modweakref.c
Compiling ../../py/vm.c
Compiling ../../py/bc.c
Compiling ../../py/showbc.c
Compiling ../../py/repl.c
Compiling ../../py/smallint.c
Compiling ../../py/frozenmod.c
Compiling main2.c
Compiling uart_core.c
Compiling ../../shared/readline/readline.c
Compiling ../../shared/runtime/pyexec.c
Compiling ../../shared/runtime/stdout_helpers.c
MISC freezing bytecode
Compiling build/_frozen_mpy.c
LINK build/firmware.elf
clang version 14.0.0 (https://github.com/ne75/llvm-project.git 72a9bb1ef2656d9953d1f41a8196d425ff2ab0b1)
Target: p2
Thread model: posix
InstalledDir: /Users/roger/Applications/p2llvm/bin
 "/Users/roger/Applications/p2llvm/bin/ld.lld" --gc-sections -L/Users/roger/Applications/p2llvm/libc/lib -L/Users/roger/Applications/p2llvm/libp2/lib --no-whole-archive build/py/mpstate.o build/py/nlr.o build/py/nlrx86.o build/py/nlrx64.o build/py/nlrthumb.o build/py/nlraarch64.o build/py/nlrmips.o build/py/nlrpowerpc.o build/py/nlrxtensa.o build/py/nlrrv32.o build/py/nlrrv64.o build/py/nlrsetjmp.o build/py/malloc.o build/py/gc.o build/py/pystack.o build/py/qstr.o build/py/vstr.o build/py/mpprint.o build/py/unicode.o build/py/mpz.o build/py/reader.o build/py/lexer.o build/py/parse.o build/py/scope.o build/py/compile.o build/py/emitcommon.o build/py/emitbc.o build/py/asmbase.o build/py/asmx64.o build/py/emitnx64.o build/py/asmx86.o build/py/emitnx86.o build/py/asmthumb.o build/py/emitnthumb.o build/py/emitinlinethumb.o build/py/asmarm.o build/py/emitnarm.o build/py/asmxtensa.o build/py/emitnxtensa.o build/py/emitinlinextensa.o build/py/emitnxtensawin.o build/py/asmrv32.o build/py/emitnrv32.o build/py/emitinlinerv32.o build/py/emitndebug.o build/py/formatfloat.o build/py/parsenumbase.o build/py/parsenum.o build/py/emitglue.o build/py/persistentcode.o build/py/runtime.o build/py/runtime_utils.o build/py/scheduler.o build/py/nativeglue.o build/py/pairheap.o build/py/ringbuf.o build/py/cstack.o build/py/stackctrl.o build/py/argcheck.o build/py/warning.o build/py/profile.o build/py/map.o build/py/obj.o build/py/objarray.o build/py/objattrtuple.o build/py/objbool.o build/py/objboundmeth.o build/py/objcell.o build/py/objclosure.o build/py/objcode.o build/py/objcomplex.o build/py/objdeque.o build/py/objdict.o build/py/objenumerate.o build/py/objexcept.o build/py/objfilter.o build/py/objfloat.o build/py/objfun.o build/py/objgenerator.o build/py/objgetitemiter.o build/py/objint.o build/py/objint_longlong.o build/py/objint_mpz.o build/py/objlist.o build/py/objmap.o build/py/objmodule.o build/py/objobject.o build/py/objpolyiter.o build/py/objproperty.o build/py/objnone.o build/py/objnamedtuple.o build/py/objrange.o build/py/objreversed.o build/py/objringio.o build/py/objset.o build/py/objsingleton.o build/py/objslice.o build/py/objstr.o build/py/objstrunicode.o build/py/objstringio.o build/py/objtemplate.o build/py/objtuple.o build/py/objtype.o build/py/objzip.o build/py/opmethods.o build/py/sequence.o build/py/stream.o build/py/binary.o build/py/builtinimport.o build/py/builtinevex.o build/py/builtinhelp.o build/py/modarray.o build/py/modbuiltins.o build/py/modcollections.o build/py/modgc.o build/py/modio.o build/py/modmath.o build/py/modcmath.o build/py/modmicropython.o build/py/modstring.o build/py/modstruct.o build/py/modsys.o build/py/moderrno.o build/py/modthread.o build/py/modweakref.o build/py/vm.o build/py/bc.o build/py/showbc.o build/py/repl.o build/py/smallint.o build/py/frozenmod.o build/main2.o build/uart_core.o build/shared/readline/readline.o build/shared/runtime/pyexec.o build/shared/runtime/stdout_helpers.o build/build/_frozen_mpy.o -o build/firmware.elf -L/lib/ -L/lib/ --whole-archive -lc -lp2 -Tp2.ld -L/Users/roger/Applications/p2llvm/bin/..
   text    data     bss     dec     hex filename
 179788     232   40336  220356   35cc4 build/firmware.elf
Create build/firmware.bin

Results in this:

❯ make run
/Users/roger/Applications/loadp2/build/loadp2 -t -PATCH -f 160000000 -b 115200 build/firmware.bin
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
MicroPython v1.28.0-dirty on 2026-04-11; P2-EVAL with Propeller2-cpu
>>> x=2
>>> y=3
>>> print(x*y)
6
>>>
Oh yeah
From a MicroPython codebase perpective only minor tweaks are needed now for obtaining a "minimal" build with no additional capabilities or modules. Only one common MP source file was altered to get the code to compile and I think it's probably a MP oversight anyway where they forgot to use their own defined seek constants and sucked in a library version instead while not including the library file by default. This is the change required for that file (just prefix SEEK_xxx defines with MP_):

diff --git a/py/stream.c b/py/stream.c
index 19c5cbb2d..4d71964e7 100644
--- a/py/stream.c
+++ b/py/stream.c
@@ -461,13 +461,13 @@ MP_DEFINE_CONST_FUN_OBJ_VAR_BETWEEN(mp_stream___exit___obj, 4, 4, mp_stream___ex
 static mp_obj_t stream_seek(size_t n_args, const mp_obj_t *args) {
     // TODO: Could be uint64
     mp_off_t offset = mp_obj_get_int(args[1]);
-    int whence = SEEK_SET;
+    int whence = MP_SEEK_SET;
     if (n_args == 3) {
         whence = mp_obj_get_int(args[2]);
     }

     // In POSIX, it's error to seek before end of stream, we enforce it here.
-    if (whence == SEEK_SET && offset < 0) {
+    if (whence == MP_SEEK_SET && offset < 0) {
         mp_raise_OSError(MP_EINVAL);
     }

@@ -484,7 +484,7 @@ MP_DEFINE_CONST_FUN_OBJ_VAR_BETWEEN(mp_stream_seek_obj, 2, 3, stream_seek);

 static mp_obj_t stream_tell(mp_obj_t self) {
     mp_obj_t offset = MP_OBJ_NEW_SMALL_INT(0);
-    mp_obj_t whence = MP_OBJ_NEW_SMALL_INT(SEEK_CUR);
+    mp_obj_t whence = MP_OBJ_NEW_SMALL_INT(MP_SEEK_CUR);
     const mp_obj_t args[3] = {self, offset, whence};
     return stream_seek(3, args);
 }

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.

However you will also need a P2LLVM toolchain built with fixes applied for a couple of cordic and stack bugs I mentioned in the P2LLVM thread in the C/C++ category and any other recent P2LLVM related posts I may have made. I plan to document it more with all the changes but that's still somewhat TBD as I probably first need to back out code to find the changes that were unnecessary for this build. I did also need a setjmp/longjmp implementation in the stdlib library which I created for the P2 along with some other customizations to the library inclusions to avoid collisions with locally used function names. So unless you repeat what I went through it might be tricky to get this version of MP to work immediately out of the box unless you are handy at fixing linker errors and that sort of thing.

UPDATE: included my LLVM fixes in another zip file called llvmfixes.zip. Apply these changes to the "llvm-project" sub-project source code after obtaining the P2LLVM project from https://github.com/ne75/p2llvm/tree/master (before building the toolchain and libraries).

UPDATE2: included my P2LLVM library fixes in the p2llvm-fixes.zip. Apply these changes to the p2llvm project source code (before building the libraries). These contain the extra files and tweaks needed for the MP build to work. You will still need to install as described in the README.md file written by Nikita. You may need to apply these file changes a second time if the initial --configure step driving CMake overwrites the CMakeLists.txt file changes in this zip file (not sure if it does or not, CMake still confuses me).

With all these changes posted here now, you should be able to reproduce my result and begin to build a minimal image based off of a very recent MicroPython v1.28. Obviously there are other things needed if you want the extra P2 specific functionality like the Smartpin IO and Cog control etc we had before this, but that can be brought in over time.

Tubular · 2026-04-11 10:00

Ok, now thats really very, very exciting.

1.28!!

rogloh · 2026-04-11 12:35

@Tubular said:
Ok, now thats really very, very exciting.

1.28!!

Yeah it's a pleasing result. We only ever really needed an up to date GCC compatible C compiler for the P2 for it to be achievable using native P2 code. I'll see how easy it is to add the other capabilities Eric and I had developed before into this build. Some of the SD card stuff may be different now but the P2 specific APIs should hopefully still be portable.

Wuerfel_21 · 2026-04-11 12:56

@rogloh said:
CMake still confuses me

I don't think anyone understands or likes CMake ;P
Yet somehow it's everywhere. I guess basic GNU make is too limited and everything slightly less annoying hasn't caught on as much.

You might want to push your LLVM changes into a git repository, that'll make it easier to work with.

rogloh · 2026-04-11 13:05

@Wuerfel_21 said:

@rogloh said:
CMake still confuses me

I don't think anyone understands or likes CMake ;P

Hah, all voodoo stuff. Just tested it out, the --configure option in build.py didn't seem to rewrite the CMakeLists.txt files so we should be able to apply my changes before the whole configure and build/install steps.

Yet somehow it's everywhere. I guess basic GNU make is too limited and everything slightly less annoying hasn't caught on as much.

Probably. Or just NIH syndrome.

You might want to push your LLVM changes into a git repository, that'll make it easier to work with.

Still thinking about doing that yeah. Might have to fork from Nikita's repo which is a fork from the LLVM project and then add my changes on top. Pity it's not mainlined yet.

One problem I have with all this is that the changes I put into p2llvm-fixes.zip are really just customizing what goes into the libraries and are only needed for building MP (in fact mostly for full v1.13 not the more recent minimal v1.28). Not so much for P2LLVM in general. The other changes in llvmfixes.zip actually fix some compiler bugs/limitations for the P2 implementation and do belong in the fork or (could just become pull requests for @n_ermosh to apply if still maintaining it).

Micropython for P2

Comments