renaming PYBFLASH mount point from PyBoard code

[dbc]

I'm working with multiple PyBoards to bring up a CAN protocol stack among other things. So I've been renaming the volume which they appear as to PYBFLASH0, PYBFLASH1,... etc.(*) Anyway... eventually it would be extremely convenient if I could read some DIP switches and set the volume name at boot time according to the DIP switches before the OS mounts the volume. Is there a way to do that?

(*) Related slightly off-topic question: I just tried to rename one from a Linux system (Ubuntu 14.04) and the file manager refuses to rename it. I was able to rename it on my Mac, no problem, from which I conclude that I must have renamed my other ones from my Mac. Any clues to the odd Linux behavior?

[dhylands]

This thread on github: https://github.com/micropython/micropython/pull/867 I proposed a module for adding calls to allow it to be renamed from python. At the time, this wasn't accepted.

More importantly, in one of the comments I showed what needs to be done under linux in order to change the name to something else (pyboard in the example). You need to unmount, but not eject the PYBFLASH volume in order to make the change.

Code: Select all

echo mtools_skip_check=1 >> ~/.mtoolsrc
sudo umount /dev/sdc1
sudo mlabel -i /dev/sdc1 -s ::pyboard

This assume that you've installed 'mtools' (i.e. sudo apt-get install mtools)

If I were to do this again, I wouldn't bother creating a whole new module and would probably make it be in the same module as the mount command (which is currently pyb.mount, but think this will become os.mount or machine.mount - I need to check the emails).

[dbc]

Yes, well, I guessed I might have to drop down to mlabel. For now I'll probably use my Mac just out of laziness...

pyb (soon to be 'machine', I gather) seems like a sensible place for a setlabel() interface. Other than exposing f_setlabel() in lib/fatfs/ff.c, what would need to happen? I'm guessing that most OS's are not expecting volumes to rename themselves unexpectedly, so I presume the interface should check to see if the PyBoard is mounted and raise an exception if it is. I assume there is a way to get a .py file executed before the PyBoard is mounted?

This isn't a problem immediately, but not so long from now I can see having 5 or 6 PyBoards all plugged into a USB hub and wanting to type 'make deploy'. Being able to set the exposed volume name from a DIP switch or jumpers will help me preserve my sanity.

[dhylands]

boot.py is normally where pyb.usb_mode is called, and that's where the USB interface gets initialized.

So, if I had a label function, I would probably call it to get the current label, and if it was equal to PYBFLASH (or different than what you wanted) then call the set label function.

We try not to take the USB link down. So if you do a soft reset (i.e. press Control-D) we don't reinitialize the USB link). So normally, boot.py only initializes the USB link the very first time its called after a hard reset.

Personally, I try to avoid using the USB Mass Storage functionality altogether and normally use pyb.usb_mode('CDC') to get a seral-only link. I've had way too many cases of my files being wiped out by one party or another since the host ahd the pyboard both think that they have exclusive access to the filesystem, but in reality they don't.

I use rshell https://github.com/dhylands/upy-shell/t ... ter/rshell now for copying files into and out of the pyboard.

[dbc]

Personally, I try to avoid using the USB Mass Storage functionality altogether and normally use pyb.usb_mode('CDC') to get a seral-only link. I've had way too many cases of my files being wiped out by one party or another since the host ahd the pyboard both think that they have exclusive access to the filesystem, but in reality they don't.

I probably haven't noticed since I am mostly only moving code down to the PyBoard, so wouldn't see the workstation wiping out files created by the PyBoard.

lsusb -v is interesting:

Code: Select all

Bus 003 Device 018: ID f055:9800  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0xf055 
  idProduct          0x9800 
  bcdDevice            2.00
  iManufacturer           1 Micro Python
  iProduct                2 Pyboard Virtual Comm Port in FS Mode
  iSerial                 3 000000000011
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
   ....

Serial number 11? Really? I am suspicious. rshell or the like is only going to be reliable in copying files to multiple, simultaneously connected Pyboards if I can get them to always come up as the same tty device, which I could do by setting a symbolic link in a udev rule that matched on the serial number. Hasn't anyone thought of building a Beowulf cluster of PyBoards? Seriously... I am headed toward the USB octopus arrangement... currently only two tentacles, but long term I need to manage this in some reasonable way. Manually naming the volumes is adequate, but creates a manual step in what is otherwise an automatic configuration set off of jumpers.

[dhylands]

Heh - mine shows as serial number 11 too.

Code: Select all

>>> pyb.unique_id()
b'9\x00\x1f\x00\x0eG242216'

The serial number is probably fixable. I'll take a look over the weekend.

[dbc]

I did a quick check of the USB spec, and serial numbers are optional for many device classes, and it is up to the device class to set the length. Reporting the cpu unique id as the serial number seems like a reasonable solution. I'm not really a USB expert, so I don't know how that figures into constructing the device descriptor.

Having CDCACM devices report a serial number is handy -- I've used it in the past with FTDI cables to make sure they always show up as the same /tty device. A UDEV rule can match on serial number, and create a symbolic link with a fixed name for that particular serial number. That way no matter what order you plug in and no matter how often you unplug and replug, you can always get to the widget at the end of the FTDI cable by the same name. It's been a while, so I'll have to go dig up the incantation again.

Of course, that is different from what caused me to start the thread originally. I'd still like to be able to read/set the volume label. Can the PyBoard answer the question: Am I mounted? After that, it seems like it would be pretty easy to expose volume label setter/getters.

[dhylands]

I posted this PR which should make the serial number actually be unique.
https://github.com/micropython/micropython/pull/1514

[dhylands]

Of course, that is different from what caused me to start the thread originally. I'd still like to be able to read/set the volume label. Can the PyBoard answer the question: Am I mounted? After that, it seems like it would be pretty easy to expose volume label setter/getters.

I don't know if there is a way to know if the host has actually mounted the pyboard's file system

What you can do is to call

Code: Select all

mode = pyb.usb_mode()

if mode == None then this means that you either set it to None, or it hasn't been initialized yet. So this could be used to determine the difference bwteen a soft reset and a hard reset.

You can also call

Code: Select all

pyb.USB_VCP().isconnected()

to determine if a host has connected to the pyboard. You can call

Code: Select all

pyb.Pin.board.USB_VBUS.value()

to detemine if power is present on the VBUS line of the USB connector.

[Damien]

You can tell if the USB mode is in MSD mode (mass storage) but I don't think there is any reliable way to detect if the volume is mounted. There might be patterns of sector read/write for a particular OS that mean mount or unmount, but that's hard to get working.

If you only need to change the label once then you could do it on the PC: when the board is plugged in, if the label is PYBFLASH, then rename it according to the MCU's unique id (which you could read from the board over serial).