Com Port issues

General
41

Yes, that is what I have (after some trial and error and being lead astray by the documentation) resorted to doing.

I expect that the BP5 documentation will be made “not wrong” (and preferably “right”!). It would also be more elegant if it is possible to avoid using /dev/ttyAC*,

Most products have bugs when introduced. The test is how quickly workarounds and corrections appear. It is too early to judge BP5 in that way, but there is an encouraging sign in the form of changing the descriptor strings in the firmware :slight_smile:

42

FWIW, on Linux, you have to make sure you are in the dialout group.

43

Nah, that was maybe true like 10 years ago. And then it was specific to one distribution, while others used for example the “plugdev” group.

Today you want to add TAG+="uaccess" at the end of your udev-rule. Then automatically all users logged in locally will get access. uaccess was introduced in 2012 if I’m not mistaken, so every common linux system should have support for it by now.

1 Like
44

I think I found the issue: all the rules we posted back and forth were syntactically wrong, because they used typographical quotes instead of the regular ones. They really look alike so if you don’t look for this kind of thing you can easily miss it. I don’t know how they got into the posts, maybe it happened when someone copied them the first time or the forum software automatically tries to “beautify” the posts,…

I tried it with another device that presents as multiple serial ports, and even the ATTRS/ENV thing works there without issues - when you use the proper quotes. So please try this one:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="7332", ATTRS{serial}=="123456789012", ENV{ID_USB_INTERFACE_NUM}=="00", MODE="0666", SYMLINK+="buspirate-text"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="7332", ATTRS{serial}=="123456789012", ENV{ID_USB_INTERFACE_NUM}=="02", MODE="0666", SYMLINK+="buspirate-binary"

I used the real double-quotes this time, let’s hope this is kept.

1 Like
45

Bingo!

ll /dev/buspirate-*
lrwxrwxrwx 1 root root 7 Mar 26 23:35 /dev/buspirate-binary -> ttyACM1
lrwxrwxrwx 1 root root 7 Mar 26 23:35 /dev/buspirate-text -> ttyACM0

… and buspirate-text works as expected :slight_smile:

(I hate tools that “help” by changing what I type, with a vengeance. DWIM has a long and inglorious history.)

Thank you :slight_smile:

1 Like
46

I have a question, What are the benefits of using a udev rule instead of /dev/ttyACMx??

47

That was the whole point because ACM port can swap places

48

yes, the port numbers of /dev/ttyACMn aren’t stable.

The number depends on the order in which devices are registered. So if you plug in for example an USB-UART converter first then it will get /dev/ttyACM0. When you plug in the buspirate afterwards it wil get /dev/ttyACM1. So you’d always have to look up the current number first. That is annoying and also can’t be used in scripts or config files.

Using a stable /dev/buspirate-text solves this - unless you have multiple bus pirates connected to the same pc.

49

Perfect, finally it works.

The MODE="0666" used currently is a bit of a sledgehammer-solution by allowing access to everyone. I suggest to use the more targeted uaccess solution instead:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="7332", ATTRS{serial}=="123456789012", ENV{ID_USB_INTERFACE_NUM}=="00",  SYMLINK+="buspirate-text", TAG+="uaccess"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="7332", ATTRS{serial}=="123456789012", ENV{ID_USB_INTERFACE_NUM}=="02",  SYMLINK+="buspirate-binary", TAG+="uaccess"
1 Like
50

Hmm. I just added these rules, rebooted, and I still get the old names when I plug in my .

51

you mean “/dev/buspirate” or “/dev/ttyACM0” (or another number)?

52

I still get “/dev/ttyACM0" with the new udev rules.

53

For me this rules work. Maybe restart udev to load new rules

54

ok, so I guess the rules file isn’t loaded for some reason.

Did you make sure no typographic quotes crept in when copying the lines from the forum?

Did you put those two lines into a file into the directory /etc/udev/rules.d/?

The filename must end in .rules. Usually the filenames start with a number to properly order them, so I suggest something like 95-buspirate.rules.

Also the permissions and ownership should be correct, 0644 and root:root.

If your system uses SELinux, the extended attributes must match, I suggest calling sudo restorecon /etc/udev/rules.d/* to fix them just in case.

Afterwards reload your rules: sudo udevadm control --reload-rules and then plug in the Bus Pirate. Does it work now?

55

It’s working now. I was missing a carriage return at the end of the last line.

56

You can access the tty also by using /dev/serial/by-id which presents something like:

  • /dev/serial/by-id/usb-Bus_Pirate_Bus_Pirate_5_123456789012-if00
  • /dev/serial/by-id/usb-Bus_Pirate_Bus_Pirate_5_123456789012-if02

This are consistent and reproducible (If the firmware provides unique serial numbers it would work with more than one PB connected at once) and you don’t need to customize any udev rules at all. Your user should probably added to the dialout group or whatever your distro puts the /dev/ttyACM* under.

Also tio seems to be more competent than minicom or screen at handling ANSI colors and keys can be mapped, eg to fix backspace.

57

Or an option to set a serial number for usb. I have done that with usb serial chips before.

58

Same issue here. Windows 7 doesn’t know what to do with the USB device.

Windows 10 detected and shows 2 com ports (com5 and com7). If you try to use com5 first with putty, it hangs and will not allow you to connect.

I followed what another poster said to do. I unplugged, plugged back in and connected to com7. Now it connects and gives a prompt.

Thanks for posting the solution! Now on for more testing!

Aaron

59

I have checked on Windows 11 and on macOS. A bit of a common theme. If you access the binary port first (of the two com ports / usb ports) you drop in to logic analyser mode from which there is no return. And it does not tell you you are in this mode. Looking at the code (my $0.02) the call to sump_logic_analyzer() in sump,c has no way back out of sump mode. And this is called from the entry into binary mode from binio.c
So basically - if you put anything on the binary UART port it would appear you are never seeing the terminal (or if you have seen it there is no way back out) as you are locked into SUMP mode. Happy to be wrong !
So if you want to see the terminal with the latest firmware - make sure to go on the terminal port. It’s not a windows or macOS or linux thing. It could be a bug in the firmware.
And there would appear to be no way to get to bit stuffing at present.
Now if I was more confident, I would help fix, so please ask if help wanted and add some directions. Looking at Github, 2 months back some major changes led to this.
(You can tell SUMP is active because CTRL-B and CTRL-D emit some status strings as noted elsewhere)
Hope this helps.

2 Likes
60

I went back and looked at the community version for the previous firmware. sump.c previously exited the infinite loop you’re looking when it received a SUMP_RESET command over the UART:

It looks a way to maybe address it is by adding a check for the state of the last received SUMP command here: BusPirate5-firmware/mode/sump.c at main · DangerousPrototypes/BusPirate5-firmware · GitHub
and then changing the while(1) to something like while(do_sump) and then update do_sump or similar to a 0 to exit out.

Edit: Or maybe this is another is a really great place to check if the button was pushed like in UART bridge