12:08 <mtrbot-ml> [mattermost] <sb10q> what is YAC?

12:08 <mtrbot-ml> [mattermost] <sb10q> there are several channels on the Kasli USB port, make sure you are using the right one

12:09 <mtrbot-ml> [mattermost] <sb10q> and you can also connect the Kasli straight to a computer if you think there maybe an issue with your network settings

12:23 <mtrbot-ml> [mattermost] <hichichris> Ah sorry i meant YAT (Yet another terminal). According to the manual I switched the drivers of Interface 0 to the WinUSB ones. I can see just one COM port which seems to talk properly with the artiq_flash script. I guess thats also the Port to listen to, isnt it? I'll try to connect the kasli dircetly to one of the computers and will update you. Thanks in advance

12:24 <mtrbot-ml> [mattermost] <sb10q> no, artiq_flash uses the JTAG channel, the UART is on another one

12:25 <mtrbot-ml> [mattermost] <sb10q> on Linux you have ttyUSB0-3, and artiq_flash will take ttyUSB0 and UART ttyUSB2

12:25 <mtrbot-ml> [mattermost] <sb10q> also make sure the comms settings are correct, 115200 8-bit data no flow control 1 stop bit

12:30 <mtrbot-ml> [mattermost] <dpn> Btw does anyone (@sb10q?) have a way to consistently figure out which port of the quad-FTDI chip on Kasli is which? Whatever that subdevice identifier is that indexes them in the Linux driver subsystem seems to be assigned fairly arbitrarily (by extension then also leading to random /dev/ttyUSB* orderings)

12:32 <mtrbot-ml> [mattermost] <sb10q> I haven't seem random ttyUSB* orderings with a freshly plugged FTDI-chip (when there are no other allocated port numbers on the system)

12:32 <mtrbot-ml> [mattermost] <dpn> Interesting. On some of our nodes, we have > 20 USB to serial devices

12:32 <mtrbot-ml> [mattermost] <dpn> We have serial numbers configured, so disambiguation between devices isn't an issue, just finding the right port for the shell is.

12:32 <mtrbot-ml> [mattermost] <dpn> Sometimes :1 will be the UART, sometimes :3, etc.

12:33 <mtrbot-ml> [mattermost] <sb10q> use a udev rule like:

12:33 <mtrbot-ml> [mattermost] <sb10q> ACTION=="add", SUBSYSTEM=="tty", ENV{ID_SERIAL}=="FTDI_Quad_RS232-HS",ENV{ID_PATH}=="pci-0000:00:14.0-usb-0:5:1.1", SYMLINK+="ttyUSB_sayma-1_0"

12:33 <mtrbot-ml> [mattermost] <dpn> artiq_flash (or rather openocd, I suppose) seems to work without issues, though, so the information might actually exist

12:34 <mtrbot-ml> [mattermost] <dpn> Hmm, I'll have a look

12:34 <mtrbot-ml> [mattermost] <sb10q> yep it exists; for artiq_flash you can use -t ftdi_device x:y

12:34 <mtrbot-ml> [mattermost] <sb10q> x:y can be determined with lsusb -t iirc

12:35 <mtrbot-ml> [mattermost] <dpn> Take e.g. the output of `python -m serial.tools.list_ports -v`, which will print something like:

12:35 <mtrbot-ml> [mattermost] <dpn> ```

12:35 <mtrbot-ml> [mattermost] <dpn> /dev/ttyUSB15

12:35 <mtrbot-ml> [mattermost] <dpn> desc: Quad RS232-HS

12:35 <mtrbot-ml> [mattermost] <dpn> hwid: USB VID:PID=0403:6011 SER=kasli_101 LOCATION=1-8.2:1.3

12:35 <mtrbot-ml> [mattermost] <dpn> ```

12:35 <mtrbot-ml> [mattermost] <dpn> Which of the 1.<n> the UART is will change

12:35 <mtrbot-ml> [mattermost] <sb10q> udev uses another numbering (of course!) that can be obtained with udevadm info -q all /dev/ttyUSBX

12:36 <mtrbot-ml> [mattermost] <sb10q> the 3 at the end is the channel within the FTDI chip and it is consistent AFAICT

12:37 <mtrbot-ml> [mattermost] <dpn> It isn't, unfortunately. Driver bug, then?

12:37 <mtrbot-ml> [mattermost] <sb10q> really?

12:37 <mtrbot-ml> [mattermost] <sb10q> I have only used udevadm, idk about pyserial

12:38 <mtrbot-ml> [mattermost] <sb10q> note that if you use a udev rule like the one above, you will need to plug the Kasli into the same USB port of your machine every time

12:39 <mtrbot-ml> [mattermost] <dpn> I'm pretty sure I've seen it change, because I wanted to write a wrapper thing to avoid the problem, but then discovered that I couldn't seem to rely on what I assume is the same string from the sys tree that udevadm also prints

12:40 <mtrbot-ml> [mattermost] <sb10q> I've used udev rules like above (also to differentiate between multiple boards on the same machine) and never had issues

12:40 <mtrbot-ml> [mattermost] <sb10q> it always worked consistently when unplugging, replugging, rebooting, etc.

12:41 <mtrbot-ml> [mattermost] <dpn> To differentiate between multiple boards, we just flash the ID to `kasli_101` or whatever; this way, ports can change, etc. without issues. Good to know it's stable for you, though; I'll have another more systematic look at some points

12:41 <mtrbot-ml> [mattermost] <sb10q> flash the ID?

12:41 <mtrbot-ml> [mattermost] <sb10q> you mean change the USB IDs in the EEPROM?

12:42 <mtrbot-ml> [mattermost] <dpn> Serial I mean, sorry

12:42 <mtrbot-ml> [mattermost] <sb10q> serial?

12:42 <mtrbot-ml> [mattermost] <dpn> The one programmed into the FTDI chip, via FT_Prog

12:42 <mtrbot-ml> [mattermost] <dpn> udev/… picks that up

12:43 <mtrbot-ml> [mattermost] <sb10q> ah I see

12:43 <mtrbot-ml> [mattermost] <sb10q> so yes, eeprom

12:45 <mtrbot-ml> [mattermost] <dpn> Sure, yes, apologies for the inaccurate language

12:45 <mtrbot-ml> [mattermost] <dpn> Then just `'ftdi_serial …'` for openocd; works nicely with > 5 Kaslis on a PC

14:08 <mtrbot-ml> [mattermost] <dpn> (which isn't the USB VID/PID, which I thought you were referring to)