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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
