@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?
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...
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?
@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...
@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?
@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.
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.
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...
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...
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
@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.
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:
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.
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.
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.
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 …
@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).
Comments
@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?
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...
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?
IDK, but it's what I get when using loadp2 to launch code.
Maybe because it's the "new console"?
@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...
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?
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.
@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…
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.
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...
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 likeimport 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...
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
Probably one of those DEL vs BS things, or it's treating BS as non-destructive cursor move only.
Think have the touch version of microgui working
Was pretty easy to adapt, except for this:
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.
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:
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.
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.
Where I work Python scripts are used for testing and mainly communicate with USB devices.
Is there anything that microPython won't do?
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: 16162To get to this point I've had to fix/workaround a number of issues including:
Original result here:
https://forums.parallax.com/discussion/comment/1473939/#Comment_1473939
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?
This is probably an old version of micro python right ? There have been quite a few changes…
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.
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).
Looks like used clang compiler in visual studio for windows last time to compile…
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...