I'm learning Micropython, (actually Circuit Python) so forgive the elementary questions.
Will this Micropython be able to use existing Circuit Python libraries? This opens up a lot of possibilities with an existing code base.
My initial impression of Micropython on the P2 was it appeared to be a very expensive way to run the platform, that is until I realized that you were replacing the necessity of a programming platform like a PC. Then it makes sense!
I'm curious about those boards I saw in the video from 3 months ago. Will these be available from Parallax or a partner?
@RetroJeff said:
I'm learning Micropython, (actually Circuit Python) so forgive the elementary questions.
Will this Micropython be able to use existing Circuit Python libraries? This opens up a lot of possibilities with an existing code base.
My initial impression of Micropython on the P2 was it appeared to be a very expensive way to run the platform, that is until I realized that you were replacing the necessity of a programming platform like a PC. Then it makes sense!
I'm curious about those boards I saw in the video from 3 months ago. Will these be available from Parallax or a partner?
RJ
Those boards are from @Tubular and I've also wondered if they'd be completed.
As for Circuit Python, TeamOz will answer that question. I believe the effort was to stay close to the hardware and original MicroPython code base produced by Damien.
I suspect running CircuitPython is possible, there's more similarities than differences, we just haven't tried it yet. Do you have a particular library you wanted us to try?
As for the P2DIP40 boards, yes these will be made available, they're about to be deployed in their first serious application and if all goes well we'll run a batch of 180
I suspect running CircuitPython is possible, there's more similarities than differences, we just haven't tried it yet. Do you have a particular library you wanted us to try?
Neopixel (neopixel.mpy) for those ws2811 strings as provided in the P2 holiday kits
As for the P2DIP40 boards, yes these will be made available, they're about to be deployed in their first serious application and if all goes well we'll run a batch of 180
I would definitely be interested when you have them for sale.
Just giving this a small bump to see what the current state of Micropython for the propeller is.
Curious if it will be able to support downloadable libraries?
@ersmith Been a while, but I'm attempting to compile this, without much luck. Not so surprising maybe...
Are there instructions for compiling the P2 version?
Is it just running make in the riscv-p2 folder?
I've tried in Windows, Mac, and Ubuntu and can't get anywhere...
One thing is that compiler complains about a lot of QSTR strings that aren't defined anywhere...
Ok, think I've finally figured it out...
Seems I had to download the code version of micropython and not the "latest release".
Something about integer definitions is wrong in latest release.
Then, had to copy the riscvp2 "latest release" into /opt (instead of wherever I wanted it).
Also, seemed to be an issue with micropython make expecting version 8.2.0 of riscvp2 instead of the 8.3.0 that I downloaded. One thing is that the folder name needs to be riscv instead of riscvp2, just made a copy for that. Then, fixed error looking for libgcc.a in a 8.2.0 folder when I had a 8.3.0 folder. Just made a copy and renamed to 8.2.0 to fix that.
Anyway, it finally compiles!
Not sure it works yet though...
Ok, doesn't work.. Get this: *** ERROR: illegal instruction at: 000252D6
Maybe I need to get the 8.2.0 version of riscvp2...
There is not really an 'official' micropython implementation for the P2. There is this one from Eric based on his riscv emulator. And then one implementation from 'team Oz' based on an old hacked GCC compiler creating native code. The parallax quick bytes for micropython is based on the later implementation and Eric's one got forgotten
@rosco_pc said:
There is not really an 'official' micropython implementation for the P2. There is this one from Eric based on his riscv emulator. And then one implementation from 'team Oz' based on an old hacked GCC compiler creating native code. The parallax quick bytes for micropython is based on the later implementation and Eric's one got forgotten
Yeah, that's the way I read it.....Criminal, I tell ya
I'm not really interested in Python (rebranded Basic) because Eric has already provided everything I could wish for in Flexprop but I see others, struggling to achieve things on other MCUs, using micropython, that would be a total breeze if they had the Prop's cogs.
Is it possible now to write Tasks in Python for P2 for more than one cog?
When I heard last of Micropython for P2, that was not possible and therefore it seemed to make absolutely no sense for P2.
@"Christof Eb." said:
Is it possible now to write Tasks in Python for P2 for more than one cog?
When I heard last of Micropython for P2, that was not possible and therefore it seemed to make absolutely no sense for P2.
I don't believe it got that far but it could have, even if it was only limited to Python cogs, it would be awesome.
So, I switched back to the "release" version of micropython and got it to compile by adding #include "stdint.h" in a few places and also a clock freq definition.
Still getting an error though...
But, added a printf to main.c and it does get there:
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
started USB on cog 2
Made it this far!
So, maybe I can figure out what is making it go off the rails...
Success! (sort of)
Commented out the uSD initialization in main() and now appears to work:
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
started USB on cog 2
Made it this far!MicroPython v1.10 on 2024-04-18; P2-Eval-Board with p2-cpu
Type "help()" for more information.
help
<function>
help()
Welcome to MicroPython!
For online docs please visit http://docs.micropython.org/
Control commands:
CTRL-A -- on a blank line, enter raw REPL mode
CTRL-B -- on a blank line, enter normal REPL mode
CTRL-C -- interrupt a running program
CTRL-D -- on a blank line, exit or do a soft reset
CTRL-E -- on a blank line, enter paste mode
For further help on a specific object, type help(obj)
Thanks @ersmith for the riscvp2 compiler fix.
Micropython compiles now and I can do os.listdir() and see files on uSD card.
So, pin writing and reading is obviously fixed.
There is something a bit strange that I'm seeing now where the FlexProp terminal (running micropython) sometimes misses keystrokes.
Not sure what is going on there... Hopefully, just a fluke...
Now, want to see about getting VGA and USB keyboard going. I think these are compiled into micropython, but don't appear to be working.
The USB adapter on Eval board does have a blinking blue light, so I think it might be trying to work at least...
Wondering if the P2 clock is not set fast enough... That might explain the serial...
Clock is good, 160 MHz, but found that the latest code in Github is better than the "latest release" version in terms of the terminal issue.
Also seems to have a few months of improvements...
@Rayman said:
Clock is good, 160 MHz, but found that the latest code in Github is better than the "latest release" version in terms of the terminal issue.
Also seems to have a few months of improvements...
Which version are you running? Is it still 1.10 or something more recent?
To make it easier to change pin assignments and such, made a platform.h file that starts with #include "Propeller.h" and then replace that include in certain files with #include "platform.h".
This binary is configured for SimpleP2 board, but is easily changed back to Eval board by editing platform.h and then recompiling.
Wish could change P2 clock in platform.h, like can with FlexProp C, but that is kind of baked into the riscvp2 compiler and looks to be a headache to change.
But, not a big deal to just recompile the toolchain with a different P2 clock freq (I hope).
Might attempt to update the core micropython files and see if the P2 port will still compile. But, maybe wait a bit on that.
Also want to see about updated the vgatext to use 720p. Probably wait a bit on that too...
One thing that looks like it would be really useful here is to implement the flash file system. Either the Parallax one or @ersmith version...
@Rayman : One way to change the clock is to bake it in to the binary by changing the words at offset $14 and $18. The riscvp2 runtime will use those values if they are non-zero, only defaulting to the 160 MHz if they were 0 to start with. It's probably a pain to change this in the .elf file, but if you produce a .binary it's simple to patch it.
Alternatively, there is an emulated system call _clkset(unsigned mode, unsigned clkfreq) (declared in propeller2.h) that will change the clock frequency at run time.
@ersmith Thanks. One issue here is with this old USB driver. It has the clock frequency baked in. Not sure newer ones are any better in this respect...
@Rayman said:
@ersmith Thanks. One issue here is with this old USB driver. It has the clock frequency baked in. Not sure newer ones are any better in this respect...
I believe this was later updated in later USB drivers from garryj and timeouts are no longer baked in statically. I have not yet tested that feature out myself however, despite having plans to do so. This is useful if a video driver for example needes to change the PLL setting on its own.
It seems you have redefined the backspace key to do the replace function and the delete key to do the backspace function. Was this intentional? Or, is this how the original is too? This is a new one on me...
Took me a minute to figure out how to quit pye without saving first. Strange that you have to edit the N that it provides and change it to y. Just hitting y then enter doesn't work...
Also think figured out that pye isn't included in micropython, it has to be on the uSD card...
Not sure if this is right, but edited a couple lines in this version to make backspace and delete keys work the way used to....
Might be using the wrong type of terminal in flexprop for this, have to check that…
@rayman : I can't remember how the keys were mapped in pye; I don't think I changed anything beyond the minimum to get it working with my terminal. At the time it was just the default Linux terminal I had, which is ANSI compatible. I hope that flexprop's ANSI terminal should work well with it, but I haven't tested (the micropython work was before I added the ANSI terminal to flexprop, IIRC).
@ersmith Any chance you could post the vgatext.spin file that is the source for the vga driver in your micropython? I attempted to use ansi.spin2 instead, but failed . Would like to take baby steps, if possible...
BTW: added this to main.c to change the color of the ansi terminal to blue background and white foreground.
Would like to use a darker blue and a vibrant yellow, but don't see how at the moment. Have to clear screen twice for some reason to get the Windows terminal to look right...
Is there a way to do things like this from within REPL?
renamed ansi.spin2 to vgatext.spin2 and can get close to making it work, but not close enough...
Instead, just editing existing vgatext.c and vgatext.h to change video modes.
Was going to do 720p, but the text is too small and you are kind of locked into a certain P2 clock freq.
So, instead thinking I like regular 640x480 VGA...
Other benefit is that terminal shows same thing as VGA...
Changed mode to 24 bit color also and can now get the colors I wanted for terminal (yellow on dark blue) with this in main.c:
//RJA Change colors?
printf("\e[37m\e[44m"); //white on blue (for PC ansi terminal)
//printf("\e[39m\e[49m"); //default
printf("\e[38;2;255;255;0m\e[48;2;0;51;102m"); //yellow on midnight blue for VGA (doesn't work on ansi terminal)
//RJA Clear screen?
printf("\e[2J\e[1;1H");
printf("\e[2J\e[1;1H");
Only problem is that the FlexProp Ansi terminal does not seem to handle the 38 and 48 escape sequences that change to 24 bit color...
The pye editor seems to work better with the FlexProp ansi terminal when rigged for 640x480.
I think that is that the terminal defaults to...
The status line is messed up on VGA monitor when in 640x480 mode though.
Thinking this old version of vgatext is missing something about jumping to bottom line or something like that.
Have to see if the new "ansi" version is better, if can figure out how to swap that in...
Comments
I'm learning Micropython, (actually Circuit Python) so forgive the elementary questions.
Will this Micropython be able to use existing Circuit Python libraries? This opens up a lot of possibilities with an existing code base.
My initial impression of Micropython on the P2 was it appeared to be a very expensive way to run the platform, that is until I realized that you were replacing the necessity of a programming platform like a PC. Then it makes sense!
I'm curious about those boards I saw in the video from 3 months ago. Will these be available from Parallax or a partner?
RJ
Those boards are from @Tubular and I've also wondered if they'd be completed.
As for Circuit Python, TeamOz will answer that question. I believe the effort was to stay close to the hardware and original MicroPython code base produced by Damien.
Ken Gracey
HI Retrojeff
I suspect running CircuitPython is possible, there's more similarities than differences, we just haven't tried it yet. Do you have a particular library you wanted us to try?
As for the P2DIP40 boards, yes these will be made available, they're about to be deployed in their first serious application and if all goes well we'll run a batch of 180
Neopixel (neopixel.mpy) for those ws2811 strings as provided in the P2 holiday kits
I would definitely be interested when you have them for sale.
RJ
Just giving this a small bump to see what the current state of Micropython for the propeller is.
Curious if it will be able to support downloadable libraries?
RJ
@ersmith Been a while, but I'm attempting to compile this, without much luck. Not so surprising maybe...
Are there instructions for compiling the P2 version?
Is it just running make in the riscv-p2 folder?
I've tried in Windows, Mac, and Ubuntu and can't get anywhere...
One thing is that compiler complains about a lot of QSTR strings that aren't defined anywhere...
Or, if possible to provide a release with VGA basepin set to 8, maybe I could skip all this...
Actually, guess I'd need to change uSD pins too...
Ok, think I've finally figured it out...
Seems I had to download the code version of micropython and not the "latest release".
Something about integer definitions is wrong in latest release.
Then, had to copy the riscvp2 "latest release" into /opt (instead of wherever I wanted it).
Also, seemed to be an issue with micropython make expecting version 8.2.0 of riscvp2 instead of the 8.3.0 that I downloaded. One thing is that the folder name needs to be riscv instead of riscvp2, just made a copy for that. Then, fixed error looking for libgcc.a in a 8.2.0 folder when I had a 8.3.0 folder. Just made a copy and renamed to 8.2.0 to fix that.
Anyway, it finally compiles!
Not sure it works yet though...
Ok, doesn't work.. Get this: *** ERROR: illegal instruction at: 000252D6
Maybe I need to get the 8.2.0 version of riscvp2...
I'm really surprised that micropython isn't crazy-popular on the P2, considering the eight cogs. Surely it would attract many more developers.
Craig
There is not really an 'official' micropython implementation for the P2. There is this one from Eric based on his riscv emulator. And then one implementation from 'team Oz' based on an old hacked GCC compiler creating native code. The parallax quick bytes for micropython is based on the later implementation and Eric's one got forgotten
Yeah, that's the way I read it.....Criminal, I tell ya
I'm not really interested in Python (rebranded Basic) because Eric has already provided everything I could wish for in Flexprop but I see others, struggling to achieve things on other MCUs, using micropython, that would be a total breeze if they had the Prop's cogs.
Is it possible now to write Tasks in Python for P2 for more than one cog?
When I heard last of Micropython for P2, that was not possible and therefore it seemed to make absolutely no sense for P2.
I don't believe it got that far but it could have, even if it was only limited to Python cogs, it would be awesome.
So, I switched back to the "release" version of micropython and got it to compile by adding #include "stdint.h" in a few places and also a clock freq definition.
Still getting an error though...
But, added a printf to main.c and it does get there:
So, maybe I can figure out what is making it go off the rails...
Success! (sort of)
Commented out the uSD initialization in main() and now appears to work:
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. ) started USB on cog 2 Made it this far!MicroPython v1.10 on 2024-04-18; P2-Eval-Board with p2-cpu Type "help()" for more information. help <function> help() Welcome to MicroPython! For online docs please visit http://docs.micropython.org/ Control commands: CTRL-A -- on a blank line, enter raw REPL mode CTRL-B -- on a blank line, enter normal REPL mode CTRL-C -- interrupt a running program CTRL-D -- on a blank line, exit or do a soft reset CTRL-E -- on a blank line, enter paste mode For further help on a specific object, type help(obj)Looks like a problem with the riscvp2 compiler... Can write to P2 pins, but read goes off the rails...
Thanks @ersmith for the riscvp2 compiler fix.
Micropython compiles now and I can do os.listdir() and see files on uSD card.
So, pin writing and reading is obviously fixed.
There is something a bit strange that I'm seeing now where the FlexProp terminal (running micropython) sometimes misses keystrokes.
Not sure what is going on there... Hopefully, just a fluke...
Now, want to see about getting VGA and USB keyboard going. I think these are compiled into micropython, but don't appear to be working.
The USB adapter on Eval board does have a blinking blue light, so I think it might be trying to work at least...
Wondering if the P2 clock is not set fast enough... That might explain the serial...
Clock is good, 160 MHz, but found that the latest code in Github is better than the "latest release" version in terms of the terminal issue.
Also seems to have a few months of improvements...
Ok, think I have it now...
Needed to add this to both uart_core.c and main.c:
This doesn't exactly feel like the right way, but it works, now have USB and VGA working...
Also, found the VGA basepin setting in uart_core.c
Which version are you running? Is it still 1.10 or something more recent?
This is the riscvp2 version from @ersmith github, totalspectrum
To make it easier to change pin assignments and such, made a platform.h file that starts with #include "Propeller.h" and then replace that include in certain files with #include "platform.h".
This binary is configured for SimpleP2 board, but is easily changed back to Eval board by editing platform.h and then recompiling.
Wish could change P2 clock in platform.h, like can with FlexProp C, but that is kind of baked into the riscvp2 compiler and looks to be a headache to change.
But, not a big deal to just recompile the toolchain with a different P2 clock freq (I hope).
Might attempt to update the core micropython files and see if the P2 port will still compile. But, maybe wait a bit on that.
Also want to see about updated the vgatext to use 720p. Probably wait a bit on that too...
One thing that looks like it would be really useful here is to implement the flash file system. Either the Parallax one or @ersmith version...
@Rayman : One way to change the clock is to bake it in to the binary by changing the words at offset $14 and $18. The riscvp2 runtime will use those values if they are non-zero, only defaulting to the 160 MHz if they were 0 to start with. It's probably a pain to change this in the .elf file, but if you produce a .binary it's simple to patch it.
Alternatively, there is an emulated system call
_clkset(unsigned mode, unsigned clkfreq)(declared in propeller2.h) that will change the clock frequency at run time.@ersmith Thanks. One issue here is with this old USB driver. It has the clock frequency baked in. Not sure newer ones are any better in this respect...
I believe this was later updated in later USB drivers from garryj and timeouts are no longer baked in statically. I have not yet tested that feature out myself however, despite having plans to do so. This is useful if a video driver for example needes to change the PLL setting on its own.
@ersmith Trying to figure out pye...
It seems you have redefined the backspace key to do the replace function and the delete key to do the backspace function. Was this intentional? Or, is this how the original is too? This is a new one on me...
Took me a minute to figure out how to quit pye without saving first. Strange that you have to edit the N that it provides and change it to y. Just hitting y then enter doesn't work...
Also think figured out that pye isn't included in micropython, it has to be on the uSD card...
Not sure if this is right, but edited a couple lines in this version to make backspace and delete keys work the way used to....
Might be using the wrong type of terminal in flexprop for this, have to check that…
@rayman : I can't remember how the keys were mapped in pye; I don't think I changed anything beyond the minimum to get it working with my terminal. At the time it was just the default Linux terminal I had, which is ANSI compatible. I hope that flexprop's ANSI terminal should work well with it, but I haven't tested (the micropython work was before I added the ANSI terminal to flexprop, IIRC).
Flexprop terminal was set to ANSI, so I don't think that's the problem.
Found a page describing this issue though:
https://wiki.sipeed.com/soft/maixpy/en/course/others/pye.html
So, it seems the change in the version of pye posted above might be a solution to handle that.
I don't know though, it's very strange...
@ersmith Any chance you could post the vgatext.spin file that is the source for the vga driver in your micropython? I attempted to use ansi.spin2 instead, but failed
. Would like to take baby steps, if possible...
BTW: added this to main.c to change the color of the ansi terminal to blue background and white foreground.
Would like to use a darker blue and a vibrant yellow, but don't see how at the moment. Have to clear screen twice for some reason to get the Windows terminal to look right...
Is there a way to do things like this from within REPL?
//RJA Change colors? printf("\e[37m\e[44m"); //RJA Clear screen? printf("\e[2J\e[1;1H"); printf("\e[2J\e[1;1H");renamed ansi.spin2 to vgatext.spin2 and can get close to making it work, but not close enough...
Instead, just editing existing vgatext.c and vgatext.h to change video modes.
Was going to do 720p, but the text is too small and you are kind of locked into a certain P2 clock freq.
So, instead thinking I like regular 640x480 VGA...
Other benefit is that terminal shows same thing as VGA...
Changed mode to 24 bit color also and can now get the colors I wanted for terminal (yellow on dark blue) with this in main.c:
//RJA Change colors? printf("\e[37m\e[44m"); //white on blue (for PC ansi terminal) //printf("\e[39m\e[49m"); //default printf("\e[38;2;255;255;0m\e[48;2;0;51;102m"); //yellow on midnight blue for VGA (doesn't work on ansi terminal) //RJA Clear screen? printf("\e[2J\e[1;1H"); printf("\e[2J\e[1;1H");Only problem is that the FlexProp Ansi terminal does not seem to handle the 38 and 48 escape sequences that change to 24 bit color...
Wikipedia (https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit) implies that this should work, but it makes both P2 and PC terminals go nuts, so doing something wrong for sure:
printf("\e[38;5;17m\e[48;5;11m");
The pye editor seems to work better with the FlexProp ansi terminal when rigged for 640x480.
I think that is that the terminal defaults to...
The status line is messed up on VGA monitor when in 640x480 mode though.
Thinking this old version of vgatext is missing something about jumping to bottom line or something like that.
Have to see if the new "ansi" version is better, if can figure out how to swap that in...