Linux Compile for Enable Uart2

enable uart2, but reading from it is not right

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.

ttyS1/uart1 initialised but not accessible through /dev/ttyS1

Well a nice chap over on the Linux board solved it, I need to insert a mknod /dev/ttyS1 c 4 65 somewhere.

Quite why this (apparently) happens for ttyS0 or whichever port is console I don't know, but right now all that matters is it works!

Comments / further info on the reasons why would be welcome for my own knowledge / future generations.

writting 0D 0A insted of 0A when I tried to write into uart

writting 0D 0A insted of 0A when I tried to write into uart

That appears to caused by a termios (mis)configuration that is inappropriate for your situation. The termios layer is capable of translating/expanding each occurrence of \n to \r\n for output (i.e. the ONLCR attribute, which is typically enabled by default).

The following code configures UART port.

Your program accesses a serial terminal (i.e. /dev/tty...) rather than a "UART port". There are several layers of processing in between your program and the UART hardware. See Linux serial drivers

Your initialization code is properly implemented (i.e. per Setting Terminal Modes Properly), but it is just the bare minimum that sets only the serial line parameters to 115200 8N1 and no HW flow control. Absolutely no other termios attributes are specified, which means that your program will use whatever previous (random?) settings (such as the ONLCR attribute), and may occasionally misbehave.

The most important consideration when using a serial terminal and termios configuration is determining whether the data should be handled in canonical (as lines of text) or non-canonical (aka raw or binary) mode. Canonical mode provides additional processing to facilitate the reading/writing of text as lines, delimited by End-of-Line characters. Otherwise syscalls are performed for an arbitrary number of bytes. See this answer for more details.

Your output data appears to be not (ASCII) text, so presumably you want to use non-canonical (aka raw) mode. For raw output, your program should specify:

ttyurt.c_oflag &= ~OPOST;

This will inhibit any data conversion on output by termios.

But your termios initialization is also incomplete for reading.

For a proper and concise termios initialization for non-canonical mode, see this answer.

If instead you need canonical mode, then refer to this answer.

BeagleBone Black: how to activate UART 4 or 5 to enable RS-485 communication

Finally, What I have done to fix the issue is:

• use ttyS4 for the RS-485;
• use can1 for CANbus communications.

The /boot/uEnv.txt is very simple then, simply do not set any UART, keep it as default. Here it is:

$ cat /boot/uEnv.txt

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.19.94-ti-r71
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo
#uboot_overlay_addr3=/lib/firmware/BB-UART5-00A0.dtbo

###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=0
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

---

Related Topics