I have a Ti processor AM335x on a dev board. right not there are two uart connect to processor. uart0 and uart2
by default, only uart0 was enable, and it was for console. after I enable uart2, I wired my GPS to it so that it should output something if I cat /dev/ttyO2. but there are only some garbage code shows up.
then I wired GPS to uart0, use same command cat /dev/ttyO0 everything works fine. GPS output shows up normally.
then I edit my uEnv.txt to switch my console to uart2, it works. and then I wired GPS to uart2, I can cat /dev/ttyO2 to get everything. But when I wired GPS to uart0. garbage code shows up.
I did use stty to do tty setup, make them all same, still, I can only read from the uart which I connect my console.
I run command dmesg | grep tty , this is the output
[0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0 rw ext4 rootwait verbose debug
[0.234749] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 154m, base_baud = 3000000) is a OMAP UART0
[0.235338] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 155m, base_baud = 3000000) is a OMAP UART2
[0.824084] console [ttyO2] enabled
first and fourth would change base on which uart I put my console on.
Are there any config I missed? why I can only read precise data from the uart I put my console on. and others doesn't work.
any idea would help. Thanks.
This is how I change my code to enable uart2.
linux compile for enable uart2
It turns out that is BAUDRATE problem.
not because I didn't setup right, is because a hardware problem. as soon as I connect my GPS to uart2. the uart2 baudrate would change to 9600 and that gives me garbage output.
if I stty setup the baudrate to 115200 and start read. THEN connect my GPS. I get everything I need with correct format.
Still don't know what issue with GPS, but that's shouldn't be part of this question. so I will close this.
Thank you, #domen without you I won't double check that baudrate.
Related
I have a USB to RS485 converter connected to my linux box:
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
and it is currently st up using
stty -F /dev/ttyUSB0 raw 57600
So when I write some characters to the device (using echo or the similar on the console) I can monitor the TX LED flash and I can clearly identify the characters on an oscilloscope.
However, when I try to read characters from it something weird happens:
I connected a simple teletyper to the RS485 output.
When I type a couple of characters on it I can watch the oscilloscope and I notice the flashing of the RX LED in the converter.
Then I start reading from the device, e.g. using cat /dev/ttyUSB0.
Now whenever I type a character on the teletyper both the RX and TX LEDs flash, and as expected, I can see garbled signals on the oscilloscope as RS485 is only half-duplex. So basically the teletyper is using the lines at the same time as the linux box seems to send something, causing a clash.
When I kill the cat process this stops and everything is fine again.
I have never witnessed this before. What am I missing?
As you were.
It's the line discipline: The linux box has had its echo enabled, so it actually echoed back every incoming character.
The solution is to disable this:
stty -F /dev/ttyUSB0 -echo
previously thank you for watching this post.
I have tried to run linux on odroidxu4 and of course the logs are written through uart2 (this uart seems default in odroidxu4)
But what I'm trying to do is changing the linux to write the logs with uart0 not the uart2.
I tried to change the default uart port from 2 to 0 by modifying the code in common/serial.c in u-boot
and also tried to change the menuconfig in linux like below :
kernel hacking => Kernel low-level debugging functions
choose in "Kernel low-level debugging port" to "Use S3C UART 0 for low-level debug"
But it didn't work.
please let me know if there's another way to change the dafault uart from 2 to 0 that i missed
thank you.
I have a goodix chip for the touchscreen on my tablet PC and even though I compiled the latest kernel module for it, things are not working.
I am using exactly this kernel version with the patched driver:
https://github.com/NimbleX/kernel
For starters, the picture of the said chip is the following:
The DSDT tables contain information regarding the touchscreen.
From what I understand the touchscreen is connected via an I2C serial interface but lshw shows that *-serial is UNCLAIMED.
Nevertheless I can see that the i2c_i801 module for the SMBus controller is loaded.
With the help of Aleksei I was able to determine that the toucscreen is connected to i2c-1 buss and that the controller must use 0x14 or 0x5d address.
Unfortunatelly, i2cdetect doesn't find anything, as it can be seen here.
I created a lengthy gist with the output of the following:
dmesg
DSDT.dsl
lshw
lspci
lsusb
/proc/bus/input/devices
xinput
I know that some of these are redundant and that others are useless but nevertheless it's better to have where to search than to miss something out.
I measured with a multimeter and the chip is powered both when running Windows and Linux so this rules out that I need to somehow tell Linux to power this thing out.
So, what do do next in order to debug this thing?
Hi can you check where pin 5,6 are connected specifically 6 which is reset ic so if that may be reseting the ic. just a posiblity.
I have an embedded linux board with a max3222e RS232 converter. The pins are availlable on soldering pins. I think I've figured out the ground pin, the TX pin and the RX pin. When I connect my pc with a terminal program, I can see the boot logs of the embedde linux system. Also I can stop u-boot with pressing any key. But when I try to use some boot arguments then the characters of the pressed key are not the same like on the pc. For example:
Enter->y
a -> 0
s -> F
Can anybody tell me what's wrong. The serial settings are 115200 Baut 8N1 and no Flowcontrol.
Thanks a lot
Karl-Heinz
What terminal you use ? I use minicom. I have set
`NO PROGRAMING FLOW CONTROL,'
`YES DEVICE FLOW CONTROL`.
And u-boot char is send good.
You try other terminal for example putty for windows ?
Posix requires changing RTS pin on port opening. I want a way to avoid it.
I have no idea why you'd want to do this, but this can be done pretty easily by modifying the linux kernel driver for your serial console so it doesn't toggle RTS. For example, for the 8250-series driver in drivers/tty/serial/8250/ you could change every write to the MCR register (UART_MCR) to ensure that bit 1 (mask is UART_MCR_RTS) is never set.
Since it's abstracted away in userspace, you're out of luck if you want to do this without modifying the kernel driver.
Having the same problem, I'd give it a try by patching the ftdi_sio kernel driver. You just need to uncomment a small piece of code in ftdi_dtr_rts() like this:
static void ftdi_dtr_rts(struct usb_serial_port *port, int on) {
...
/* drop RTS and DTR */
if (on)
set_mctrl(port, TIOCM_DTR /*| TIOCM_RTS*/); // <<-- HERE
else
clear_mctrl(port, TIOCM_DTR /*| TIOCM_RTS*/); // <<-- and HERE
}
and the RTS handshake line is not longer changed upon open() call.
Note, that the uart than might not longer working with RTS/CTS hardware handshake, as long as your modified kernel driver is loaded. But you can still control the state of the RTS handshake line manually by calling e.g.:
int opins = TIOCM_RTS;
ioctl(tty_fd, TIOCMBIC, &opins);
I'd tested this with the Ctrl+A+G command of picocom 2.3a, running Kubuntu 16.04 64 bit and Ftdi FT2232H based usb uart adapter.
You might find more details on this topic here.
A change in the DTR pin can be (eventually) avoided using the command line
stty -F /dev/ttyUSB0 -hupcl
This has the effect of making DTR turn on; and subsequently when the port is opened and closed, DTR is not affected.
Source: https://raspberrypi.stackexchange.com/questions/9695/disable-dtr-on-ttyusb0/27706#27706
And there is code there to do the same thing from python via termios, this can be done before opening the port via pyserial:
import termios
path = '/dev/ttyACM0'
# Disable reset after hangup
with open(path) as f:
attrs = termios.tcgetattr(f)
attrs[2] = attrs[2] & ~termios.HUPCL
termios.tcsetattr(f, termios.TCSAFLUSH, attrs)
The OP was running this on a Raspberry Pi, but I just tried it on Linux Mint on x86_64, it worked. I don't know how RTS is affected.
The reason I find this useful, is for communication with an Arduino Nano - which has a USB-> serial chip on board - and normally the Arduino gets reset every time you open the serial port from linux (rising edge of DTR causes reset). For some applications, this is not a problem, but it's clearly useful to avoid this for other applications, and it's not so easy to remove that tiny capacitor from the Arduino which connects DTR to reset.
You will still get a single reset when the stty command is executed (after plugging in the USB cable). But at least you can then keep opening and closing the serial port after that without further resets.
calling fopen("/dev/ACM0", "r") doesn't require you do do anything:) You may not receive the data you expect though.