Suggested enhancement to pyb.bootloader()

[blmorris]

After following the development of MicroPython since close to the beginning, I have finally summoned the courage (and all of my nearly forgotten knowledge of C) to implement a new uPy module to support I2S (Inter-IC-Sound) on the pyboard. Glad to say that I'm making steady progress and I'll be able to put some preliminary code up for review soon.
I have found the pyb.bootloader() function to be quite useful for the code-test-debug cycle, but I think that it could be improved. I do my development on a Mac; if I have a terminal program open and connected to the pyboard (I am using 'screen') and I type 'pyb.bootloader()' at the REPL, screen basically crashes and I need to clear and reset my Bash prompt. Do this enough times, and the USB system gets hung up to the point where I need to restart my machine. (And that is assuming that I also remember to unmount 'PYBFLASH' before jumping to DFU.)
The simple solution is to type something like 'pyb.delay(10000); pyb.bootloader()' to allow 10 seconds to exit screen gracefully before the DFU takes over. I finally got tired of this - sometimes I would mis-spell 'bootloader' and have to restart screen when the pyboard didn't restart.
I added this code to main.py - pyb.bootloader() is commented out here for testing:

Code: Select all

def bootload(count):
    print("Restarting in DFU boot mode in {0} seconds".format(count))
    while (count > 0):
        pyb.delay(1000)
        count -= 1
        print("{0} ".format(count), end="")
    print("\npyb.bootloader()")
    # pyb.bootloader()

# Code executing:
>>> bootload(10)
Restarting in DFU boot mode in 10 seconds
9 8 7 6 5 4 3 2 1 0 
pyb.bootloader()

Does anyone else think that it would be useful for pyb.bootloader() to have a delay option built in? I can accept the argument that it wouldn't be 'micro' enough; but I would counter that many users will mostly call bootloader() from the REPL anyway, and calling it without a delay will cause many terminal programs to exit less than gracefully.
I would like to implement this myself, but my priority right now is I2S, and if Damien likes the idea he might get it done in less time than it takes me to fire up my text editor

[dhylands]

Hey Bryan,

I wrote a simple terminal program in python. You can find it over here: https://github.com/dhylands/usb-ser-mon ... ser-mon.py

Under linux, it detects when a USB device is disconnected and then waits for it to reappear. Apparently, pyudev, one of the key modules used, is available on the Mac.

So it would be interesting to find out if this works under OSX or not.

Right now, you use Conrol-X to exit the terminal program.

[blmorris]

Thanks Dave, I'll give it a try. I now remember that you've mentioned it as a way to get around this kind of problem before; it sounds like you designed it specifically to play nice with USB TTY devices that disappear and reappear. I'll let you know if I can get it working on my Mac.

I still like my idea of allowing pyb.bootloader() to accept an option for a delay.

-Bryan

[blmorris]

Hi Dave- I can't find any clear indication that pyudev can be used on a Mac. I tried running 'sudo pip3 install pyudev' and it fails with the final message 'ImportError: No library named udev'
It appears that pyudev depends on libudev, which is a Linux library; I saw some hints that it can be made to work on OSX but I haven't found a definitive explanation for how to make that work. 'sudo port install libudev' and 'udev' simply give me 'Error: Port [lib]udev not found'

-Bryan

[dhylands]

Hi Bryan,

ok - no problem.

This was the page that I saw that mentioned OSX:
https://code.activestate.com/pypm/pyudev/

I originally though it would be linux only, and seeing OSX mentioned I thought it was worth a try.

[Damien]

Here are some tips for rapid C development with the pyboard:

• Use this command line script to enter the bootloader: https://gist.github.com/dpgeorge/c76f33d6b1144bb6c5b3
• Put pyb.usb_mode('VCP') in boot.py to prevent the MSC device from starting each reset and being auto-mounted.
• Use the REPL over a UART (see pyb.repl_uart()) so that when you do pyb.bootloader() you retain the connection (use another pyboard to do UART-USB pass through). In this case you still want to connect the USB so that DFU programming works.
• If using REPL over UART, put pyb.usb_mode(None) in boot.py to stop the device openning over and over again.

[pfalcon]

Use this command line script to enter the bootloader: https://gist.github.com/dpgeorge/c76f33d6b1144bb6c5b3

Very complicated script. For esp8266 it's as simple as "make reset", and "script" is one-liner:

Code: Select all

echo -e "\r\nimport pyb; pyb.hard_reset()\r\n" >$(PORT)

(esp8266 easy setup is opposite of pyboard's - it starts in bootloader mode, automatically runs app after flashing, and then can be put into bootloader mode by reset.)

[Damien]

The delay and flushing is precisely to get around the problems that blmorris had with the USB device disappearing while still connected to it.

As I say above, it's much easier if you use the UART REPL, then it is the same as ESP8266 (which also uses UART).

[blmorris]

Here are some tips for rapid C development with the pyboard:

So I take it you aren't so interested in my brilliant idea Given the effort that you are putting in to trimming the binary size, I'm not so surprised - it can always be implemented with a python script as I did anyway.

I'll try your suggestions, I see how they can streamline the dev process. I did need to read your list a few times to get that you are really describing two different setups:
Setup 1 - USB only: use terminal program for REPL, then exit the terminal and use your script to execute a clean jump to DFU bootloader.
Setup 2 - DFU on USB, REPL on UART: USB port of pyboard stays connected for DFU and power, but with REPL over UART there is no need to ever exit the terminal program because the (virtual) COM port never disappears. I have a USB-serial converter I could use for this purpose so as not to require my second pyboard.

I guess that I hesitated to disable mass storage (usb mode = 'VCP' or None) because getting MSC back requires a safe mode boot, wiping the filesystem. Is this correct? Not a problem if it is, I have made a habit of keeping all of my scripts on the computer and copying them to the pyboard as needed, and this dev setup could save a lot of time to make it worthwhile.

[blmorris]

Hi Bryan,

ok - no problem.

This was the page that I saw that mentioned OSX:
https://code.activestate.com/pypm/pyudev/

I originally though it would be linux only, and seeing OSX mentioned I thought it was worth a try.

Completely off-topic now, but I found the same link as you did, making me think that it might work, so I went to investigate it further. That page actually provides a lot of details if you click through. It shows builds of pyudev being available for non-linux platforms up to version 0.8, but pyudev is now up to version 0.16.1; version 0.8 seems to date from November 2010. Clicking through to the build logs, all of the more recent versions showed failed builds - the error messages were the same as I got, basically that libudev can't be found. So why did 0.8 build successfully? As far as I can tell, it was only after that version that the build process actually checked for the presence and usability of udev / libudev.

Just another way that misleading info can creep into the web to become an established reference