Method to list connected Glasgow boards #208

attie · 2020-09-25T17:10:56Z

This patchset addresses #206.

I have broken GlasgowHardwareDevice.__init__() in half, to better support acquiring a list of Glasgow boards, and maintaining the existing firmware loading and filtering of USB devices.

The output of glasgow list defaults to a text-based table - I've implemented a very simplistic table using only str.format() to avoid adding any dependencies.

If the user wishes, glasgow list -j can be used to get output as JSON instead, which can then in turn be paired with tools like jq to perform more complex filtering.

Examples:

venv:$ glasgow list
Serial              : Rev   : USB Path
------------------- : ----- : --------
C1-20200923T174926Z : revC1 : 1-4.4.4
C1-20200923T190627Z : revC1 : 1-2

venv:$ glasgow list -j
[{"serial": "C1-20200923T174926Z", "revision": "C1", "usb_path": "1-4.4.4"}, {"serial": "C1-20200923T190627Z", "revision": "C1", "usb_path": "1-2"}]

venv:$ glasgow list -j | jq -r '.[] | select(.usb_path == "1-2") | .serial'
C1-20200923T190627Z

whitequark

I think this is a lot more complicated than it needs to be.

The class method on GlasgowHardwareDevice should return the list of serials, since that's what you feed back to the constructor.
Definitely no libusb calls should be involved in the caller--we don't want to be tied to USB forever, and also with WinUSB it's easy to "lock yourself out" of a device because handles have exclusive access there.
The revision is included in the serial--in fact that's how the firmware knows the revision in first place.
I find it hard to imagine many cases when the USB topology is helpful--if you lost a device it'd be nice to have a "blink a LED" functionality instead of requiring you to remember port numbers on hubs.
Once you get rid of those, ditch the table header (when not printing to a TTY) and you don't need JSON; head works just fine for simple CLI usage. Anything more complicated than that can be scripted through Python, which is why (1) and (2) are important.

attie · 2020-09-29T19:52:40Z

Thanks for the feedback.

Sounds reasonable.
Yes, good point - especially with the future revisions and technologies in mind.
Indeed - that was a tenuous one, but I decided that the filtering I was planning (e.g: with jq) may appreciate direct string comparisons over string manipulation. Happy to drop.
This one was for a fairly specific use-case that I have in mind - where the USB topology will be fairly persistent over time, but the specific Glasgow in use may not be (either due to replacement of a Glasgow, or duplication of a physical setup).
- I'd propose perhaps including a -p flag to also include this information in the output.
- -p would provide the board's "path" - USB path (e.g: usb://1-2), Ethernet path (e.g: tcp://192.168.0.100:1234), whatever else may be employed in the future...
- If that's incompatible with your plans, then no worries - I'll drop it.
Sure, no problem

I think the only contentious point is #4, so I'll think about putting it in a separate patch, and we can drop it if you don't like the idea.

whitequark · 2020-09-29T20:35:41Z

-p would provide the board's "path" - USB path (e.g: usb://1-2), Ethernet path (e.g: tcp://192.168.0.100:1234), whatever else may be employed in the future...

I'm not sure if this is the UI I want to have. For simple cases, like (host-local) USB and (segment-local) Ethernet, the serial number alone is sufficient (USB can be enumerated, and IPv6 IID can be a part of the serial or you could use broadcasts). For more complex cases, if I bother to use something more meaningful and persistent than serials, I try to refer to boards by aliases (denoting their functions), which generally stays the same, rather than their geographical or network address, which generally changes for benign reasons (DHCP allocated a new IP, hub plugged in a different port, etc). Here's my writeup on setting up udev to assign aliases to USB-serial converters that can only be distinguished geographically.

So I'm thinking that this kind of advanced setup (many Glasgow boards and abstraction over specific hardware means you're dropping hundreds of dollars on hardware alone, and quite a bit of time on top of that) could use something like a /etc/hosts file that would map function-based aliases to serials or paths or whatever. Then you'd have glasgow --alias tl-wr841nd_jtag_uart run ... instead of glasgow --path usb://1-4.4.4 run .... Of course, if your use case specifically depends on geographical USB addressing I'm all ears.

