Micropython for P2

ersmithersmith Posts: 3,150
edited 2019-07-19 - 15:44:31 in Propeller 2
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.
«13456

Comments

  • ?!

    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
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • 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. :smile:
  • @ersmith do you think you can compile that : http://jerryscript.net/getting-started/ ?
    I'm just curious...
  • What is jerryscript?
  • 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.
  • 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?
  • @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
    
  • @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...)
  • 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

  • @ersmith what clock rate are you setting the P2 to run at? I'll run some timing comparisons
  • 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 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.
  • Catalina could likely compile MicroPyrhon
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • 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?

  • 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 :).
  • 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?
  • 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?
  • jmgjmg Posts: 13,614
    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... )


  • TubularTubular Posts: 3,606
    edited 2019-03-04 - 22:19:41
    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
  • 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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • TubularTubular Posts: 3,606
    edited 2019-03-04 - 23:55:08
    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.
  • 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).
  • 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.
  • Working in industry I have never seen micropython used, but I have four different platforms from various manufacturers that now run Lua.
  • 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 ElthamRoy Eltham Posts: 2,630
    edited 2019-03-05 - 04:20:22
    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.
  • jmgjmg Posts: 13,614
    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 GraceyKen Gracey Posts: 6,420
    edited 2019-03-05 - 04:47:27
    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
  • Ken,
    I highly recommend getting behind ersmith's fastspin. It's kind of everything in one for both P1 and P2.
  • Ken,
    What happened to Blockly? Doesn't that use (or compile to) C?
    Tom
Sign In or Register to comment.