Micropython for P2

ersmith

Note: micropython is now included as part of FlexGUI, so the easiest way to run it is start flexgui.exe and select "Special > Run uPython on P2". But micropython does not depend in any way on FlexGUI, so you can also run it with PNut or any other download program, following the instructions below. If you want to run a newer version of micropython with an older FlexGUI, just unzip the upython.zip file somewhere and then copy all of the files into flexgui\samples\upython.

Also note that the current version can run on both revisions of the P2-ES boards and should fully support USB and VGA on both boards. Other boards (such as the P2D2) are untested, and may not work.

This is a micropython binary that can run on the P2.

Basic instructions: unzip and run upython.binary on the P2-ES board. It will communicate with the PC at 230400 baud on the standard serial pins. It will also try to talk to a VGA board on pin group 48 and USB serial host on pin group 16; the serial and USB/VGA communication are merged together, so input may come from either source and output goes to both.

If an SD card is present when upython.binary starts up, it will attempt to mount it and run "main.py" from the root directory.

See README.txt for more details.

Edit: 2020-01-08: v22, reads frequency settings from $14-$18 so loadp2 -PATCH works

Edit: 2020-01-02: v21, with input() function and some rudimentary help text

Edit: 2019-12-11: v20, now with pyb.Cpu() to allow running compiled PASM on other COGs

Edit: 2019-11-05: v19, new USB and VGA drivers which support both original and new P2-ES boards

Edit: 2019-09-16: v18, some minor performance tweaks and a fix to make the code compatible with new silicon

Edit: 2019-07-19: v17, basically the same micropython with tidied up internal code, a bit more user space, and a performance fix

Edit: 2019-07-17: v16b, same source code as v16 but compiled with a newer riscvp2 compiler for a performance boost

Edit: 2019-07-16: v16, with improved sdcard detection

Edit: 2019-07-14: v15, fixes ANSI escape sequences in the built-in VGA terminal

Edit: 2019-07-12: v14: mostly a clean up, with a few more built in modules (enough to support the pye.py editor). I've mentioned it elsewhere, but just in case: source code is now available at https://github.com/totalspectrum/micropython, using the compiler framework from https://github.com/totalspectrum/riscvp2.

Edit: 2019-06-23: v13: built with a new JIT compiler that supports compressed instructions, so it's faster and has more room for user code (we're back up to 200K for a while it was down to 144K due to all the additional built in modules). There are some debugging hooks in the emulator for I/O and other operations, which should make debugging easier and may allow for interesting hacks like @ozpropdev 's editor to be plugged in; see the README.txt for details, and/or ask here.

The SD card support is enhanced, and now micropython automatically runs "main.py" if there's an SD card plugged in when it starts up. The VGA text code is also enhanced, and allows for underline, blinking, and strikethrough as well as 256 foreground and background colors. With a VGA hooked up on pins 48 and a USB module on pins 16 the micropython interpreter can work in stand-alone mode.

Edit: 2019-06-13: v12, now with SD card FAT file system support

Edit: 2019-05-23: v11, fixes a typo in the buffered serial code that could cause characters to get stuck repeating

Edit: 2019-05-22: updated to v10, with buffered serial using another COG