whitequark · 2020-09-29T20:38:01Z

3. Indeed - that was a tenuous one, but I decided that the filtering I was planning (e.g: with jq) may appreciate direct string comparisons over string manipulation.

What is the use case of filtering connected boards by their revision? Would it be better served by something like glasgow list --rev C0?

attie · 2020-10-02T12:01:19Z

I'm not sure if this is the UI I want to have
network address, which generally changes for benign reasons (DHCP ...

No problem, I'm happy to drop this request!

Here's my writeup on setting up udev to assign aliases to USB-serial converters that can only be distinguished geographically.
Of course, if your use case specifically depends on geographical USB addressing I'm all ears.

Thanks very much for the link - a good idea for sure.
This is probably getting a little off-topic now, but my use-case has an automated device testing farm in mind. The concept being that with fairly minimal effort (i.e: config in coordinator, plug things in, and power on), it is possible to support another instance of a particular device that is already in the farm. The physical location of a device on the bus then becomes the stable factor (as you noted "they arrange themselves through a fair dice roll on every reboot"), and writing / installing udev rules for each instance is an extra (and somewhat unnecessary) step.

After thinking about it, it's trivial to retrieve the serial number by other means (e.g: sysfs / lsusb), so with knowledge of the physical port, we can still provide the --serial arg to glasgow to achieve the behaviour I was considering.

What is the use case of filtering connected boards by their revision?

Honestly I didn't have a use case in mind for that.

A plain list of serials it is!

whitequark · 2020-10-02T12:42:26Z

software/glasgow/cli.py

@@ -325,6 +325,10 @@ def factory_serial(arg):
        default=datetime.now().strftime("%Y%m%dT%H%M%SZ"),
        help="serial number in ISO 8601 format (if not specified: %(default)s)")

+    p_list = subparsers.add_parser(
+        "list", formatter_class=TextHelpFormatter,
+        help="list glasgows connected to the system")


Suggested change

help="list glasgows connected to the system")

help="list devices connected to the system")

software/glasgow/device/hardware.py

…a static method

attie force-pushed the list branch from 7b0b8ae to fee28af Compare September 26, 2020 00:08

whitequark requested changes Sep 29, 2020

View reviewed changes

attie force-pushed the list branch 2 times, most recently from 752b51e to 6ff8fbf Compare October 2, 2020 12:28

whitequark requested changes Oct 2, 2020

View reviewed changes

attie-argentum added 3 commits October 2, 2020 14:06

device.hardware: split glasgow firmware loading and enumeration into …

9628574

…a static method

device.hardware: add get_serial_list()

8521484

cli: add list subcommand

2236ab1

attie force-pushed the list branch from 6ff8fbf to 2236ab1 Compare October 2, 2020 13:07

whitequark approved these changes Oct 2, 2020

View reviewed changes

whitequark merged commit 696b94a into GlasgowEmbedded:master Oct 3, 2020

attie deleted the list branch October 10, 2020 22:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Method to list connected Glasgow boards #208

Method to list connected Glasgow boards #208

attie commented Sep 25, 2020 •

edited

Loading

whitequark left a comment •

edited

Loading

attie commented Sep 29, 2020

whitequark commented Sep 29, 2020

whitequark commented Sep 29, 2020

attie commented Oct 2, 2020 •

edited

Loading

whitequark Oct 2, 2020

	help="list glasgows connected to the system")
	help="list devices connected to the system")

Method to list connected Glasgow boards #208

Method to list connected Glasgow boards #208

Conversation

attie commented Sep 25, 2020 • edited Loading

whitequark left a comment • edited Loading

Choose a reason for hiding this comment

attie commented Sep 29, 2020

whitequark commented Sep 29, 2020

whitequark commented Sep 29, 2020

attie commented Oct 2, 2020 • edited Loading

whitequark Oct 2, 2020

Choose a reason for hiding this comment

attie commented Sep 25, 2020 •

edited

Loading

whitequark left a comment •

edited

Loading

attie commented Oct 2, 2020 •

edited

Loading