Computing > Embedded Computing


(1/3) > >>

I just can't seem to get my @rse in gear as regards UART. I understand the principles but need, actually, to do it!

Obviously, I need two "things" that can communicate with each other using UART and I need one, at least, to have a display so that I can see what's happening.

My idea is to use the RPi (easily connects to screen, keyboard, etc.) and ... well, something.

Does anyone have any ideas how I can get started please including suggestions of to what "thing" I can connect the RPi for practice.


You can talk to yourself by simply wire Tx-->Rx. If you have a FTDL or SIL USB-UART adapter you can use that to talk to a terminal on the PC. If you do that you'll be surprised that you actually see messages floating by. Especially during boot. The Kernel uses the build in UART for messages.

Configuring the build in UART (/dev/ttyAMA0)  for bash usage:
# Setup ttyAMA0 to 115200 baud, 8n1, no flow control
stty -F /dev/ttyAMA0 115200 cs8 -cstopb -ixon -ixoff -crtscts -hup -parenb -echo

If you want do send messages from bash a simple
echo -ne "Hello World\n" > /dev/ttyAMA0

receiving is can be done as well:
cat /dev/ttyAMA0

Disabling the Kernel using the UART depends a bit on the Distribution. But changing the /boot/cmdline.txt is a starting point (for some reasons removing the tty0 parts didn't last, so I told the kernel to use tty1). This is from Archlinux:
root=/dev/mmcblk0p2 rw rootwait audit=0 console=tty1 kgdboc=tty1 rootfstype=ext4 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 elevator=noop

Eventually you need to stop some services to really tell the kernel you really don't want any kernel messages there like getty@tty0.service (also changed to tty1). But that depends on the used distribution.

Maybe I did something wrong and others have better solutions. But it works for me ;-)

Thank you.

It's very kind of you to post but I don't understand half (more?) of your post. Perhaps I'm not ready for serial comms.

No worries! Its not that complicated as it look. It is just that the RasPi occupies the UART. If you skip that, that reduces to simple read/write instructions. Very much like the keyboard or screen.

Maybe using the bash is a bit exotic. If you use C, Python... you can use any example you‘ll find and it will work on the RasPi just fine.

If you have a Scope or logic analyzer with an UART decoder build in you can also use this to see what‘s send.

Most Pi boards are a poor choice for mucking around with serial comms on their GPIO headers.  See
Before Pi 4, any Pi with Bluetooth had the full spec. UART allocated to the Bluetooth chip, and using the remaining mini-UART requires you to set a fixed clock frequency, crippling performance, to get a stable baud rate.  Also its got limited handshake lines which are a PITA to enable.  The PI4's got plenty of full UARTs,  so you can avoid the mini-UART, but its relatively high cost makes it a poor choice for experimenting as any mistake has a high probability of killing it.   Also 3.3V levels + no 5V tolerance isn't experiment-friendly.

A USB<=>serial adapter is a much better choice - unless you are really unlucky/careless you are unlikely to damage the host computer.   As a bonus, some logic leve ones (i.e. without RS232 level converter/line drivers) have fully customizable I/O voltage levels.   N.B. RS232 line level signals are inverted with respect to logic level UART signals.

There is some benefit in using a real COM port on a PC with legacy ports, as RS232 compliant ports can tolerate up to +/-25V signal levels, are short-circuit proof, and dont have a vulnerable 5V Vbus supply so the odds of damaging the PC are minimal.  Add a MAX3232 or similar logic level <=> RS232 level converter if you need 5V or 3.3V logic levels.

As for what to connect to,  the RX and TX pins on just about any Arduino with a seperate USB interface chip are connected to the MCU's UART.  Most GPS modules have a UART interface.  Most consumer GPSes use a NMEA-0183 serial interface which is quasi-RS232 compatible.  Otherwise it depends on what legacy hardware with a UART interface you (a) have available, and (b) are willing to put some effort into hacking.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version