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 : 'mite family and Linux
Page 1 of 2 | |||||
Author | Message | ||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
I thought I might start a topic that seems to crop up periodically but spread all over other threads. Background: A retired Electronics Technician and a lifelong hobbyist, I have spent the last 2 years slowly moving from a Windows environment to a Linux one (mostly due to cost and a frustration with Windows upgrade issues). I am running Linux Mint 20.2 with legacy Windows application programs (for which there are no Linux equivalents or that won't run under Linux) running under either Wine or VirtualBox (Win 7 Pro - my old stallwart). I have no real axe to grind with Windows - I used it extensively for many years and it's pretty good but I am enjoying the challenges of working with Linux and the 'closeness' to the metal it offers. I am still definitely a Linux beginner but am slowly getting more proficient with the command line (as a retiree, time is not an issue ). Now to the recent discussions re Pico and dis-connect/re-connect - on my Mint 20.2 system, a dis-connect/re-connect always comes back with the same ACM number - the following can demonstrate your own situation:- doug@GarageMint20$ udevadm monitor -k | grep ACM ' I dis-connected the Pico here KERNEL[426208.028091] remove /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.1/2-2.1:1.0/tty/ttyACM0 (tty) ' and re-connected the Pico here KERNEL[426236.282003] add /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.1/2-2.1:1.0/tty/ttyACM0 (tty) ^C As suggested by valhout, there may be scope to make use of udev rules to make things easier for users. I am working on a Bash script to both provide more info as well as possible ways to initiate other interactions. 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: 5867 |
Just out of interest, try changing the OPTION CPUSPEED which causes a reset. Does the com port still stay the same? Jim VK7JH MMedit MMBasic Help |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
Good idea @panky. Also gives me somewhere to thank Rob and @Volhout for there recent suggestions without further hijacking the original threads. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
alas, working at that level you are likely to find variations between different flavours of Linux and other UNIXes that will trip you up. there is also the problem that creating and/or changing udev rules require using elevated privileges, something that unsettles many users. btw, your friend here is pkexec, that is available on many Linux variants, but certainly far from all. the fundamental issue is that both Windows and UNIXes (a term that also encompasses Linux) expect serial ports to be part of the 'fixed wiring'. faults in said 'fixed wiring' create unpredictable results on all the major operating systems, and likely will continue to do so for the foreseeable future. under Windows there are a few 'tricks' you can use to 'peek under the bonnet', intercepting some of the myriad of global messages that continuously whiz around the system that give you clues about when things break down. when GFXterm sees a possible sign of a cable being pulled, it then uses an undocumented side-effect within a windows API to verify if the currently open serial port is affected. under UNIXes, there are slightly more formalized routes that can give you similar information. but none of these 'tricks' can provide guaranteed results, and may in future themselves cease to be supported by the operating system. folks have discovered the methods used by long hours of trial and error experimenting. the least reliable thing, currently, is the port name that a briefly unplugged device returns under. the safest approach is for any pico program (and here i'm talking about the MMbasic firmware) really is to minimize generating USB 'unplug' events. the events can create anything from a port name change, to a complete crash of the Windows or UNIX operating system. while one particular install of Windows running on one particular set of hardware (sitting somewhere in the UK) may handle unplug events 100% gracefully, this does not guarantee that every other computer in the world - or even the just to the 73.75% running Windows - will behave the same. cheers, rob :-) Edited 2022-01-08 22:11 by robert.rozee |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3641 |
I suspect su is always there & would work for what you want. (su -c particularly.) John |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
the advantage of pkexec is that it will generate a GUI popup window itself, asking you to enter your password: this (pkexec ls /) works if called from a shell script, or from a GUI executable. when using su (or sudo where the root account is disabled as it is in Linux Mint) within a script or from an application, you need to figure out how to pipe the password into it yourself, which can be quite a challenge - and almost impossible to do in a secure manner that can not be intercepted by a bad actor. for instance: echo "mysecretpassword" | sudo -S ls / which works, but is an immensely bad idea from a security perspective. cheers, rob :-) Edited 2022-01-09 00:23 by robert.rozee |
||||
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3641 |
Oh, GUI. John |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Hi Jim, Yes, on my Mint 20.2, the COM port comes back with the same ACM every time as far as using the Pico is concerned. I have the Pico on a hub and even removing the hub then plugging the Pico directly into the laptop still retains its ACM number. The only time it will change is if I plug devices in in a different sequence - it will then retain whatever sequence number is during unplug/plug or Pico reset/restart. It may even by platform dependent - I am running an Acer laptop with 2 hubs ( a 4 port for external hard drives) and a 7 port for all my 'mites. 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: 5867 |
Thanks Doug, I wasn't worried about the 'slow' changes, it is only the fast ones due to option changes that cause both my systems (Linux Mint and RPi) that give the changes port number. It is good that the problem appears to be uncommon. I can live with it. Jim VK7JH MMedit MMBasic Help |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Jim, If you're running Mint 20.2 then it seems like it may be a difference in PC/laptop USB interface hardware? My laptop has an Intel i7-5500U processor and the Linux kernal is 5.4.0-81 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: 5867 |
My Mint is on a slow laptop so I assume that the issue I observe is due to the age of the laptop. [ 842.374714] usb 3-1: new full-speed USB device number 2 using ohci-pci [ 842.585836] usb 3-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [ 842.585847] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 842.585853] usb 3-1: Product: Pico [ 842.585859] usb 3-1: Manufacturer: Raspberry Pi [ 842.585864] usb 3-1: SerialNumber: E6605838833E9738 [ 842.646952] cdc_acm 3-1:1.0: ttyACM0: USB ACM device [ 842.651642] usbcore: registered new interface driver cdc_acm [ 842.651648] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters [ 899.696389] usb 3-1: USB disconnect, device number 2 [ 900.786847] usb 3-1: new full-speed USB device number 3 using ohci-pci [ 901.009882] usb 3-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [ 901.009893] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 901.009900] usb 3-1: Product: Pico [ 901.009906] usb 3-1: Manufacturer: Raspberry Pi [ 901.009911] usb 3-1: SerialNumber: E6605838833E9738 [ 901.018162] cdc_acm 3-1:1.0: ttyACM1: USB ACM device [ 1157.600040] usb 3-1: USB disconnect, device number 3 [ 1158.667367] usb 3-1: new full-speed USB device number 4 using ohci-pci [ 1158.878546] usb 3-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [ 1158.878557] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1158.878563] usb 3-1: Product: Pico [ 1158.878569] usb 3-1: Manufacturer: Raspberry Pi [ 1158.878575] usb 3-1: SerialNumber: E6605838833E9738 [ 1158.886667] cdc_acm 3-1:1.0: ttyACM0: USB ACM device jim@Satellite:~$ The two port number changes are when I do an OPTION CPUSPEED The disconnect-reconnect takes just over 1 second. Pressing reset button as fast as I can gets the time down to nearly as fast and the port number does stay the same. Don't worry about it, I am rapidly coming to the conclusion that my desire to support Linux with MMEdit is a silly idea. Jim VK7JH MMedit MMBasic Help |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Jim, Just for info, a disconnect/re-connect of the Pico on my machine - differences appear to be the driver, mine being xhci_hcd as opposed to your ohci_hcd [523058.114822] usb 2-2.1: USB disconnect, device number 36 [523058.116037] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr [523058.116039] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending. [523060.641561] usb 2-2.1: new full-speed USB device number 39 using xhci_hcd [523060.767452] usb 2-2.1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [523060.767456] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [523060.767458] usb 2-2.1: Product: Pico [523060.767460] usb 2-2.1: Manufacturer: Raspberry Pi [523060.767462] usb 2-2.1: SerialNumber: E660443043789921 [523060.780585] cdc_acm 2-2.1:1.0: ttyACM0: USB ACM device doug@GarageMint20:/etc/udev/rules.d$ Re MMEdit for Linux - it seems a shame to not continue having gone as far as you have. Mind you, I'm not the one tearing my hair out If I can assist in any way, please let me know. Regards, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
Jim, If you want a break from working with windows (the double glazing type ), this has some background on xhci_hcd. Also, just for my interest, could you run the following udevadm monitor -k | grep ACM then unplug/replug the Pico and post the results? Cheers, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
perhaps we should just create a fork from peter's github page of the pico version of MMbasic, and fix the problem within the MMbasic firmware itself? essentially, it sounds like a good portion of the problems could be resolved by (a) forcing tinyusb to formally disconnect before rebooting, and, (b) introduce a fixed delay upon startup before any USB connect to the host is initiated. i also believe that my semicolon idea (for deferring the reset caused by an OPTION change) would be relatively simple to add into the code and would resolve many issued being seen. the prototype for the 'front end' of this already exists within the source code for the PRINT command. incidentally, the MX470 versions of MMbasic (Micromite+) had a similar problem with USB. the solution quickly adopted was to drop the on-chip USB support and instead use an auxiliary PIC16F1455 as a USB to serial bridge + 'ascii ICSP' programmer. i don't believe that such an approach is necessary with the pico. cheers, rob :-) Edited 2022-01-09 15:18 by robert.rozee |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5867 |
Sorry Doug, USB3 ports use xhci_hcd and it makes no difference to my system [16144.779737] usb 5-1: new full-speed USB device number 4 using xhci_hcd [16144.955543] usb 5-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [16144.955554] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [16144.955560] usb 5-1: Product: Pico [16144.955566] usb 5-1: Manufacturer: Raspberry Pi [16144.955571] usb 5-1: SerialNumber: E6605838833E9738 [16144.971844] cdc_acm 5-1:1.0: ttyACM0: USB ACM device [16198.465502] usb 5-1: USB disconnect, device number 4 [16199.219899] usb 5-1: new full-speed USB device number 5 using xhci_hcd [16199.395545] usb 5-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [16199.395556] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [16199.395563] usb 5-1: Product: Pico [16199.395569] usb 5-1: Manufacturer: Raspberry Pi [16199.395574] usb 5-1: SerialNumber: E6605838833E9738 [16199.409717] cdc_acm 5-1:1.0: ttyACM1: USB ACM device [16229.050471] wlp5s0: AP 38:10:d5:10:f2:83 changed bandwidth, new config is 2462 MHz, width 1 (2462/0 MHz) jim@Satellite:~$ Jim VK7JH MMedit MMBasic Help |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8517 |
Perhaps you should check the TinyUSB source like I have an see that as far as I can see it does not offer a disconnect mechanism of any sort I also believe you don't know what you are talking about. The issue isn't the ; syntax but rewriting a big chunk of the option handling to update a "shadow" option rather than the real ones before issuing the save. What you also don't know is that I have used every byte of RAM and that there isn't RAM available for this "shadow" structure Also if you implement it you are in the situation that you issue an option command and as a user you have to guess if it gets actioned or not immediately or if you have to wait until you do something else before it gets actioned. Hardly a recipe for simplicity and straightforward operation OPTION LCDPANEL whatever TEXT 0,0,"Hello" Error: Display not set Or perhaps you also want to edit and slow down every relevant command to test for option configured but not yet implemented (there are a lot of them) Edited 2022-01-09 19:01 by matherp |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
hi peter, welcome to the Linux thread, a safe place for Linux and other like-minded users to kick around ideas without fear of admonishment or ridicule. i am sure all the thread contributors welcome your constructive input i have looked at the various threads on the pico SDK forum, and seen various discussion of ways and places to 'slow down' startup. i believe you even experimented with introduced some delays yourself in the early stages of development. I also believe you don't know what you are talking about [...] the PRINT command decodes a trailing semicolon, it is not reasonable to assume that the same mechanism could not be effected with the OPTION command? this would provide the 'front end' or user-facing side of the coding problem, but does have NOTHING to do with how the back end in handled. the pico version of MMbasic provides somewhere around 100k or so of RAM for variable storage, with some sort of heap manager, yes? a deferred OPTION ... ; command could simply allocate/grab some of this RAM (i'm guessing 256 bytes would likely be sufficient for all the hardware configuration options? or 512 bytes, or 1k?), with that RAM then being deallocated automatically when a non-deferred OPTION ... (NO semicolon) command was encountered and the pico reset itself. use of deferred options is unlikely to be used every time a program is run, but rather be a short user-written utility program held in a spare flash slot to be run now and then as required. at the absolutely most complicated, two or more blocks of OPTION statements with a simple basic-driven menu for the user to select the desired setup. at the simplest, just a short list of OPTION statements, all but the last one ending in a semicolon. cheers, rob :-) Edited 2022-01-09 19:28 by robert.rozee |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8517 |
It is not worth discussing internal MMbasic workings here other than to comment that other than Geoff I probably know more about them than anyone else and the possible ramifications of "easy" solutions like using HEAP. However, feel free to take the source and do what you want with it. You can even post your revised firmware to solve a non-problem but don't expect me to commit to integrate changes into the official version or consider or fix bugs in a forked version or not make future changes which would render a forked version incompatible or (despite Tom's wishes) use github in any way other than overwriting updated files as and when I change them. PS: Are you aware that in Geoff's latest versions every time you type RUN the code forces a reset and restarts the processor to get a completely clean start for the program - perhaps I should do that Edited 2022-01-09 19:47 by matherp |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
wow... in one fell sweep you could alienate hundreds of people, all at once |
||||
scruss Regular Member Joined: 20/09/2021 Location: CanadaPosts: 79 |
Well, it would - as long as you don't plug anything else in. Then it might not. The absolutely guaranteed, no-UDEV-fankle-required, always-in-the-same-place serial port is under /dev/serial/by-id. What's more, since recent versions of Picomite pick up the board's unique serial device, you get at address that's unique to each Raspberry Pi Pico. For me, my Picomite will be at /dev/serial/by-id/usb-Raspberry_Pi_Pico_E6609CB2D34D6933-if00, no matter which Linux machine I plug it into. Your board will be different, as will any other board that I own. udev rules are a huge barrier to usability: requiring them before hardware will do its thing is a big no thank you from most users. |
||||
Page 1 of 2 |
Print this page |