Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 07:24 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 2 of 2    
Author Message
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 2613
Posted: 08:32pm 09 Jan 2022
Copy link to clipboard 
Print this post

  scruss said  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.

They're the price for better security (better than just allowing stuff regardless, that is).

It would be nice if the first time a user plugged in an unknown device something (with a GUI I suppose) quickly went about helping the user (er, asked was it deliberate, what to do and whatever).

"Just" needs someone to see that, figure just what it ought to do, and write it LOL

I guess it's got minimal appeal, as most users never plug such things in.

John
 
panky

Guru

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

I didn't intend for this thread to be a general Linux problem thread, rather just a place where anyone could post on issues that occur between any of the 'mites and Linux. No offence of anyone's contributions was intended and if caused, I apologise.

What I found interesting in my own exploration of the Pico/Linux communications was that the Linux kernal (at least in my setup here) DOES recognize and handle the re-connect automatically and in my case, assigns the same ACM number.

In minicom (a Linux communications program), the application (minicom) AUTOMATICALLY re-connects. It must obviously retry the same ACM number on loss for some time before giving up. Unfortunately, GFXTerm does not do the re-try before giving up (Putty doesn't either).

Exactly the same mechanism/sequence appears to occur with Windows and TerraTerm (automatically tries to re-connect to the last connected device) thus from Peter's (quite reasonable) perception, there is no real end-user issue so little point in chasing any 'solutions' to a problem that only occurs in specific situations.

For me it was never a 'game changer', just one of those '...it would be nice if...' things.

Thanks to all who offered advice.

Doug.
... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it!
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 2613
Posted: 08:44pm 12 Jan 2022
Copy link to clipboard 
Print this post

IWFM (it works for me).

Tried with a couple of laptops, I get the same ttyACM0 every time.

However, I do NOT get the signon message :(
(I do get a > prompt if I hit Enter.)

So... looked at the code. Looks OK. Part of main:

if(Option.SerialConsole==0) while (!tud_cdc_connected() && mSecTimer<5000) {}


Superficially OK, though what mSecTimer has got to at that time I don't know.

The disassembly looks wrong :(

10002306:       2c00            cmp     r4, #0
10002308:       d12b            bne.n   10002362 <main+0x1de>
1000230a:       4e0e            ldr     r6, [pc, #56]   ; (10002344 <main+0x1c0>)
1000230c:       4d0e            ldr     r5, [pc, #56]   ; (10002348 <main+0x1c4>)
1000230e:       e023            b.n     10002358 <main+0x1d4>
...
10002344:       20030bf0        .word   0x20030bf0
10002348:       00001387        .word   0x00001387
1000234c:       6832            ldr     r2, [r6, #0]
1000234e:       6873            ldr     r3, [r6, #4]
10002350:       2b00            cmp     r3, #0
10002352:       dc06            bgt.n   10002362 <main+0x1de>
10002354:       d100            bne.n   10002358 <main+0x1d4>
10002356:       e0fc            b.n     10002552 <main+0x3ce>
10002358:       0020            movs    r0, r4
1000235a:       f05a fd6b       bl      1005ce34 <tud_cdc_n_connected>
1000235e:       2800            cmp     r0, #0
10002360:       d0f4            beq.n   1000234c <main+0x1c8>


Looks like it fails to wait.

edit: I've sometimes had the message... Must play more...

John
Edited 2022-01-13 07:50 by JohnS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 5688
Posted: 10:43pm 12 Jan 2022
Copy link to clipboard 
Print this post

tud_cdc_n_connected is not reliable definitely sometimes gives not connected when it is and probably connected when it isn't TinyUSB is OK but far from perfect and there appears to be no option. Others also report the RP2040 USB H/W is pretty limited. IMHO better to just accept as-is and get on with it
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 2613
Posted: 11:58pm 12 Jan 2022
Copy link to clipboard 
Print this post

It's good enough, I reckon.

Slightly confusing, maybe.

minicom copes well with the option resets.
(My usual choice is screen but no matter.)

John
 
     Page 2 of 2    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2022