arduino usb/com port issue

[Gary Aitken]

On 6/1/20 7:42 PM, Gary Aitken wrote:
> Ok, I've rebooted even though I didn't need to ;-)
> 
> If I start an X session as root, when I start arduino the Serial Port
> menu item is live; I have the needed access and see 4 devices:
>    /dev/ttyu0
>    /dev/cuau0
>    /dev/ttyU0
>    /dev/cuaU0
> In my case, /dev/cuaU0 is what responds when I have the arduino
> plugged in.
> The other three devices are "permanently" present;
> cuaU0 only appears when the arduino is plugged in.
> If I assign cuaU0 as the arduino serial device, arduino uploads to
> it fine.
> So all is cool if you're the supreme being.
> 
> Switching back to a normal user, the entire serial port menu item
> is still greyed out, so you see no choices even though the other
> three devices are still present.
> 
> As a normal user:
> $ grep skinnyguy /etc/group
> operator:*:5:root,skinnyguy
> video:*:44:skinnyguy
> dialer:*:68:skinnyguy
> 
> $ grep devfs /etc/rc.conf
> # allow local rules as specified in /etc/devfs.rules (5)
> devfs_system_ruleset="localrules"
> 
> $ cat /etc/devfs.rules
> # Allow operator group to mount USB devices
> [localrules=5]
> add path 'da*' mode 0660 group operator
> # for arduino hotplug USB
> add path 'ugen*' mode 0660 group operator
> add path 'usb/*' mode 0660 group operator
> add path 'usb' mode 0770 group operator
> add path 'cuaU*' mode 0770 group operator
> 
> $ ls -l /dev/cuaU0
> crwxrwx---  1 uucp  operator  0xac Jun  1 17:32 /dev/cuaU0
> 
> Giving +rw access to everyone for cua* makes no difference
> 
> Did I miss something along the way, or is there yet something else
> that root has that I'm missing?
> On 6/1/20 9:36 AM, Tomasz CEDRO wrote:
> 
>> On Mon, Jun 1, 2020 at 5:28 PM Ian Lepore wrote:
>>> There should be no need to unload ucom to access the low-level usb
>>> device via libusb.  I typically have anywhere from 5-8 usb-serial
>>> adapters connected at once, it would be crazy to unload ucom and lose
>>> access to all of them just to use one of them with libusb.
>>>
>>> It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU#
>>> at the same time that some application is using libusb (or libftdi) to
>>> access that same device.  That would cause ucom and the work being done
>>> via libusb to conflict with each other.
>>
>> Exactly the problem here. Either application tries to unload kernel
>> driver just to make sure terminal can connect to a dongle (linux
>> quickfix), or the modem port is already opened with u3g module (more
>> probable scenario). Anyway CMSIS-DAP has its own endpoint that is
>> separate from VCP so it should work without unloading the module.
>>
>> Will verify and send patches to the upstream no worries, thanks for
>> the hints, but that could be another source of problem described by
>> Gary that I found in a similar application :-)

Duh.  It was not clear from the ports tree that arduino18 is the
more up-to-date version of arduino.  Installing the arduino18 package
deletes the arduino package, and when it comes up it properly finds
the arduino uno device on cuaU0.  It lists two devices under Serial
Ports:
   /dev/cuaU0
   /dev/cuaU0 (Arduino Genuino Uno)
and the second one is checked (and works).  Why there are two entries
for the same device is unclear, but at least it works.

There are no notes in UPDATING or the ports themselves indicating
the arduino port is (probably?) obsolete.

Thanks all for your help.  devinfo -v makes my head hurt, but it was
illuminating :-).

Gary