 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Thoughts on USB
| Author | Message | ||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
I find USB, while elegant in its concept, to be overly and frustratingly complex in its application to what is essentially serial byte communication (as with most micros). The increasing integration of the USB into the silicon and firmware of the micro itself, as in the Pico, makes it harder and harder to determine just exactly what is, or should be, happening. You can not easily "see" what any signals are much less interpret what they mean. I would be interested to hear any comments/ideas on fault finding techniques specifically targeted at USB communication. As a long time sufferer of OFD (old f!@#s disease), I would far to prefer to work with straight serial and leave the USB/serial interface to a standalone module (eg. Microbridge, FTDI etc.) which do not care what serial device with which they are connected. Analysing communications issues is then greatly simplified - from a simple logic probe for activity through using an oscilloscope or even a logic analyser for greater detail of the data stream. If it were any way possible, a serial console option for the Pico, as was done for the F407, would be extremely useful. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
There is a USB plug-in for WireShark It is my preferred way of analyzing if debug code in MMEdit isn't enough. Jim VK7JH MMedit |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
hi panky, i fear i'm going to sound like a broken record in the following... i've suffered through the same USB pains over the years i used windows. i when through the FTDI wars, and endured the Prolific 'difficult times'. thankfully i missed out on the early E-100 saga before an external USB-to-serial bridge was added. and now we have the pico saga - which is, incidentally, also impacting linux. the only difference is that in the case of linux there are simple tools to fix the injuries inflicted. you should give linux a go. i use linux mint with the XFCE desktop. a simple download - write it to a USB drive, and it will boot from the drive and then with a single mouse click can be installed in a matter of minutes. once you have linux up and running, it does require a few tweaks to get everything working nicely. after that, you have libre office as an alternative to MS office. you can install the GIMP to do image manipulation. there are built-in media players, and just about anything else you might need is downloadable with just a few clicks. and USB/CDC works out-of-the box, no extra drivers ever needed. just plug it in, and it works. the pico will still knock over the USB subsystem every now and again, but i've got a short script now that you just click on (like a batch file in windows) that brings it all back up again. with the pico, i use that script a great deal! cheers, rob :-) |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Tend to agree with Rob!  Just recently, I had a thread up trying to find out why Windoze was moaning so much about a USB device malfunction. You just don't seem to get that kind of issue in Linux - ever. I have plugged in gawd only knows how many USB things in Linux, and - shock, horror - they just WORK. I know, I know! I could not belive it either coming from Windoze, but they do just work! That includes external hard-drives - one of the devices that give me the most amount of pain on Windoze with the above error. Not in Linux. Plug in the drive, mount it, and away you go. This is why I only have one Windoze machine running now(this one), all the other machines are Linux, including all my server boxes and my mediaplayer too. They just go and go and go, 24 hours a day, 7 days a week, 365 days a year. The only down-time, is when I actually shut them off for something. None of this Windoze moaning about now needing to reboot and install updates etc. Ranting a bit now, so I will leave it there.  Smoke makes things work. When the smoke gets out, it stops! |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 504 |
USB protocol is complex. There is a nice video from the Ben Eater Youtube channel showing how USB communication works. https://www.youtube.com/watch?v=wdgULBpRoXk |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
Unfortunately linux is by no means immune. USB is only half the story. You may be able to plug something in, it might be recognised, but it's possible that you'll never get it to work because the manufacturer only ever produced it to work with windows. You may be lucky and someone has reverse-engineered the system to produce a linux driver or you may not. If you're really lucky there'll already be a kernel driver, but don't count on that unless the device is several years old. Even when stuff works, the chances are that the functionality will be reduced compared to a windows installation. I used to run linux exclusively. I still think it's brilliant, but IMHO it's not the ideal if you want to get easy connectivity with modern devices. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
If you use W10 and teraterm then reconnection after a reset or power on is instant. The only way you will know that the reset has occurred is that you hear the USB connection/reconnection sounds. Why Linux can't do the same is something for their developers to answer. W7 doesn't support it either. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
If it's just teraterm that does it then I suppose it must have some logic to try reopening the USB connection. I don't know if any Linux app ("terminal program") already includes that feature (I've never needed it so haven't looked) but obviously it could be added (maybe call it "auto-reconnect"). It would be fairly easy to use a shell script to do something adequate (but a bit clunky), I think. Sounds roughly what Rob has done. I wonder if anyone on the RPi forums has provided something (again, I've not needed it so haven't looked)... John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
detecting a disconnect is relatively easy under windows - hook WMDeviceChange events (USB device plug and unplug), then a short time after each event (i used 45ms) use CreateFile() to check the status of "\\.\COMn". a return of ERROR_FILE_NOT_FOUND means the port is no longer present. the same under linux is near-trivial - just keep an eye on the file "/dev/ttyACM0" (or whatever the port name happens to be). if it disappears, the USB device has been unplugged (or, in the case of pico, crashed itself or broken the USB subsystem). the tricky part is detecting the reconnect. if the USB device does not have a serial number set (the vast majority do not) then windows may or may not use the previous COMn name. the same holds for linux i believe. you can sit waiting for the port you were connected to before to reappear and when it does open it, but this is a gamble. teraterm is pretty good at beating the odds on this one. you could just open the next com port that appears, but then there is a risk of opening something completely unrelated. under linux, maybe 70% of the time the pico pops up with the same name, while 20% of the time it gets a new name as it has managed to enumerate before the USB subsystem has finished with the old name. and perhaps 10% of the time the USB subsystem falls over with an error -110 (power exceeded). the pico is the only device i've seen do this. the solution when the linux USB subsystem falls over is to unbind then (re)bind it. a short magic incantation, easy enough when you figure out how, but requires root access. i'm working on a simpler solution. cheers, rob :-) Edited 2021-06-12 20:32 by robert.rozee |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Windows stores usb devices in registry. When a device disappears, an reappears it will have the same COM port number. Teraterm stays alive an polls the COM port, when it,s back, you simply continue where you left. Linux allocates serial devices dynamically. This is fine if you have only 1 device. But when you have more, and one is removed, the other can after reconnect get another ID. I.e. From /dev/ttyUSB3 to /dev/ttyUSB2. In that case a program like Putty cannot reconnect automatically. There is a way to get serial devices to a unique fixed name: use udev.rules. The issue with windows device drivers is that sometimes the drivers are 'tuned' to ignore copycat chips. To fix that install the oldest driver you can find on the original mfgr website. Many cases that works. PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Windows stores usb devices in registry. When a device disappears, an reappears it will have the same COM port number. Teraterm stays alive an polls the COM port, when it,s back, you simply continue where you left. Linux allocates serial devices dynamically. This is fine if you have only 1 device. But when you have more, and one is removed, the other can after reconnect get another ID. I.e. From /dev/ttyUSB3 to /dev/ttyUSB2. In that case a program like Putty cannot reconnect automatically. There is a way to get serial devices to a unique fixed name: use udev.rules. The issue with windows device drivers is that sometimes the drivers are 'tuned' to ignore copycat chips. To fix that install the oldest driver you can find on the original mfgr website. Many cases that works. PicomiteVGA PETSCII ROBOTS |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
In Windows, rather than using CreateFile() to check the status of "\\.\COMn", I now use the pDBHDR.DEV_BROADCAST_HDR structure which lparm points to to get the info. The procedure I use in MMUploader (PureBasic): Procedure GetDeviceEvent(WindowID,Message,wParam,lParam) ;Callback procedure to catch a removable device event Protected ValidEvent = #False, result, portname$, unitmask.q, driveLetter.s, bt.l Protected *pDBHDR.DEV_BROADCAST_HDR, *pDBO.DEV_BROADCAST_OEM, *pDBP.DEV_BROADCAST_PORT, *pDBV.DEV_BROADCAST_VOLUME result = #PB_ProcessPureBasicEvents If Message=#WM_DEVICECHANGE result = #True Select wParam Case #DBT_DEVICEARRIVAL ; AddGadgetItem(5, -1,"WM_DEVICECHANGE "+"DBT_DEVICEARRIVAL") ValidEvent = #True Case #DBT_DEVICEREMOVECOMPLETE ;AddGadgetItem(5, -1,"WM_DEVICECHANGE "+"DBT_DEVICEREMOVECOMPLETE") ValidEvent = #True Default ; AddGadgetItem(5, -1,"WM_DEVICECHANGE "+StrU(wParam)) EndSelect If ValidEvent = #True *pDBHDR.DEV_BROADCAST_HDR=lParam Select *pDBHDR\dbch_devicetype Case #DBT_DEVTYP_OEM *pDBO.DEV_BROADCAST_OEM=lParam ;oemID = *pDBO\dbco_identifier ; AddGadgetItem(5, -1,"Device Change Info "+"dbco_identifier: " + Str(oemID)) Case #DBT_DEVTYP_PORT *pDBP.DEV_BROADCAST_PORT=lParam portName$ = PeekS(*pDBP + OffsetOf(DEV_BROADCAST_PORT\dbcp_name)) If wParam = #DBT_DEVICEARRIVAL AddGadgetItem(#Report, -1, "Port: "+portName$+" inserted") Else AddGadgetItem(#Report, -1, "Port: "+portName$+" removed") EndIf updatePorts() ; AddGadgetItem(5, -1,"Device Change Info "+"dbcp_name : " + portName$) Case #DBT_DEVTYP_VOLUME *pDBV.DEV_BROADCAST_VOLUME=lParam unitmask = *pDBV\dbcv_unitmask Repeat If (unitmask & 1) = 1 driveLetter = Chr(65+bt) Break EndIf bt = bt + 1 unitmask = unitmask/2 Until unitmask = 0 Select *pDBV\dbcv_flags Case #DBTF_MEDIA ; AddGadgetItem(5, -1,"Device Change Info "+"DBTF_MEDIA") Case #DBTF_NET ; AddGadgetItem(5, -1,"Device Change Info "+"DBTF_NET") Default AddGadgetItem(#Report, -1," Device Drive "+driveLetter) If picoReady = 1 picoReady = 0 Delay(1000) AddGadgetItem(#Report, -1,driveLetter+":\"+GetFilePart(currentFile)) CopyFile(currentFile,driveLetter+":\"+GetFilePart(currentFile)) EndIf EndSelect Case #DBT_DEVTYP_DEVICEINTERFACE ; AddGadgetItem(5, -1,"Device Change Info "+"#DBT_DEVTYP_DEVICEINTERFACE") Case #DBT_DEVTYP_HANDLE ; AddGadgetItem(5, -1,"Device Change Info "+"#DBT_DEVTYP_HANDLE") EndSelect EndIf ; AddGadgetItem(#Report, -1, "Device Change Info "+"dbcp_name : " + portName$) ; SendMessage_(GadgetID(5), #EM_SETSEL, -1, -1) EndIf ProcedureReturn result EndProcedure I wait for the new drive to appear when I trigger a firmware upload with the pico. I then know what drive letter it gets so I can paste the uf2 file into it. I just have to incorporate it into MMEdit and I should have auto reconnect working there. It's on the gunna do list. Jim VK7JH MMedit |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