Edit: 2019-05-21: updated to v9, with VGA on pins 48-55 and USB keyboard on pins 16-24 (via garryj's single COG USB keyboard/mouse driver).

Edit: 2019-05-16: updated to v8, with 192K RAM available now and some minor REPL improvements

Edit: 2019-04-04: updated to v7 with more user RAM available (128K now, was 32K before)

Edit: 2019-03-24: updated to v6, with long integer support (so all 32 bits of smartpin registers are accessible), and support for floating point and math functions

Edit: 2019-03-19: updated to v5, with improved counters and some performance tuning. There are two versions of the interpreter, upython.binary and upython_emu.binary. Both run at 160 MHz and communicate at 230_400 baud. Internally they have very different implementations; upython.binary runs on a JIT compiled RISCV emulator which should generally be much faster, but there may be some circumstances where the cache it uses starts to thrash, and then the plain emulator upython_emu.binary might be faster. Also bugs in one hopefully won't appear in the other, but you never know .

Edit: 2019-03-18: updated to v4, fixed pin reading an access to Pin(0)
Edit: 2019-03-15: updated to v3, now has a few smart pin functions implemented; docs still in README.txt

Here's a very simple MicroPython interpreter running on the P2 Eval board. Directions are in README.txt. Only one set of P2 functions are provided (in the pyb module) to turn pins on and off.

DavidZemon

?!

Details por favor? Is this actually MicroPython, or did you write your own Python interpretter? Where's your source? How did you compile it?

David Betz

It's actually MicroPython. You can probably figure out how Eric did it by looking through the forums to see what he's been working on lately. And don't stop at fastspin.

FredBlais

@ersmith do you think you can compile that : http://jerryscript.net/getting-started/ ?
I'm just curious...

David Betz

What is jerryscript?

FredBlais

JerryScript is the lightweight JavaScript engine intended to run on a very constrained devices such as microcontrollers:

Only few kilobytes of RAM available to the engine (<64 KB RAM)
Constrained ROM space for the code of the engine (<200 KB ROM)
The engine supports on-device compilation, execution and provides access to peripherals from JavaScript.

Mark_T

ersmith wrote: »

Here's a very simple MicroPython interpreter running on the P2 Eval board. Directions are in README.txt. Only one set of P2 functions are provided (in the pyb module) to turn pins on and off.

Cool. How much code space does it take up in this minimal form?

ersmith

@DavidZemon : It's MicroPython, forked from their git repo at 95213990... As to how I compiled it, I used another solution (not fastspin or p2gcc) and I'm not sure yet whether I want to support it, so at the moment I'm not ready to go into much detail, sorry. There are at least 6 ways that I know of now to compile C code for the P2. Some of them (e.g. TAZ) are obsolete, and others are obscure and haven't attracted much interest. The main contenders are definitely p2gcc and fastspin. This project was a result of playing around with one of the others to see what it could do.

@FredBlais : What, Python isn't good enough for you? Seriously though my plate is pretty full right now and I already spend more time than I should on my P2 hobby, so I'm not ready to tackle porting yet another language to the P2.

@Mark_T : It's not fully stripped down, so I don't know how low it could go, but the binary size of the current version is readily found from the .binary in the zip file I posted:

 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
     549  Defl:N      333  39% 2019-03-01 18:05 685d9bc8  README.txt
    1089  Defl:N      640  41% 2019-03-01 18:04 e94de7d8  LICENSE
  156860  Defl:N    77698  51% 2019-03-01 18:04 59ca0ee5  upython.binary
--------          -------  ---                            -------
  158498            78671  50%                            3 files

FredBlais

@ersmith Python is good enough great work by the way. I was just thinking that if MicroPython can be compiled, that open the way to a lot of possibilities on the P2 and there is a couple interesting open source projects that the P2 can be a good target for. (Jerryscript, eLua, Zephyr, PAHO MQTT-SN, OpenThread...)

Tubular

Ok Eric I had a chance to run this. Its been a long time since I've been as excited to see something working behind a terminal screen. Well done

Tubular

@ersmith what clock rate are you setting the P2 to run at? I'll run some timing comparisons

ersmith

Tubular wrote: »

@ersmith what clock rate are you setting the P2 to run at? I'll run some timing comparisons

It's at 160 MHz.

ersmith

ersmith wrote: »

Tubular wrote: »

@ersmith what clock rate are you setting the P2 to run at? I'll run some timing comparisons

It's at 160 MHz.

I should also point out that it's not really optimized at all yet, so I'm not sure how useful timing comparisons will be at this point.

potatohead

Catalina could likely compile MicroPyrhon

David Betz

potatohead wrote: »

Catalina could likely compile MicroPyrhon

That might be true but how does it help? Last I knew Catalina only targets P1 so it doesn't get us any closer to a C compiler for P2 than PropGCC does. Or are you saying Ross might be willing to come back and work on Catalina for P2?

ersmith

Here's a version with somewhat improved P2 runtime code, which should produce more sensible results for timing. There are still some optimizations I'd like to make, but I think we'll be getting close to final speed now. I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

FredBlais

ersmith wrote: »

I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

I suppose that people that want to code in Python on a mcu are more interested with the ease of use and rapid prototyping than speed. There is a lot of opportunity with the smartpins, could you add in the pyb module support for WRPIN WXPIN WYPIN and RDPIN on a selected IO?

David Betz

ersmith wrote: »

Here's a version with somewhat improved P2 runtime code, which should produce more sensible results for timing. There are still some optimizations I'd like to make, but I think we'll be getting close to final speed now. I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

How hard would it be to add P2 primitives that are coded in PASM? It might be okay for the main interpreter to be fairly slow if the P2 primitives could be fast especially if the "primitives" are actually fairly high level like PWM motor controllers rather than just bit twiddling. After all, Spin on P1 was pretty slow but still useful. Also, how hard would it be to implement the MicroPython byte code engine using XBYTE instead of interpreted RISC-V instructions?

jmg

David Betz wrote: »

How hard would it be to add P2 primitives that are coded in PASM? It might be okay for the main interpreter to be fairly slow if the P2 primitives could be fast especially if the "primitives" are actually fairly high level like PWM motor controllers rather than just bit twiddling. After all, Spin on P1 was pretty slow but still useful. Also, how hard would it be to implement the MicroPython byte code engine using XBYTE instead of interpreted RISC-V instructions?

Another pathway for more speed, would be to allow Python to co-operate with other languages which place code in other COGs ?
Any cog does not know, or care what the other code in other cogs is, or how it was compiled.

Some housekeeping stuff to allow shared mapping of data areas, and merge of code for download ? ( Debug could get more interesting... )

Tubular

ersmith wrote: »

Here's a version with somewhat improved P2 runtime code, which should produce more sensible results for timing. There are still some optimizations I'd like to make, but I think we'll be getting close to final speed now. I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

Really nice improvement there Eric, that seems about 4x faster on primitive pin toggling

Like Fred said, I doubt speed matters a whole lot at this stage. Spin2 is really going to fly (will be very hard to 'catch), and many of the micropython folk are likely to be interested in what the smartpins can do (since they can choose other micropython platforms for speed, but not the same pin flexibility).

So i agree that opening up the smartpins would be high priority to showcase P2

DavidZemon

Tubular wrote: »

ersmith wrote: »

Here's a version with somewhat improved P2 runtime code, which should produce more sensible results for timing. There are still some optimizations I'd like to make, but I think we'll be getting close to final speed now. I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

Really nice improvement there Eric, that seems about 4x faster on primitive pin toggling

Like Fred said, I doubt speed matters a whole lot at this stage. Spin2 is really going to fly (will be very hard to 'catch), and many of the micropython folk are likely to be interested in what the smartpins can do (since they can choose other micropython platforms for speed, but not the same pin flexibility).

So i agree that opening up the smartpins would be high priority to showcase P2

I think it would be really cool if we put together a list (it will probably be a BIG list) of as many different things that the smartpins can do and came up with a common, language-agnostic API that various HALs could implement. We use some simple psuedo-code (spin syntax ought to work well for this purpose) to define this API and then translating that psuedo code to a specific language would take minimal effort:

start_pwm(pin, frequency, duty): long  # Returns an error code if any parameters are invalid

and that can be translated into C and Python as:

error_t start_pwm(const uint32_t pin, const uint32_t frequency, const uint8_t duty);

def start_pwm(pin, frequency, duty)  # Raises an exception if any parameters are invalid

I bring this up here and now because I'd love to see this happen (help make it happen) rather than everyone start implementing their own unique HALs around the smart pins in the various languages that are quickly developing for the P2.

Tubular

I agree that its the right time to have a first pass at this, David (new thread!).

I think doing pseudo code in spin syntax makes a lot of sense, too.

ersmith

David Betz wrote: »

ersmith wrote: »

Here's a version with somewhat improved P2 runtime code, which should produce more sensible results for timing. There are still some optimizations I'd like to make, but I think we'll be getting close to final speed now. I have no idea if it's acceptably fast or not; I don't know what "acceptably fast" would be .

How hard would it be to add P2 primitives that are coded in PASM?

There's probably not much need; I think you could write the primitives in C, or else use coginit to run them in another COG.

As you correctly surmised, the main code is running under a Risc-V emulator, but that has very little overhead -- as long as a routine fits in the 512 byte L1 cache (best) or 4K L2 cache (next best) it'll basically run as fast as native P2 code, because in fact it is native P2 code at that point (it's JIT compiled from Risc-V to P2).

ersmith

Tubular wrote: »

Like Fred said, I doubt speed matters a whole lot at this stage. Spin2 is really going to fly (will be very hard to 'catch),

We already have a version of Spin2 on P2, of course. I assume by "Spin2" you mean Chip's interpreter, but it's not going to be as fast as fastspin or p2gcc, which are the solutions people should use if they really want fast code on P2.

But I agree with your overall sentiment, that interactive languages like python are probably better suited for development and quick testing of hardware features, so we should provide building blocks that people can use.

localroger

Working in industry I have never seen micropython used, but I have four different platforms from various manufacturers that now run Lua.

Ken Gracey

localroger wrote: »

Working in industry I have never seen micropython used, but I have four different platforms from various manufacturers that now run Lua.

Python is quickly becoming the top programming language for education. I'm really not sure about the industry uses either, but educational sales are the primary source of revenue for Parallax. For the Propeller 2, we are currently considering Spin/PASM as the primary language for commercial products and Python for education.

I'm watching this discussion closely, along with others.

Ken Gracey

Roy Eltham

I would think that the "industry" (or commercial) market would be wider with C than with Spin/PASM.
Luckily, we already have some C solutions coming together.

jmg

Ken Gracey wrote: »

.. For the Propeller 2, we are currently considering Spin/PASM as the primary language for commercial products and Python for education.

As mentioned above, if you hope to get users of any other MCU looking at P2, you will need to provide them a C pathway, because that is most likely what they will know already.
Basic is also not going away, and looks to already be running on P2, so that's another pathway to attract new users from other hardware.

Users (and their managers) will cool off very quickly, if you say they need to learn both a new language and a new MCU architecture.

Ken Gracey

jmg wrote: »

As mentioned above, if you hope to get users of any other MCU looking at P2, you will need to provide them a C pathway, because that is most likely what they will know already.
Basic is also not going away, and looks to already be running on P2, so that's another pathway to attract new users from other hardware.

Users (and their managers) will cool off very quickly, if you say they need to learn both a new language and a new MCU architecture.

Agreed. What we can actually support with examples and documentation is a serious consideration for Parallax. Spin/ASM are certainly going to be supported, along with a language for education - most likely microPython. To get microPython we will need C, so there will be a C compiler. We wouldn't be able to provide the depth of support for C like we would for Spin/ASM and microPython. We have only 30 staff, limited resources, and our educational customers keep this business productive - and have enabled all the P2 R&D.

We're watching the forum discussion and researching options as well with the intent of getting behind some efforts soon.

Ken Gracey

Roy Eltham

Ken,
I highly recommend getting behind ersmith's fastspin. It's kind of everything in one for both P1 and P2.

twm47099

Ken,
What happened to Blockly? Doesn't that use (or compile to) C?
Tom