arduino usb/com port issue

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

arduino usb/com port issue

Gary Aitken-2
It's not clear to me if this is the right place for this or not; please
let me know if not.  I originally posted on questions and got no response.

I installed the arduino package on an 11.3-RELEASE system.  When
it comes up, the Tools/Serial Port menu item is greyed out,
apparently because it doesn't know USB ports serve as com ports,
or for some reason it can't find them.  Is this something I need to
configure somehow?  Is this something that should be filed as a
bug?

Thanks for any clues,

Gary
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Hans Petter Selasky-6
On 2020-05-31 18:55, Gary Aitken wrote:

> It's not clear to me if this is the right place for this or not; please
> let me know if not.  I originally posted on questions and got no response.
>
> I installed the arduino package on an 11.3-RELEASE system.  When
> it comes up, the Tools/Serial Port menu item is greyed out,
> apparently because it doesn't know USB ports serve as com ports,
> or for some reason it can't find them.  Is this something I need to
> configure somehow?  Is this something that should be filed as a
> bug?
>
> Thanks for any clues,
>

Did you check the permissions on /dev/usb/XXX ?

And output from usbconfig

--HPS

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Tomasz CEDRO
On Sun, May 31, 2020 at 7:54 PM Hans Petter Selasky wrote:

>
> On 2020-05-31 18:55, Gary Aitken wrote:
> > It's not clear to me if this is the right place for this or not; please
> > let me know if not.  I originally posted on questions and got no response.
> >
> > I installed the arduino package on an 11.3-RELEASE system.  When
> > it comes up, the Tools/Serial Port menu item is greyed out,
> > apparently because it doesn't know USB ports serve as com ports,
> > or for some reason it can't find them.  Is this something I need to
> > configure somehow?  Is this something that should be filed as a
> > bug?
> >
> > Thanks for any clues,
> >
>
> Did you check the permissions on /dev/usb/XXX ?
>
> And output from usbconfig
>
> --HPS

Hey Gary, Hey HPS :-)

I am using /dev/cuaU0 USB VCOM Port with success for years on FreeBSD,
even today it works fine with ARM DAPLink debug probe :-)

As HPS noted in the first place check if you have valid permissions
that allow you to read/write from/to usb device. I did a hint at the
OpenOCD port:

/usr/ports/devel/openocd/pkg-message

 To allow an ordinary user to acces any of the the hotplug USB interface
 add him/her to the operator group  (pw groupmod operator -m username), then
 setup the devfs subsystem by adding these lines to the following files:

 ***/etc/devfs.rules:
 [localrules=10]
        add path 'ugen*' mode 0660 group operator
        add path 'usb/*'  mode 0660 group operator
        add path 'usb' mode 0770 group operator

 ***/etc/rc.conf:
        devfs_system_ruleset="localrules"

I use MINICOM as the Terminal emulator. Type Ctrl+A then Z for command
menu. Note that you will have to create a configuration for a given
port in the first place (as root type `minicom -s /dev/cuaU0` set
valid port name and parameters then save as the default configuration
for that port).

I did not use that particular Arduino utility, but there may be a
chance that it was written for Linux and it may suggest port name like
/dev/ttyUSB0 instead /dev/cuaU0 as it is used in FreeBSD.

In general on FreeBSD COM port over USB (aka Virtual-COM-Port) is
handled by `ucom` kernel module (type `kldstat` to list loaded kernel
modules), also it may use `umodem` or even `u3g` module. Those modules
are loaded by `devd` system daemon based on USB descriptors when you
plug a device. I just found a bug in pyOCD (Python module for ARM CPU
debug) that prevents running GDB Server when `ucom` module is loaded
for the VCP port on that board. pyOCD tries to unload the kernel
module by default to gain access to the VCP using LibUSB but it lacks
permissions to do so and the whole program stops with an exception. In
that case simply unload selected modules and `service devd stop` for
the time of testing. This may be also the case for you:
1. You lack permissions to access a resource so temporary try run as
root and see if that works.
2. You may require some component that is already taken by other
service/application.

