A quick guide to minicom as a terminal for your embedded Linux system

minicom is a great little terminal application for talking to embedded Linux systems (or pretty much anything else that uses a serial port). It can be tricky to set up at first but, once you're done with that, it's very fast and easy to use. Here's how I set it up:

install and configure

On Ubuntu, you'll need to install the minicom package:


$ sudo apt-get install minicom


By default, minicom will try to do all sorts of stuff for supporting modems. This wastes time and will send various characters down to the connected system's shell, so I recommend disabling all of it. You can do that via the menus but you can also write the following to ~/.minirc.dfl once before starting minicom:


# Machine-generated file - use setup menu in minicom to change parameters.
pu port /dev/ttyS0
pu minit
pu mreset
pu mdialpre
pu mdialsuf
pu mdialpre2
pu mdialsuf2
pu mdialpre3
pu mdialsuf3
pu mconnect
pu mnocon1
pu mnocon2
pu mnocon3
pu mnocon4
pu mhangup
pu mdialcan
pu rtscts No


Note that I typically use /dev/ttyS0 (the first serial port) and you may wish to change that.  If you prefer to run minicom's setup manually, try:


$ sudo minicom -s


...and then save the configuration by selecting "Save setup as dfl" from the menu.

running minicom

I like to have a little launcher icon for minicom which starts the terminal with certain settings. To make one, right-click on a Gnome panel, select "Add to panel..." and then create an "Application launcher". The command that I recommend for the launcher is:


gnome-terminal --title="minicom" -e "minicom -o -w -c on"


That starts minicom in a new gnome-terminal window (titled "minicom"), with additional modem stuff disabled (-o), line wrapping enabled (-w), and color output enabled (-c on). Alternately you can just run:


minicom -o -w -c on


from your shell. minicom accepts commands after you type control+a. Its menu-driven configuration interface is activated by pressing control+a and then "o". For example, to set the baud rate, press control+a and then "o" and navigate to "Serial port setup". To exit minicom, type control+a and then "x". Keep in mind that most Linux systems use 115200 8N1 (115200 baud, 8-bit, no parity) for their serial terminal. Note that, after typing control+a, you will see a red bar on the bottom of the minicom screen with information about the current serial port configuration.

useful features / issues

You can clear the minicom screen at any time by typing control+c. minicom has a handy logging feature that enables you to capture shell output to a file. To activate it, type control+a "l" (lower-case "L") and then enter the name of the destination file (log). After that, type control+a and then "l" again to start or pause logging.

minicom is not particularly graceful with multiple instances of the application. You can use "lsof" to see if someone has the serial port open, for example:


$ lsof /dev/ttyS0


...and stop or kill the offending processes if needed. Also keep in mind that, if you use a USB serial port dongle, the kernel may assign a new device between plugging/unplugging the dongle. Be sure to tell minicom about that (ex: /dev/ttyUSB1 vs. /dev/ttyUSB0). I prefer to use the physical RS232 port on my ThinkPad's docking station rather than dealing with USB dongles.

working with a local git tree and OpenEmbedded

OpenEmbedded works pretty well as a system-level build system but sometimes one needs to develop something locally (for example, a whole application or a set of changes) before committing to a tree that OpenEmedded pulls from.   OpenEmbedded won't really pull local files, and it's uncomfortable to not have revision control either way.

I use a local git tree to achieve this the work flow, which someone else might find useful.  I originally came across this approach here but want to elaborate a bit.

Setup

First, create a git tree for your project. For example:

$ mkdir myapp.git
$ cd myapp.git
$ git init --bare


This sets up the git management stuff that OpenEmbedded will use. Now clone it:

$ cd ..
$ git clone myapp.git myapp
$ cd myapp


...and either start developing there or grab your code from somewhere else.  For example, we can add a file (or several) and push to a new branch, "master".

$ cp /path/to/something/main.c ./
$ git add main.c
$ git commit -a -m "initial commit"

$ git push origin master

Edit (or create) an OpenEmbedded recipe for your app and tell it to fetch from the local git. You need the full path to 'myapp.git', for example '/home/andrey/myapp.git'. In the recipe this looks like:

SRC_URI = "git:///home/andrey/myapp.git;protocol=file;branch=master"


Note the three "/" after "git:".

Change / Build / Test

Now, the workflow is:

1. make some changes to the source code
2. commit and push:
   
$ git commit -a -m "my change"
$ git push origin master


3. in OpenEmbedded, clean and rebuild:
   
$ bitbake -c distclean myapp && bitbake myapp


4. deploy and test your app
5. repeat as needed

When you're happy with a set of changes, commit them to some upstream (or otherwise not local) tree or send a patch to someone.  The advantage is that you are able to work locally and you have revision control for all of your changes, no matter how minor.  In addition, your application builds within OpenEmebdded and has access to dependencies that it may need.  You do have to suffer some time waiting for bitbake to do its thing, but that can be quite fast for small applications or libraries.  You can then switch the "SRC_URI" for your recipe to pull from your remote repository and switch back to the local one when you need to make and test some more quick changes.