Hey,
I'm working on a Raspberry Pi using Raspbian, but I'm not sure if my problem is HW related. I'm writing a program that communicates with an external device via uart. That device is connected via USB and has an FTDI chip. The problem is, that my program cannot open a connection to that external device. I get a permission denied error. If I run the program with sudo it works.
The crazy thing is, that I can echo to the device file, and I can cat it without sudo. I'm using a Segger JLink probe to flash firmware to that device. The program that communicates with the probe also doesn't work without sudo on the raspberry, while not making any problems on any other Linux system that I've heard of.
To add insult to injury, after a fresh install everything worked. I rebooted, ran my tests, everything worked. This morning, I made a small change to the source code, and wanted to test it again, and I'm seeing the problem again. I've had this a lot in the past. I ignored it mostly because using sudo was an option, but now I'd like to clean that up. I've seen this with two different Raspberries over multiple fresh installs, sometimes this behavior is shown from the beginning (i.e. immediately after installation), sometimes it starts after a while. There is a third one that hasn't shown this behavior a single time so far. All Raspberries are 4B+ models.
Permissions are alright:
All of this is completely nonsensical, and I googled myself to death, not finding any hint. If anyone has a creative idea what could cause this, I'd be very happy.
Short summary:
echo and cat can access the device, my software cannot (except when used with sudo). Another program and another device, that are commonly used in embedded development also exhibit this behavior. These problems only happen on 2 out of 3 pies, and they randomly start occurring at some point, possibly immediately after a fresh installation.
I'm working on a Raspberry Pi using Raspbian, but I'm not sure if my problem is HW related. I'm writing a program that communicates with an external device via uart. That device is connected via USB and has an FTDI chip. The problem is, that my program cannot open a connection to that external device. I get a permission denied error. If I run the program with sudo it works.
The crazy thing is, that I can echo to the device file, and I can cat it without sudo. I'm using a Segger JLink probe to flash firmware to that device. The program that communicates with the probe also doesn't work without sudo on the raspberry, while not making any problems on any other Linux system that I've heard of.
To add insult to injury, after a fresh install everything worked. I rebooted, ran my tests, everything worked. This morning, I made a small change to the source code, and wanted to test it again, and I'm seeing the problem again. I've had this a lot in the past. I ignored it mostly because using sudo was an option, but now I'd like to clean that up. I've seen this with two different Raspberries over multiple fresh installs, sometimes this behavior is shown from the beginning (i.e. immediately after installation), sometimes it starts after a while. There is a third one that hasn't shown this behavior a single time so far. All Raspberries are 4B+ models.
Permissions are alright:
Code:
neuro@raspberrypi:~ $ ll /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Sep 7 08:25 /dev/ttyUSB0
neuro@raspberrypi:~ $ groups
neuro adm tty dialout cdrom sudo audio video plugdev games users input render netdev lpadmin gpio i2c spi
neuro@raspberrypi:~ $ echo hi > /dev/ttyUSB0
neuro@raspberrypi:~ $ cat /dev/ttyUSB0
^C
All of this is completely nonsensical, and I googled myself to death, not finding any hint. If anyone has a creative idea what could cause this, I'd be very happy.
Short summary:
echo and cat can access the device, my software cannot (except when used with sudo). Another program and another device, that are commonly used in embedded development also exhibit this behavior. These problems only happen on 2 out of 3 pies, and they randomly start occurring at some point, possibly immediately after a fresh installation.