Note: It is not wise to run as root networked enabled applications
even though are "only meant" for electronics development, so try to
configure your system so it runs such applications without root :-)

Have fun! :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Gary Aitken-2
Hello Tomasz and Petter,

Thank you for your replies.  Still working on this:

>>> I installed the arduino package on an 11.3-RELEASE system.  When
>>> it comes up, the Tools/Serial Port menu item is greyed out,
>>> apparently because it doesn't know USB ports serve as com ports,
>>> or for some reason it can't find them.  Is this something I need
>>> to configure somehow?  Is this something that should be filed as
>>> a bug?
...
>> Did you check the permissions on /dev/usb/XXX ?

These are all set to crw-------
I tried changing all to crw-rw-rw- but still no arduino success

>> And output from usbconfig

# usbconfig -d ugen6.2 dump_device_desc
ugen6.2: <Arduino www.arduino.cc product 0x0043> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0110
   bDeviceClass = 0x0002  <Communication device>
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0008
   idVendor = 0x2341
   idProduct = 0x0043
   bcdDevice = 0x0001
   iManufacturer = 0x0001  <Arduino (www.arduino.cc)>
   iProduct = 0x0002  <retrieving string failed>
   iSerialNumber = 0x00dc  <75833353934351E05231>
   bNumConfigurations = 0x0001

...

> As HPS noted in the first place check if you have valid permissions
> that allow you to read/write from/to usb device. I did a hint at the
> OpenOCD port:
>
> /usr/ports/devel/openocd/pkg-message
>
> To allow an ordinary user to acces any of the the hotplug USB
> interface add him/her to the operator group  (pw groupmod operator -m
> username), then setup the devfs subsystem by adding these lines to
> the following files:
>
> ***/etc/devfs.rules: [localrules=10] add path 'ugen*' mode 0660 group
> operator add path 'usb/*'  mode 0660 group operator add path 'usb'
> mode 0770 group operator
>
> ***/etc/rc.conf: devfs_system_ruleset="localrules"

$ cat /etc/rc.conf | grep devfs
# 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

Do I need to restart after changing devfs.rules?
That would be a bit painful at the moment; already works for
devices like camera and usb sticks but they are da* devices.

> I use MINICOM as the Terminal emulator. Type Ctrl+A then Z for
> command menu. Note that you will have to create a configuration for a
> given port in the first place (as root type `minicom -s /dev/cuaU0`
> set valid port name and parameters then save as the default
> configuration for that port).

I don't understand the need for MINICOM.  I currently use xterm.
Will that work for the print output?

> I did not use that particular Arduino utility, but there may be a
> chance that it was written for Linux and it may suggest port name
> like /dev/ttyUSB0 instead /dev/cuaU0 as it is used in FreeBSD.

The "Serial Port" menu item is greyed out, as if it found none.
When I plug in the arduino, there are 7 new entries in /dev:
$ diff dev_noarduino.txt dev_arduino.txt
29a30,32
> cuaU0
> cuaU0.init
> cuaU0.lock
81a85,87
> ttyU0
> ttyU0.init
> ttyU0.lock
106a113
> ugen6.2

> In general on FreeBSD COM port over USB (aka Virtual-COM-Port) is
> handled by `ucom` kernel module (type `kldstat` to list loaded
> kernel modules), also it may use `umodem` or even `u3g` module. Those
> modules are loaded by `devd` system daemon based on USB descriptors
> when you plug a device. I just found a bug in pyOCD (Python module
> for ARM CPU debug) that prevents running GDB Server when `ucom`
> module is loaded for the VCP port on that board. pyOCD tries to
> unload the kernel module by default to gain access to the VCP using
> LibUSB but it lacks permissions to do so and the whole program stops
> with an exception. In that case simply unload selected modules and
> `service devd stop` for the time of testing. This may be also the
> case for you: 1. You lack permissions to access a resource so
> temporary try run as root and see if that works. 2. You may require
> some component that is already taken by other service/application.

