On Wed, 16 Oct 2024, Ramiro Aceves wrote:
netbsd-raspa4$ { sleep 1; stty -f /dev/ttyU0 9600 raw clocal cread
-crtscts; } & cat -u -v /dev/ttyU0
stty: /dev/ttyU0: Resource temporarily unavailable
Wrong device--use /dev/dtyU0.
OK, the only thing I can think of is that there's something which cu is
setting on the serial-port, but, which we're not: for example, there's
mdmbuf and cdtrcts which I haven't seen on Linux (but, -clocal should've
taken care of both of these..). Let's use the same settings cu uses:
1. Run your cu command:
$ cu ...
2. While cu's running, copy the settings:
$ stty -f /dev/dtyU0 -g > /tmp/cu-set.txt
3. Stop cu, run cat with saved cu settings:
$ { sleep 1; stty -f /dev/dtyU0 "$(cat /tmp/cu-set.txt)"; } & hexdump -C
/dev/dtyU0
OR, using kre's method:
$ (stty "$(cat /tmp/cu-set.txt)"; hexdump -C) < /dev/dtyU0
and if the device is constantly spewing data at the serial port, you should
see it now.
-RVP
PS. you wrote:
[...] and I can see all bytes returned by the GPS module when asked with the
@@Ea command by the PIC microcontroller.:
Does this mean that you have somehow to trigger the GPS module with a command
before it'll send data? If yes, and you're ending that command using cu, then
you'll have to do the same when using cat/hexdump. Otherwise, you'll just sit
there until the end of time (more realistically, until the power-supply goes
off)
waiting for data which'll never come...
