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 ?
Related
I'm trying to send files over a half-duplex interface (RS-485) between a box PC running debian (4.19) and a SBC with an im6xDL.
Thanks to this community I can successfully transfer simple data between the units using picocom or by echoing/reading.
The box PC supports half-duplex RS-485 natively and has automatic RTS functions so that you can read/send data without any issue. The SBC on the other hand needs to be toggled to change into RX or TX mode.
This turned out to be a problem when I tried to send files from the box PC to the SBC.
On the box PC:
picocom /dev/ttyUSB0 -b 9600 -fn
C-a,C-S
***file: /home/user/test.txt
Transfer incomplete
*** exit status: 128
On the SBC
picocom /dev/ttymxc2 -b 9600 -fn -et
C-a,C-r
Terminal ready
�000000
As you can see something is terribly wrong, it is like it cannot interpret the bits when a file is being transferred.
My questions:
Is it possible to send files from the command line in half-duplex systems? (The SBC needs to be in RX mode the entire time).
Is there another way to achieve this that is more intuitive?
As always, thanks for the help and support :)
/W
See here:
Pymodbus - Read input register of Energy meter over rs485 on uart of raspberry pi3
The solution I presented there using pylibmodbus should work for any hardware with UART and one or two GPIO lines accessible from user space in Linux.
If, on the other hand, what you want to do is use something like picocom or minicom then you can take a look at the hardware-only solution using a 555 timer.
Of course, if prototyping circuits is not for you, you can always buy a USB to RS485 with half-duplex support. You have many available but those based on the MAX13487 IC seem to work very well.
EDIT: The solution using the 555 timer is not in the post I linked above but here together with some more background material on half-duplex RS485 links: RS485: Inappropriate ioctl for device
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
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.
I have a USB Bluetooth dongle that I am trying to use in order to extract information from an ELM327 OBD-II interface.
I am trying to communicate with the ELM327 through PuTTY. According to the ELM327 documentation, I need to use baud rate 38,400 if the PP 0C pin hasn't been changed or 9,600 if pin 6 = 0 V.
I tried setting PuTTY according to the Device Manager details with:
Baud rate 9,600 or 38,400
8 data bits
No parity
1 stop bits
No flow control
When I open PuTTY, the window is blank, and I cannot send commands to the device.
What could be the issue here?
Your problem might be with PuTTY and Windows 10. Neither PuTTY nor Hyperterminal allowed me to connect to my ELM327 on Windows 10 (I am using the USB connection for talking to ELM327). It might be some kind of problem of these software on the latest version on Windows.
Looking for a similar software that works well on Windows 10 I found RealTerm. You can download it from this link. A brief tutorial about how to use RealTerm is available here (pay attention to the procedure to open a serial port by clicking twice on the button "open", an how to send commands from the send tab).
After downloading it, just configure your serial connection with the values you were using:
Baud rate 38,400 (or 9,600)
8 data bits
No parity
1 stop bits
No flow control
Also, do not forget to add a CR (carriage return) at the end of the commands you send to the ELM327, if you forget it, the ELM327 will ignore the commands. You can do it by clicking on the EOL options shown in the figure below.
This solved my problem and now I am able to talk to the ELM327 and receive its answers, e.g. the commands atz returns the ELM327 version. The OBD2 command 0100 returns the PIDs available on a car's ECU. I don't know why but the CR is shown on the RealTerm display and hides some characters (as it happens with the 'a' of the "atz" command in the figure).
I hope this helps you.
I have a Linux USB HID device (a Hama MCE), and I can read its events manually by reading cat /dev/input/event7 and cat /dev/input/event8. Whenever I press a key on the device, a few bytes become available for reading with one of the cat commands above. I have a default installation of Ubuntu Jaunty 64-bit desktop on the machine.
I think I can write a parser to interpret the bytes emitted by the device, or I'll use libhid if it's more convenient.
My questions are:
How do I prevent the text-mode virtual consoles from receiving some of the key presses on the device as normal keypresses? As of now, some device keys result an Enter, a BackSpace, a PageUp or numeric keypad numbers.
Similarly, how do I prevent the X server from receiving keyboard and mouse events from this device? I have several USB keyboards and mice connected to the computer. I want the X server receive events from all of them, except for this device.
How do I set up that whenever the device gets connected to the computer, the command /usr/local/bin/keydumper /dev/input/event7 /dev/input/event8 (or one command for each /dev/ path) would get run, with the proper /dev/ paths substituted in the command line?
Answering my own question based on answers from the Linux USB HID driver developers:
Question 1. and 2.: Do
ioctl(open("/dev/input/event7", O_RDONLY), EVIOCGRAB, 1);
As long as this filehandle is open, the events generated would go only
to this filehandle (not to other open()s of the same device or to the
system keyboard or mouse event pool). At most one process can hold a
successful EVIOCGRAB at a HID device at a time. Lirc can be configured
to do an EVIOCGRAB.
Question 3.: Configure udev to start the program once the device is connected.
I do not have enough points to comment sadly.
If you are looking for the definition of EVIOCGRAB try
#include <linux/input.h>
I think solution for all questions can be writing own filter device driver, or custom driver for your device. I know such a thing (filter device driver) is available on windows so something similar can be on Linux. In that filter device driver you could block all unwanted events from the target device that you wish to block, I don't really get 3 question so I don't know how to answer for that.