$ kldstat
Id Refs Address            Size     Name
  1   13 0xffffffff80200000 206c860  kernel
  2    1 0xffffffff8226e000 15cf0    fuse.ko
  3    1 0xffffffff82421000 2408     ums.ko
  4    1 0xffffffff82424000 76cc     tmpfs.ko
  5    1 0xffffffff8242c000 1bc0     umodem.ko
  6    1 0xffffffff8242e000 3c58     ucom.ko

I don't think I can run arduino as root as I can't connect to X as root;
do I need to reboot for the /etc/devfs.rules to take effect?
(will have to do some cleanup before trying that)

Thanks,

Gary


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Tomasz CEDRO
On Sun, May 31, 2020 at 11:45 PM Gary Aitken wrote:
> >>> I installed the arduino package on an 11.3-RELEASE system.

Message from arduino-1.0.6_3,1:

"--
Notes on using the Arduino IDE:

To allow serial port locking, add your user to the dialer group:
    pw groupmod dialer -m myuser
(..)"

Did you add your user to the dialer group? That would allow to you to
access modem/vcom devices which seems exactly what you need. The modem
device is /dev/cuaU* for USB-Virtual-COM-Ports :-)


> >> Did you check the permissions on /dev/usb/XXX ?
>
> These are all set to crw-------
> I tried changing all to crw-rw-rw- but still no arduino success

How about /dev/cuaU* ?


> > ***/etc/devfs.rules: [localrules=10] add path 'ugen*' mode 0660 group
> > operator add path 'usb/*'  mode 0660 group operator add path 'usb'
> > mode 0770 group operator
> >
> > ***/etc/rc.conf: devfs_system_ruleset="localrules"
>
> $ cat /etc/rc.conf | grep devfs
> # 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

Either try adding your user to the dialer group as instructed by the
post-install package message (this is the preferred method, note you
need to logout and login after that), or add `add path 'cuaU*' mode
0660 group operator` as another rule in /etc/devfs.rules so you will
gain access to the /dev/cuaU* files as needed if that method works for
you with other devices :-)

You can restart devfs with `service devfs restart` as root no need to reboot :-)


> I don't understand the need for MINICOM.  I currently use xterm.
> Will that work for the print output?

MINICOM can talk to the /dev/cuaU0 and other serial ports like this so
you can test if communication works with your device if other software
fails :-)


Good luck and have fun! :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Ian Lepore-3
In reply to this post by Tomasz CEDRO
On Sun, 2020-05-31 at 22:11 +0200, Tomasz CEDRO wrote:

> On Sun, May 31, 2020 at 7:54 PM Hans Petter Selasky wrote:
> >
> > [...]
>
> I use MINICOM as the Terminal emulator. Type Ctrl+A then Z for command
> menu. Note that you will have to create a configuration for a given
> port in the first place (as root type `minicom -s /dev/cuaU0` set
> valid port name and parameters then save as the default configuration
> for that port).
>

You can use cu(1) from the base system for that.  To connect to the
first usb-serial at speed 115,200 use:

   cu -l cuaU0 -s 115200

To disconnect, use the key sequence <CR> ~ ^D

> In general on FreeBSD COM port over USB (aka Virtual-COM-Port) is
> handled by `ucom` kernel module (type `kldstat` to list loaded kernel
> modules), also it may use `umodem` or even `u3g` module. Those modules
> are loaded by `devd` system daemon based on USB descriptors when you
> plug a device. I just found a bug in pyOCD (Python module for ARM CPU
> debug) that prevents running GDB Server when `ucom` module is loaded
> for the VCP port on that board. pyOCD tries to unload the kernel
> module by default to gain access to the VCP using LibUSB

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.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Tomasz CEDRO
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 :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Gary Aitken-2
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 :-)

I'm running xfce via "/usr/local/bin/startxfce4 --with-ck-launch"
Other than a bunch of xterms, a clock, and thunderbird, nothing
special.

However, I see that dbus- has four instances, and at-spi-bus-launcher
has one:

$ ps ax | grep bus
  604  -  Is      0:00.03 /usr/local/bin/dbus-daemon --system
