Micropython for P2

1234568

Comments

  • cheezus wrote: »
    ersmith wrote: »
    I've thought of putting a "run micropython" button in flexgui, but I'm not sure how useful it would be. Maybe a different GUI (based on some of the other micropython runners) would be helpful though?

    This got me thinking a gui that could do a few simple utilities (such as run micropython or drop into taq-oz or cluso's debugger) might actually be handy. A serial term with a few buttons, make sure there are options for DTR/RTS and run/program eeprom and solid gold IMHO.

    The next version of FlexGUI will have menu items for these 3 things (running micropython, dropping into TAQOZ, or running the P2 ROM monitor). There's a preview version available at my Patreon page
  • David BetzDavid Betz Posts: 13,541
    edited 2019-11-08 - 02:21:00
    I just updated loadp2 and now I can't even load MicroPython at all. I get this:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -t upython.binary 
    Could not find a P2 on port /dev/cu.usbserial-P2EEQXU
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -t upython.binary 
    ERROR: got incorrect initial chksum: 
    P
    
    I see activity on the LEDs so I know I have the correct port selected. This same command line worked for me before I updated loadp2. The only problem I had was with ^S and ^Q.

    Edit: Well, it isn't completely broken. This worked:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -t -xTAQOZ
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    x
      Cold start
    ----------------------------------------------------------------
      Parallax P2  .:.:--TAQOZ--:.:.  V1.0--142          180530-0135
    ----------------------------------------------------------------
    TAQOZ# 1 2 + . 3 ok
    TAQOZ# 
    
  • evanhevanh Posts: 8,073
    edited 2019-11-08 - 02:41:22
    Newest loadp2 seems okay for me on Kubuntu 18.04.3 HWE - loadp2 version 0.029 2019-11-07

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • evanh wrote: »
    Newest loadp2 seems okay for me on Kubuntu 18.04.3 HWE - loadp2 version 0.029 2019-11-07
    Hmmm... Probably some issue with the Mac I guess.

  • This seems to work. Was there some change in the default baud rates for this version of loadp2?
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 230400 -b 230400 -t upython.binary 
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    started USB on cog 2
    MicroPython eric_v19 on 2019-11-05; P2-Eval-Board with p2-cpu
    Type "help()" for more information.
    >>> print("Hello, world!")
    Hello, world!
    >>> 
    
  • Yeah, I think it has been defaulting to 2 Mbaud download for a number of versions now.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • David BetzDavid Betz Posts: 13,541
    edited 2019-11-08 - 14:40:38
    My first working (but dumb) MicroPython program for the P2:
    import pyb
    import os
    
    def sleep(n):
        end = pyb.millis() + n
        while pyb.millis() < end:
            pass
    
    def blink(pin, n):
        p = pyb.Pin(pin)
        for i in range(n):
            p.toggle()
            sleep(500)
    
    blink(56, 10)
    

    Edit: BTW, this was written on the P2 using the pye editor. However, I used a serial connection to a PC not the VGA/keyboard option.
  • It's great once you overcome the usual baud rate problems with Micropython and loadp params etc. We suffered the same issues with my native version too. Be neat to have it somehow auto baud perhaps so beginners don't run into these issues.
  • ersmithersmith Posts: 3,523
    edited 2019-11-08 - 09:33:25
    David Betz wrote: »
    This seems to work. Was there some change in the default baud rates for this version of loadp2?

    loadp2 changed internally a while back in order to allow Linux to change baud rates -- on Linux if you change baud more than once on an open port it drops DTR which will reset the board. So if the loader baud and terminal baud are different we now open a whole new file handle. I forgot to close the old one, though. This didn't seem to bother Linux, but I'll bet it was messing things up on the Mac. I've fixed this in v029b in github, could you give that a try?
  • ersmith wrote: »
    David Betz wrote: »
    This seems to work. Was there some change in the default baud rates for this version of loadp2?

    loadp2 changed internally a while back in order to allow Linux to change baud rates -- on Linux if you change baud more than once on an open port it drops DTR which will reset the board. So if the loader baud and terminal baud are different we now open a whole new file handle. I forgot to close the old one, though. This didn't seem to bother Linux, but I'll bet it was messing things up on the Mac. I've fixed this in v029b in github, could you give that a try?
    I'm afraid that didn't help. It still doesn't seem to work with the default baud rates on the Mac. Are the defaults really 115200 and 921600 like the usage message claims? Also, I see a minor problem here. If I type "loadp2 -?" I get an error that says that "-?" is an invalid option but it is listed as a valid option in the usage message.
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -?
    Invalid option -?
    loadp2 - a loader for the propeller 2 - version 0.029b 2019-11-08
    usage: loadp2
             [ -p port ]               serial port
             [ -b baud ]               user baud rate (default is 115200)
             [ -l baud ]               loader baud rate (default is 921600)
             [ -f clkfreq ]            clock frequency (default is 80000000)
             [ -m clkmode ]            clock mode in hex (default is ffffffff)
             [ -s address ]            starting address in hex (default is 0)
             [ -t ]                    enter terminal mode after running the program
             [ -T ]                    enter PST-compatible terminal mode
             [ -v ]                    enable verbose mode
             [ -k ]                    wait for user input before exit
             [ -q ]                    quiet mode: also checks for magic escape sequence
             [ -n ]                    no reset; skip any hardware reset
             [ -? ]                    display a usage message and exit
             [ -xDEBUG ]               enter ROM debug monitor
             [ -xTAQOZ ]               enter ROM version of TAQOZ
             [ -CHIP ]                 set load mode for CHIP
             [ -FPGA ]                 set load mode for FPGA
             [ -PATCH ]                patch in clock frequency and serial parms
             [ -NOZERO ]               do not clear memory before download
             [ -SINGLE ]               set load mode for single stage
             file                      file to load
    
  • ersmithersmith Posts: 3,523
    edited 2019-11-08 - 11:40:28
    Do you know which version of loadp2 it was that worked for you? We can try to go back and see what else has changed. Some of the timeouts were shortened a bit.

    Does the -SINGLE option work?

    Does any combination of -lBAUD1 and -bBAUD2 work when BAUD1 != BAUD2? (Obviously I don't expect you to try them all :) but if -l230400 -b230400 works, does -l230400 -b115200)? Perhaps it's only the 921600 default that does not work? Does giving an explicit -l921600 help? Maybe the default is wrong for MacOS (the Linux default is 2000000, the Mac one is 921600 because it's not clear if 2000000 is supported on Mac; is it?)

    (Thanks for your help, and thanks for the -? bug report, that should be fixed now.)
  • David BetzDavid Betz Posts: 13,541
    edited 2019-11-08 - 13:44:25
    This works:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 230400 -b 230400 -t upython.binary
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    started USB on cog 2
    MicroPython eric_v19 on 2019-11-05; P2-Eval-Board with p2-cpu
    Type "help()" for more information.
    >>>
    
    But this doesn't:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 460800 -b 230400 -t upython.binary
    ERROR: got incorrect initial chksum: 
    P
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 460800 -b 230400 -t upython.binary
    Could not find a P2 on port /dev/cu.usbserial-P2EEQXU
    
  • Are loader speeds above 230400 broken? Or is it having different loader and terminal speeds that is broken? Does -l 115200 -b 230400 work?
  • ersmith wrote: »
    Are loader speeds above 230400 broken? Or is it having different loader and terminal speeds that is broken? Does -l 115200 -b 230400 work?
    Looks like you've figured it out:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 115200 -b 230400 -t upython.binary
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    started USB on cog 2
    MicroPython eric_v19 on 2019-11-05; P2-Eval-Board with p2-cpu
    Type "help()" for more information.
    >>> 
    
    So it looks like high baud rates are broken. Should I be looking into this myself since it seems to only be present on the Mac? I seem to recall that a while back another forum user said they had a fix for the Mac serial I/O functions to enable 2MB. Did they ever send it to you?

  • David Betz wrote: »
    ersmith wrote: »
    Are loader speeds above 230400 broken? Or is it having different loader and terminal speeds that is broken? Does -l 115200 -b 230400 work?
    Looks like you've figured it out:
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 -p /dev/cu.usbserial-P2EEQXU -l 115200 -b 230400 -t upython.binary
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    started USB on cog 2
    MicroPython eric_v19 on 2019-11-05; P2-Eval-Board with p2-cpu
    Type "help()" for more information.
    >>> 
    
    So it looks like high baud rates are broken. Should I be looking into this myself since it seems to only be present on the Mac? I seem to recall that a while back another forum user said they had a fix for the Mac serial I/O functions to enable 2MB. Did they ever send it to you?

    If you're able to look into it that would be great. I think I did integrate some code for supporting higher speed Mac serial I/O, but maybe I didn't do it right? Although I thought that only applied above 921600.
  • David Betz wrote: »
    So it looks like high baud rates are broken. Should I be looking into this myself since it seems to only be present on the Mac? I seem to recall that a while back another forum user said they had a fix for the Mac serial I/O functions to enable 2MB. Did they ever send it to you?
    Yes I have higher baud rates (2000000) working on the Mac (10.10) and provided some working code which I believe Eric has integrated some time back, though other serial things have also changed since. I am still using my older version with my patch here and am fearful to even upgrade as I'm in the midst of P2 stuff and don't want to break anything.
  • I just got my P2 Eval v2 board and I can now confirm that MicroPython works on the new board. The chip version detection seems to be working just fine!
  • What baud rates work for you, David?
  • dgatelydgately Posts: 1,127
    edited 2019-11-13 - 01:07:43
    This has been working for me on P2ES Rev B and upython.v19:
    loadp2 -p /dev/cu.usbserial-DN43WMDD -b 230400 -l 115200 -t -CHIP upython.binary
    OR
    loadp2 -p /dev/cu.usbserial-DN43WMDD -b 230400 -l 230400 -t -CHIP upython.binary
    

    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • David BetzDavid Betz Posts: 13,541
    edited 2019-11-13 - 01:51:32
    dgately wrote: »
    This has been working for me on P2ES Rev B and upython.v19:
    loadp2 -p /dev/cu.usbserial-DN43WMDD -b 230400 -l 115200 -t -CHIP upython.binary
    OR
    loadp2 -p /dev/cu.usbserial-DN43WMDD -b 230400 -l 230400 -t -CHIP upython.binary
    

    dgately
    I used 230400 for both. I would think you could use other baud rates for the loader but the terminal baud rate probably has to be 230400.
  • I think the current github version of loadp2 should work much better on the Mac. I fixed a bug in setting baud (which was causing rates above 230400 to fail) and also added some code to search /dev/ for serial devices, rather than relying on them being numbered consecutively (so if you just have one P2 board you shouldn't need to specify -p).
  • ersmith wrote: »
    I think the current github version of loadp2 should work much better on the Mac. I fixed a bug in setting baud (which was causing rates above 230400 to fail) and also added some code to search /dev/ for serial devices, rather than relying on them being numbered consecutively (so if you just have one P2 board you shouldn't need to specify -p).
    Thanks, Eric! I'll update and give it a try.

  • ersmith wrote: »
    I think the current github version of loadp2 should work much better on the Mac. I fixed a bug in setting baud (which was causing rates above 230400 to fail) and also added some code to search /dev/ for serial devices, rather than relying on them being numbered consecutively (so if you just have one P2 board you shouldn't need to specify -p).
    I updated my loadp2 sources and I'm still having trouble with the Mac. It seems to locate the serial port correctly because I see LEDs flashing on the board when I type the command but it still fails to identify the P2.
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 upython.binary -t
    Could not find a P2
    
    Wait, I just removed the SD card and tried again and it seems to work. I also had to see the final baud rate to 230400.
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 upython.binary -t -b 230400
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    started USB on cog 2
    MicroPython eric_v19 on 2019-11-05; P2-Eval-Board with p2-cpu
    Type "help()" for more information.
    >>> 1 + 2
    3
    >>> 
    
    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.

  • David Betz wrote: »
    ....
    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.
    https://forums.parallax.com/discussion/comment/1481699/#Comment_1481699
    Stockholm, Sweden
    I am only an egg -- Stranger in a Strange land, Robert A. Heinlein
  • David Betz wrote: »
    I updated my loadp2 sources and I'm still having trouble with the Mac. It seems to locate the serial port correctly because I see LEDs flashing on the board when I type the command but it still fails to identify the P2.
    Davids-Mac-mini:upython_v19 dbetz$ loadp2 upython.binary -t
    Could not find a P2
    
    Wait, I just removed the SD card and tried again and it seems to work. I also had to see the final baud rate to 230400.

    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.

    I think the default if an SD card is inserted is to attempt to boot from the SD card first and only then (if it fails) to try serial. This inserts a considerable delay. However, trying loadp2 again right away seems to work. I'm not sure how to navigate that. I guess we could try a longer default timeout period, at the cost of slower startup on systems with multiple USB devices inserted. Since in the latter case the user probably wants to specify an exact port anyway, so perhaps that's not so bad.

    I've checked in a revised version with longer initial timeout (to overcome the SD card delay).

    As for the final baud rate, upython.binary always sets a baud rate of 230400 for its output, so that's mandatory (the loadp2 default is 115200 baud, for historical reasons).
  • rosco_pc wrote: »
    David Betz wrote: »
    ....
    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.
    https://forums.parallax.com/discussion/comment/1481699/#Comment_1481699
    Thanks for the link. Turning on switch 3 fixed my problem. However, why didn't it fall back to serial when it didn't find anything to boot on the SD card?

  • David Betz wrote: »
    rosco_pc wrote: »
    David Betz wrote: »
    ....
    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.
    https://forums.parallax.com/discussion/comment/1481699/#Comment_1481699
    Thanks for the link. Turning on switch 3 fixed my problem. However, why didn't it fall back to serial when it didn't find anything to boot on the SD card?

    It does fall back to serial, it just takes longer to do that than loadp2 expected (loadp2 is scanning all the ports, so it only waits a limited amount of time for a response from each port). The revised version of loadp2 checked into github now has a longer per-port timeout.
  • ersmith wrote: »
    David Betz wrote: »
    rosco_pc wrote: »
    David Betz wrote: »
    ....
    Why would it fail if there is an SD card inserted? I haven't installed anything in the boot sector of my SD card.
    https://forums.parallax.com/discussion/comment/1481699/#Comment_1481699
    Thanks for the link. Turning on switch 3 fixed my problem. However, why didn't it fall back to serial when it didn't find anything to boot on the SD card?

    It does fall back to serial, it just takes longer to do that than loadp2 expected (loadp2 is scanning all the ports, so it only waits a limited amount of time for a response from each port). The revised version of loadp2 checked into github now has a longer per-port timeout.
    Thanks! That worked.

  • Unfortunately SD cards take considerable time to initialise. If you have the switches set such that SD is tried, then it can take somewhere in the 100-500ms IIRC to fall back to serial.

    Peter and I only added our code to the ROM at the last minute. Chip was understandably cautious not to impact his debugged code so our code needed to be autonomous and only invoked by the use of pull-ups and pull downs as this was the smallest change to his code. Remember, if our code was buggy it could have ruined a complete shuttle run! By keeping it almost autonomous there was negligible possibility of causing a shuttle run failure.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I don't suppose there is any way to run Python code on more than one COG at the same time?
Sign In or Register to comment.