I would like to run a programme or script that I wrote on start-up of the Pi - on a separate thread(process) / background.

I would love to do this with MONO application but any other examples would be great too.

Basically all I need it to do is dump UART data into a file.

1 Answer 1


Threads are within one process, so I guess you mean separate process that runs in the background (like a deamon process)?

Anyway, adding '&' at the end of the command will make it detach from the terminal and run as background process. This works for everything, executable and script.

Depending on the format you want it stored (the uart data), you probably can find a script/executable or just a unix command utility that will do it for you.

If the data is pure ASCII:

 cat /dev/[your serial device]

should already work, add a redirection and the & you'll get:

 cat /dev/[your serial device] > /tmp/uart-output.txt &

If you need to setup your serial port first, you can use the command stty for this purpose.

Please, check the stty man page for a truckload of parameters and options.

If you don't want to use cat or you need to convert/format the data (to hex for example because it is not ASCII only) this perl script will give you a good start, although using cat and a couple of other utils, you should be able to get similar results:

# Author: Bruce S. Garlock 
# Date: 2002-09-11 
# Requirements: Device::SerialPort 0.12 (from cpan) 
# Version: 0.1 
# Description: This perl script is for logging of data from a serial 
# port, to a specified logfile. The logfile can then be parsed with 
# other programs for reporting purposes. 
# This program was written for specifically logging Multitech's 
# MTASR2-203 T1 Router. The router outputs text to the command 
# port with 57.6k, 8-1-N, and No flow control. 
use Device::SerialPort 0.12; 
$LOGDIR = "/var/log";     # path to data file 
$LOGFILE = "router.log";  # file name to output to 
$PORT = "/dev/ttyD015";   # port to watch 
# Serial Settings 
$ob = Device::SerialPort->new ($PORT) || die "Can't Open $PORT: $!"; 
$ob->baudrate(57600) || die "failed setting baudrate"; 
$ob->parity("none") || die "failed setting parity"; 
$ob->databits(8) || die "failed setting databits"; 
$ob->handshake("none") || die "failed setting handshake"; 
$ob->write_settings || die "no settings"; 
# Send a string to the port 
sleep 1; 
# open the logfile, and Port 
open(LOG,">>${LOGDIR}/${LOGFILE}") ||die "can't open smdr file $LOGDIR/$LOGFILE for append: $SUB $!\n"; 
open(DEV, "<$PORT") || die "Cannot open $PORT: $_"; 
select(LOG), $| = 1; # set nonbufferd mode 
# Loop forver, logging data to the log file 
while($_ = <DEV>){ # print input device to file 
   print LOG $_;

undef $ob; 

If I messed up the conversion to html, here is the link logger.pl

If you saved this script as logger.pl the command:

logger.pl &

should make it detach and run as background process, or

perl logger.pl &

in the case you don't make it executable.

  • Excellent - I actually found stty and cat on other pages- But the expected data is not showing up- Just garbage... I use a normal serial interface and the expected values come out. The baud is correct and I can do other things on the serial port. Any way. Great answer! the & is a new to me. How do i terminate that process then?
    – Piotr Kula
    Dec 7, 2012 at 9:20
  • you need to know the PID (Process ID) you get that by using ps (or use ps | grep [process name]), the PID is in the first column of the output. When you know the PID, use kill [PID] to kill the process. Alternatively you can use the killall [process name]. The kill command can send different signals, for different purposes, without a specific signal it send SIGTERM. If you have a process that does not listen you have the ultimate weapon against it the -9 (SIGKILL) signal, but it kills a process in a crude way. Check man kill, man ps etc for more info.
    – ikku
    Dec 7, 2012 at 11:49
  • 1
    About the data coming out as garbage: the data expected is ASCII only, or binary? You could use miniterm, to try different configuration parameters before using, one of the described final options above. With miniterm you can easily change parameters and see the effects (miniterm is a serial terminal program). If you have some program that works with the device (it communicates) you can use a serial sniffer to see what is going on, slsniff is a good choice. Here other options.
    – ikku
    Dec 7, 2012 at 11:59
  • Thanks! Your answer is really helpful you deserve many votes from me! I will try miniterm and your other recomendations. And I can run this process at boot time.
    – Piotr Kula
    Dec 7, 2012 at 12:40
  • And I can run this process at boot time, is a question? miniterm is not useful to use at boot time, it needs user input, you can only use it to try to make some sense of the data you're receiving. After when that is under control, you need to go for one of the options described in my original answer.
    – ikku
    Dec 7, 2012 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.