Micropython for P2

1356789

Comments

  • That's a pretty clever work-around, @ozpropdev !

    I think I've fixed the long int problems I had, so hopefully you won't need to go to such extremes to access the smart-pin registers now. One side effect of my change is that the readxval() method returns an unsigned integer rather than signed (so if the pin is in repository mode "p.xval(-1)" followed by "p.readzval()" will actually return 4294967295. I'm not sure if this is a good change or not; will it cause any problems for you?

    I've also added floating point support, so you can use math.sin(), math.cos(), and the like.

    The updated interpreter is in the first post.

    Regards,
    Eric
  • Thanks Eric!
    V6 improvements working nicely. :)
    Unsigned result on readzval() seems OK to me.

    Thanks again for your efforts!
    Cheers
    Brian

    Melbourne, Australia
  • Here's a binary that will program the P2-ES Eval boards SPI FLASH with Eric's micropython V6 image.
    Make sure the "FLASH" dip switch is on before loading the binary.
    LEDS 56 and 57 will show program completion and after 10 seconds the board will reset.
    From there on micropython will boot on reset.

    In PNUT you can load the binary simply by
    dat	orgh
    
    	file	"flash_upython_v6.binary"
    
    Melbourne, Australia
  • Here's an implementation of the input() function using the already configured smartpin.
    def input(prompt):
        print(prompt,end="")
        m = ""
        key=pyb.Pin(63)
        key.read()
        while True:
            if key.read() == 1:
                q = key.readzval() >> 24
                if q == 13:
                    print()
                    return m
                elif q == 8:
                    if len(m) != 0:
                        m = m[0:len(m)-1]
                        print(chr(8)+" "+chr(8),end="")
                else:
                    m = m + chr(q)
                    print(chr(q),end="")
    
    and a esc key check that can be used to break while loops.
    def esc_pressed():
        key=pyb.Pin(63)
        if key.read() == 1:
            q = key.readzval() >> 24
            if q == 27:
                return True
        return False
    
    Melbourne, Australia
  • Hi Eric

    I seem to have hit a memory limit when running micropython.
    I've been capturing P2's hub activity and here's the result.

    The locations indicated by the "EE" markers (3b400) are the limit.
    00000: X.XXXXXXXX......XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    06200: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    0c400: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    12600: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    18800: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    1ea00: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    24c00: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    2ae00: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    31000: XXXXXXXXXXXXXXXXXXXX.............................
    37200: .................................EE..............  <- Limit $3b400
    3d400: .................................................
    43600: .................................................
    49800: .................................................
    4fa00: .................................................
    55c00: .................................................
    5be00: .................................VVVVVVVVV.VVVVVV
    62000: VVV..............................................
    68200: .................................................
    6e400: .............XX.XXXXX....X.........XXX.......XX..
    74600: ........XXXXX............XX..XX.X...XX.X.........
    7a800: ..XX.............XXXX.XX............X......X
    

    Hopefully it's simply a constant that needs tweaking. :)
    Cheers
    Brian
    Melbourne, Australia
  • Thanks for checking this Brian. Yes, it was a constant that needed tweaking; there's a predefined array that determines how much RAM is available for the garbage collector. I've increased its size from 32K to 128K and updated the binary in the first post. It can still go a bit bigger, but OTOH we're also probably not adding features to the code yet, so it's probably wise to leave some space. We could also disable some features (like floating point) if we don't think they're needed.

    Cheers,
    Eric
  • Thanks Eric! V7 working nicely. :)
    Melbourne, Australia
  • Hi Eric
    I found a few little issues with P2 Mucropython.
    I've included comparison results from a Pybaord.

    First one is the handling of infinite numbers. (Locks up)
    #PyBoard Micropython
    >>> 1e39
    inf
    
    #P2 Micropython
    >>> 1e39
    *** ERROR: illegal instruction at: 00032EF0
    

    The second one is the reporting of undefined labels.
    When you have multiple labels in a line, helps to know which one.
    #Pyboard Micropython
    >>> junk
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'junk' is not defined
    
    #P2 Mucropython
    >>> junk
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name not defined
    

    and the third one and the most important is auto indentation is not working.
    #Pyboard
    >>> def oz(x):
    ...     return x*2
    ...
    ...
    ...
    >>>
    
    #P2 Micropython
    >>> def oz(x):
    ... return x*2
    ...
    Traceback (most recent call last):
      File "<stdin>", line 2
    SyntaxError: invalid syntax
    >>>
    

    I have been running all sorts of tests on P2 Micropython and it's looking good. :)
    Any chance of getting a peek at how you got Micropython going on P2?
    Cheers
    Brian

    Melbourne, Australia
  • TubularTubular Posts: 3,728
    edited 2019-04-29 - 02:19:56
    Because OzProp's work is really interesting to watch, here's a quick video showing MicroPython digesting some new code.

    There's a full hub memory map in the top half of the screen, and a zoom in memory block in the lower half. From what I understand the yellow and cyan 'V' sections are video buffers for the two vga screens being driven in 80x30 text mode. The magenta 'C' is Eric's Risc-V micropython binary, and the green below it is MicroPython heap which grows as the code is brought in and digested

    Here's a link to the video which would be too big to post here
    https://drive.google.com/open?id=1xZ65tY-cwBPGlDr4T1Y2r9c90tEr1a6V

    And here's a still photo of the screen
    4608 x 3456 - 5M
  • Hey I think OzPropDev added some colour since the last time you showed it to me. Nice. Always handy to see live memory updates to help check memory/stack usage etc. This type of thing could come in handy as part of a more complete future debugger/monitoring system for MicroPython. How many COGs are used for it and what penalties/limits currently apply?
  • rogloh wrote: »
    How many COGs are used for it and what penalties/limits currently apply?
    Hey Roger
    The current setup uses 3 cogs. 1 each for the two vga text displays and one for the memory monitor.
    The VGA text drivers are jam packed with code,font data in cog/lut ram and generates video on the fly.
    This means their hub impact is kept to ~5k each.

    The memory monitor cog also has a full lut and has zero impact on hub memory use.
    :)

    Melbourne, Australia
  • It's ALIVE!
    Just got my first quick and dirty version of a self hosted Micropython running on P2-ES.

    Using a modified version of garryj's USB keyboard driver and a custom VGA 80*30 text driver
    interfaced to hacked version of ersmiths's Micropython .
    :)


    Melbourne, Australia
  • This sounds great Brian! So with this effort you can basically write Python code and run it fully standalone? Now that you added a console you probably want to add a filesystem to let you save it, is that next? Also is there a fast way to download Python code snippets from a UART etc or do you need to type it in? Sorry if these are basic questions, I've sort of forgotten what you had working last time I visited, and what HW/Cog access your MicroPython currently supports.
  • I'm having trouble keeping up too, Roger. When I saw it he was starting to look at the USB keyboard code, but sounds like this is now running

    Having self hosted MicroPython, multiple monitors, usb keyboard is all sounding pretty compelling.
  • Interesting, Brian. Is the USB code fairly modular? I have a VGA driver already (in both original P2 and RISC-V forms) but the USB keyboard and mouse have eluded me so far.

    I haven't had time yet to organize the micropython build environment, but it's basically a standard micropython build using an rv32im RISC-V toolchain and linked with the RISC-V emulator from my github repository (https://github.com/totalspectrum/riscvemu).
  • That's right Roger, you can type and run code without a PC terminal.
    It still supports UART terminal paste mode as well, so downloads can be done from a PC too.

    The "glue" that binds all these P2 code pieces together is a little messy.
    For example to get the USB keyboard and VGA console working with Micropython required
    some modification/patching of the existing Tx/Rx smart pins used by Micropython.

    I redirect and intercept Rx/Tx pins to allow buffering and injection of data
    into the data stream. The buffering was necessary for reliable downloads from PC @230400 baud.

    Attaching a file system gets a little trickier, but I have a few ideas that might work.

    Here's a .obj file that can be loaded onto a P2-ES Eval board.
    Place the VGA accessory board on header pins 48:55 (top right header)
    Pace USB accessory board on header pins 8:15 (lower left side)

    Melbourne, Australia
  • TubularTubular Posts: 3,728
    edited 2019-05-03 - 14:26:06
    Ok got that up and running. Bit of a false start because of an earlier micropython in the flash memory, but switched it off and now all is good.

    Wow, real hosted micropython. Ironically I cannot find a USB keyboard at home to test with, only about 5 ps/2 keyboards. Perhaps as a result of this work of yours and GarryJ those keyboards can now be retired. Its super neat being able to enter commands either via terminal or USB keyboard, though

    I notice there's a special bonus easter egg if you connect the VGA to P40~47 (debug screen). I found that by accidently connecting to the 'other' top right header

    For others following along, just copy the .obj file to _BOOT_P2.BIX on the uSD card, and switch off flash (switch 2, only applies if you have something preloaded in flash) to boot the uPython from uSD.
  • hi @ersmith

    Any chance of more than that 128kB working memory? Asking for a friend who has some neat debugging code in Python
  • (its quite close to fitting. There will be other ways to squeeze it in if 128kB is a hard limit for whatever reason)
  • I've updated the first post with a version having 192K of user memory. There's still a little bit of space left, but we also don't have USB or SD card support built in yet, so I don't know how much room we'll need for that.

    I also fixed a few of the problems @ozpropdev noticed. There's still a crash with expressions like "1e39"; strangely, doing:
      x = 1e38
      10 * x
    
    does seem to work correctly, so I'm not sure what's going wrong.
  • I have VGA code that I can plug in to upython easily enough. I don't have keyboard support though. Is there a stand-alone USB module with a reasonably simple interface that we could use to add keyboard support?

  • I think my next p2asm "lite" usb keyboard/mouse coming up should be pretty easy to incorporate. The .bin file is currently ~8KB, or less if a mouse is not needed.
    garryj
  • garryj wrote: »
    I think my next p2asm "lite" usb keyboard/mouse coming up should be pretty easy to incorporate. The .bin file is currently ~8KB, or less if a mouse is not needed.

    The Spin2 version of your driver sounds like it's exactly what I need (I can easily convert it to C with spin2cpp). I'm looking forward to it, thanks!
  • This will tie in nicely with the code editor enhancement I'm working on at the moment. :)
    Melbourne, Australia
  • ersmithersmith Posts: 3,528
    edited 2019-05-21 - 12:24:54
    I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.

    Now all that's really left to make it a comfortable stand alone environment is sd card support.

    The source code for this is checked in to my github at https://github.com/totalspectrum/micropython.
  • ersmith wrote: »
    I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.

    Now all that's really left to make it a comfortable stand alone environment is sd card support.

    The source code for this is checked in to my github at https://github.com/totalspectrum/micropython.

    Sounds good, Eric.
  • ersmith wrote: »
    I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.

    Now all that's really left to make it a comfortable stand alone environment is sd card support.

    The source code for this is checked in to my github at https://github.com/totalspectrum/micropython.
    Nice! Did you run into any issues integrating the usb keyboard object that I might be able to smooth out to make it easier?
    garryj
  • jmgjmg Posts: 14,024
    ersmith wrote: »
    and a USB keyboard (via @garryj's single COG USB driver, ported to C by me)..
    Nice.
    How does the C version compare with the Spin and p2asm versions in garryj's thread.
    Should the C version be included in that thread's first post, with notes on Size/speed/ when to choose each version ?

  • garryj wrote: »
    Nice! Did you run into any issues integrating the usb keyboard object that I might be able to smooth out to make it easier?

    Not really... the hard part was that the C translation (via spin2cpp) was producing a static array for the DAT section, but that needed to be relocated because there were references to HUB addresses. In theory loc was supposed to fix this, but loc only works if all the code is in the same code range (LUT, COG, or HUB) and obviously that wasn't the case here (and rightly so, COG and LUT are faster than HUB). So I had to add a simple relocator to spin2cpp. The only minor change I had to make to your code was to change a sequence like:
        mov htmp, ##@h_lut_end - 4
        sub htmp, ##@hlut_start
    
    into:
        mov htmp. ##(@h_lut_end-4) - @hlut_start
    
    because the relocation couldn't handle AUGS prefixes; the second form doesn't need relocation (it's a constant).

    Thanks,
    Eric
  • jmg wrote: »
    ersmith wrote: »
    and a USB keyboard (via @garryj's single COG USB driver, ported to C by me)..
    Nice.
    How does the C version compare with the Spin and p2asm versions in garryj's thread.
    Should the C version be included in that thread's first post, with notes on Size/speed/ when to choose each version ?

    The C version is a mechanical translation using spin2cpp. It's not necessary (at all) with fastspin, but I needed it because I wanted to compile the code with the Risc-V version of gcc. So it's probably not generally useful, although I suppose it might with some tweaking be usable under PropGCC or Catalina.

Sign In or Register to comment.