Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 07:14 22 Jan 2022 Privacy Policy
Jump to

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: Australia
Posts: 918
Posted: 01:47am 08 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 4537
Posted: 06:15am 08 Jan 2022
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2077
Posted: 09:01am 08 Jan 2022
Copy link to clipboard 
Print this post

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
CMM2 Welcome Tape, Creaky old text adventures
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 1891
Posted: 12:08pm 08 Jan 2022
Copy link to clipboard 
Print this post

  panky said  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


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 Kingdom
Posts: 2613
Posted: 01:53pm 08 Jan 2022
Copy link to clipboard 
Print this post

  robert.rozee said  your friend here is pkexec, that is available on many Linux variants, but certainly far from all.

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 Zealand
Posts: 1891
Posted: 02:19pm 08 Jan 2022
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2613
Posted: 05:34pm 08 Jan 2022
Copy link to clipboard 
Print this post

Oh, GUI.

John
 
panky

Guru

Joined: 02/10/2012
Location: Australia
Posts: 918
Posted: 11:35pm 08 Jan 2022
Copy link to clipboard 
Print this post

  TassyJim said  Just out of interest,
try changing the OPTION CPUSPEED which causes a reset.
Does the com port still stay the same?

Jim

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: Australia
Posts: 4537
Posted: 12:04am 09 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 918
Posted: 12:23am 09 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 4537
Posted: 02:23am 09 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 918
Posted: 03:47am 09 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 918
Posted: 04:00am 09 Jan 2022
Copy link to clipboard 
Print this post

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 Zealand
Posts: 1891
Posted: 05:16am 09 Jan 2022
Copy link to clipboard 
Print this post

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: Australia
Posts: 4537
Posted: 06:15am 09 Jan 2022
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 5688
Posted: 08:17am 09 Jan 2022
Copy link to clipboard 
Print this post

  Quote  
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.


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

  Quote  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.


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 Zealand
Posts: 1891
Posted: 09:22am 09 Jan 2022
Copy link to clipboard 
Print this post

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  


  matherp said  
  Quote  [...](b) introduce a fixed delay upon startup before any USB connect to the host is initiated

Perhaps you should check the TinyUSB source like I have [...]


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.


  matherp said  
  Quote  [...] the prototype for the 'front end' of this already exists within the source code for the PRINT command

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.


  matherp said  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


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 Kingdom
Posts: 5688
Posted: 09:41am 09 Jan 2022
Copy link to clipboard 
Print this post

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 Zealand
Posts: 1891
Posted: 01:48pm 09 Jan 2022
Copy link to clipboard 
Print this post

  matherp said  [...]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


wow... in one fell sweep you could alienate hundreds of people, all at once  
 
scruss
Newbie

Joined: 20/09/2021
Location: Canada
Posts: 37
Posted: 08:16pm 09 Jan 2022
Copy link to clipboard 
Print this post

  panky said  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

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
© JAQ Software 2022