Step05 – UART

Using the UART on the BeagleBone is pretty simple. Using our previous knowledge of GPIO settings, we can navigate around the filesystem and setup the GPIO pins for the UART to mux the pins to the UART io.

I’m using UART1 (To which I have a modem connected). So to test the connections, I need to setup the UART IO and then write some data to the UART and read some data from the UART:

The pins we need to setup are easily named for us this time – uart1_rxd and uart1_txd:

[code]root@beaglebone:/sys/kernel/debug/omap_mux# cat uart1_rxd

name: uart1_rxd.gpio0_14 (0x44e10980/0x980 = 0x0037), b NA, t NA
signals: uart1_rxd | mmc1_sdwp | d_can1_tx | i2c1_sda | NA | pr1_uart0_rxd_mux1 | NA | gpio0_14

root@beaglebone:/sys/kernel/debug/omap_mux# cat uart1_txd

name: uart1_txd.gpio0_15 (0x44e10984/0x984 = 0x0037), b NA, t NA
signals: uart1_txd | mmc2_sdwp | d_can1_rx | i2c1_scl | NA | pr1_uart0_txd_mux1 | NA | gpio0_15[/code]

Both these pins are currently muxed to their GPIO functions (MODE 7). So we need to use the UART io (MODE 0) instead.

As we know, we can simply set the mode:


root@beaglebone:/sys/kernel/debug/omap_mux# echo 0 > uart1_rxd
root@beaglebone:/sys/kernel/debug/omap_mux# echo 0 > uart1_txd
root@beaglebone:/sys/kernel/debug/omap_mux# cat uart1_rxd

name: uart1_rxd.uart1_rxd (0x44e10980/0x980 = 0x0000), b NA, t NA
signals: uart1_rxd | mmc1_sdwp | d_can1_tx | i2c1_sda | NA | pr1_uart0_rxd_mux1 | NA | gpio0_14

root@beaglebone:/sys/kernel/debug/omap_mux# cat uart1_txd

name: uart1_txd.uart1_txd (0x44e10984/0x984 = 0x0000), b NA, t NA
signals: uart1_txd | mmc2_sdwp | d_can1_rx | i2c1_scl | NA | pr1_uart0_txd_mux1 | NA | gpio0_15[/code]

We can now see that the pin modes are both uart (see uart1_rxd.uart1_rxd,  and uart1_txd.uart1_txd).

The serial ports for the OMAP CPU are mapped to /dev/ttyO0 through /dev/ttyO5. /dev/ttyO0 is dedicated to the on-board FTDI chip providing the console output that we’re putty’ing into so we can’t use that anyway.

Now that we’ve setup the UART, we can check to see it work, again from the BASH shell. You can use stty to setup the comms link. Google stty man page if you need a hand with it. You can check the settings of a serial port (console) by typing in the following:

[code]root@beaglebone:/dev# stty -F /dev/ttyO1

speed 9600 baud; line = 0;
-brkint -imaxbel[/code]

To set the speed for example, here we set it to 38400 baud:

[code]root@beaglebone:/dev# stty -F /dev/ttyO1 38400[/code]

In order to see what is transmitted and what is received, we need to cat the serial port whilst also writing to it. We need multiple consoles, and as we cannot Ctrl+Alt+Fn to access virtual ones, we need to connect another session of PuTTY. If you’ve been using the serial port connection so far to PuTTY into the beaglebone you’ll now need to use an ethernet cable to establish a connection for PuTTY to give you another console. Simply type ‘ifconfig’ to get the IP address of your beaglebone on your network after you’ve plugged in the network cable and then PuTTY to that IP address.

In one console we will keep an eye on the bytes received through the COM port, by typing:

[code]root@beaglebone:~# cat /dev/ttyO1 [/code]

I’m connected to a modem through this serial port, so the easiest thing for me to try is the ubiquitous AT command to hopefully get an OK response.

In the second console we send data from the serial port by typing:

[code]root@beaglebone:/sys/kernel/debug/omap_mux# echo "AT" > /dev/ttyO1[/code]

Hopefully (cross-fingers) we get in the first window:

[code]root@beaglebone:~# cat /dev/ttyO1






The AT command set for this modem is set to verbose which means the reply is actually <CR><LF>OK<CR><LF>! Success anyway! We get comms!

Serial Comms in C


8 thoughts on “Step05 – UART

  1. Sören


    Thanks for this page.

    However, there’s still one problem. When I send data from the terminal
    to the BBB I see the output (cat /dev/ttyO1) but also the data is echoed
    back to the terminal.

    How can I prevent the BBB from echoing every received message?

    Thanks a lot.

      1. Jimit

        Hi Brian,
        I am facing the same problem I.e. the BBB echoes whatever it receives from the terminal back to it. I couldn’t find anything helpful with stty commands. Were you able to resolve the issue?

  2. Dusan


    thank you for this tutorial. It is the first one that answered some of my questions, but not all, at least not the most important ones.

    You could maybe help me.

    Imagine that you have something connected via UART (e.g. modem that you mentioned, or bluetooth stick or whatever) to your board, and that you DON’T KNOW WHEN you will receive a signal from that device on rx pin.
    You write a C/C++ application that will be executed on your board (on embedded Linux) and there is a function in your code that should be invoked ONLY when the board receive a signal on rx pin of the UART.
    Since you DON’T KNOW WHEN that signal will come, you probably need a kind of interrupt that will notify you somehow when it happens, so that you could invoke your function.

    I am a guy who worked with real-time operating systems and used interrupts, so I think that way. Am I wrong this time? 🙂

    Thanks in advance!

    1. Brian_S Post author

      When you have the Linux operating system running you need to think a bit differently about, for example, waiting for UART traffic which you would normally have in an interrupt service routine.

      Most of the time you need to block, waiting for activity. In your program you can call fgetc() on the serial port and your program will wait until data arrives before continuing. You can of course put this in a new thread if you don’t want to block your whole application and this will essentially be acting like an interrupt, although you’re essentially reading out of a software FIFO and not the hardware registers, Linux has already done that work for you.

      Really, you need to define the application requirements and then you can start fleshing out what is going to block and what will carry on (if anything).

      It’s worth asking this sort of question on Stack Overflow or similar, there’s an incredible pool of talent there waiting to help given a good enough question they’ll give you excellent ways of getting the right results.

      Best Regards, Brian.

      1. Dusan

        Hi Brian,

        thank you very much for the advice!

        One more question. I saw some tutorials about Raspberry board on this site. I consider to buy a BeagleBone. I would do simple projects, practice actually. Is there any point, in your opinion, to buy BeagleBone for that purpose, nowing that it is almost 3 times more expensive? Could it do better things…?

        Best regards


        1. Brian_S Post author

          Well, it depends what you need. The Rapsberry-Pi is a great board and is brilliant at being a media server or similar. It has pretty limited IO capabilities, but generally for small projects you can get by. Actually, now the B+ model has been released the IO is less of an issue because there’s more pins available.

          The Beaglebone Black is also a brilliant board, has on-board eMMC so doesn’t need an SD Card to boot. It also has the PRUSS system which can be vital if you need real-time IO capabilities. This basically means the processor has two additional 2000MHz processors directly connected to the IO that can be used to IO intensive tasks.

          So really, it depends on the application. But simple stuff is easy to do on the Rapsberry Pi, but IO is a bit more limited.

  3. Rahul Sharma

    I am using beagle bone black and when I simply tried to echo the port from home I couldn’t. But after following this post I tried to access the directory omap_mux but there was no such directory in /sys/kernel/debg folder. May be the path is different for beaglebone black. Could you please help mein this matter.

Leave a Reply