6260  -  Is      0:00.03 /usr/local/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
6262  -  I       0:00.01 /usr/local/libexec/at-spi-bus-launcher
6263  -  S       0:00.09 /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --p
6259 v0  I       0:00.00 /usr/local/bin/dbus-launch --sh-syntax --exit-with-session xfce4-session

Could these be interfering with user access as you hypothesize?
I don't *know* of any other apps accessing any usb port other than
the mouse.

Jun  1 17:32:30 breakaway kernel: ugen6.2: <Arduino www.arduino.cc product 0x0043> at usbus6
Jun  1 17:32:30 breakaway kernel: umodem0 on uhub3
Jun  1 17:32:30 breakaway kernel: umodem0: <Arduino www.arduino.cc product 0x0043, class 2/0, rev 1.10/0.01, addr 2> on usbus6
Jun  1 17:32:30 breakaway kernel: umodem0: data interface 1, has CM over data, has break

Is there a document describing the relationship between usb0 and
ugen6.2, umodem0, usbus6, and uhub3?  I'm guessing something like
usbusn is a physical port on uhubm which is a physical multiplexor,
and ugena.b, umodemx and usbusy are somehow mapped to usbusn, but
that's a wild guess and probably not useful (to *me*) in making
progress here.  But inquiring minds always want to know, if for
no other reason than to fight dementia :-).

Gary
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Warner Losh
On Mon, Jun 1, 2020 at 7:45 PM Gary Aitken <[hidden email]> 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 :-)
>
> I'm running xfce via "/usr/local/bin/startxfce4 --with-ck-launch"
> Other than a bunch of xterms, a clock, and thunderbird, nothing
> special.
>
> However, I see that dbus- has four instances, and at-spi-bus-launcher
> has one:
>
> $ ps ax | grep bus
>   604  -  Is      0:00.03 /usr/local/bin/dbus-daemon --system
> 6260  -  Is      0:00.03 /usr/local/bin/dbus-daemon --syslog --fork
> --print-pid 5 --print-address 7 --session
> 6262  -  I       0:00.01 /usr/local/libexec/at-spi-bus-launcher
> 6263  -  S       0:00.09 /usr/local/bin/dbus-daemon
> --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork
> --p
> 6259 v0  I       0:00.00 /usr/local/bin/dbus-launch --sh-syntax
> --exit-with-session xfce4-session
>
> Could these be interfering with user access as you hypothesize?
> I don't *know* of any other apps accessing any usb port other than
> the mouse.
>
> Jun  1 17:32:30 breakaway kernel: ugen6.2: <Arduino www.arduino.cc
> product 0x0043> at usbus6
> Jun  1 17:32:30 breakaway kernel: umodem0 on uhub3
> Jun  1 17:32:30 breakaway kernel: umodem0: <Arduino www.arduino.cc
> product 0x0043, class 2/0, rev 1.10/0.01, addr 2> on usbus6
> Jun  1 17:32:30 breakaway kernel: umodem0: data interface 1, has CM over
> data, has break
>
> Is there a document describing the relationship between usb0 and
> ugen6.2, umodem0, usbus6, and uhub3?


Not really no. :( uhub is the 'bus' of USB, but beyond that it gets murky.


> I'm guessing something like
> usbusn is a physical port on uhubm which is a physical multiplexor,
> and ugena.b, umodemx and usbusy are somehow mapped to usbusn, but
> that's a wild guess and probably not useful (to *me*) in making
> progress here.  But inquiring minds always want to know, if for
> no other reason than to fight dementia :-).
>

You might find that devinfo -v gives you enough information to hold
dementia at bay for another day or three... Or not if I've lost it

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Gary Aitken-2
In reply to this post by Gary Aitken-2
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arduino usb/com port issue

Tomasz CEDRO
On Wed, Jun 3, 2020 at 9:10 PM Gary Aitken wrote:

> 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 :-).

Glad to hear it works now! :-)

The old version probably may be still used if its there for some reason :-)

Have fun! :-)

Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"