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
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:
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!
>>>
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.
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?
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
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.)
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?
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?
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.
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!
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 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 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.
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).
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?
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 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.
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.
Comments
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
Edit: Well, it isn't completely broken. This worked:
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! >>>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.
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?
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 loadDoes 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
(Thanks for your help, and thanks for the -? bug report, that should be fixed now.)
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.
dgately
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).
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.
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.