TCL is an interpreted scripting language that is procedural with object-oriented language extensions. TCL doesn't run in a TCL virtual machine similar to the way Python or Java works; instead, it's read by an interpreter and executed. The nature of the language is such that each line starts with a declaration or function name. The TCL interpreter uses the name of the TCL function to locate a C symbol and then calls that with the parameters as an array. What makes TCL such an inviting language to use for embedded systems is how well it interfaces with C. It lets you write timing-critical or low-level code in C and do the remaining development in TCL. TCL also has a windowing library, Tk. Tk provides a TCL interface over the X Window environment and uses the object-oriented features in TCL to represent the windowing system elements. Tk is designed to be a thin layer over the underlying windowing kit to keep a small and light library.
You can obtain the software for TCL at http://www.tcl.tk/software/tcltk/download.html. Download the source, and perform a cross-build using these steps:
$ tar xzf tcl<version>-src.tar.gz $ cd tcl<version>/unix $ export tcl_cv_strtod_buggy=1 $ export ac_cv_func_strtod=yes $ CC=<cross-compiler> ./configure -prefix=<board-rfs> $ make $ make install
This compiles TCL with the cross-compiler and puts the resulting code in the board's root file system. These two commands
$ export tcl_cv_strtod_buggy=1 $ export ac_cv_func_strtod=yes
compensate for incorrect assumptions made when cross-compiling; in this case, the configuration script assumes that the cross-compiler's library doesn't have strtod, and it creates this function as part of the build. If these are forgotten, an error similar to this appears during the build process: fixstrtod.c:(.text+0x0): multiple definition of `fixstrtod' TCL with its libraries consumes about 1MB of disk space. Most of TCL's functionality is contained in the libtcl<version>.so library, and there isn't a way to reduce the size of this file by removing functionality when building. Because most TCL programs are small, this overhead is tolerable. A simple TCL program looks like this:
puts "Here are the arguments"
foreach i $argv { puts $i }
To run this code, save it in a file such as aprogram.tcl and do the following:
$ tcl<version> aprogram.tcl
Generally, you'll put the following at the top of a TCL script and mark the file as executable:
#!/usr/bin/tclsh
Use this command to make the file executable:
$ chmod +x aprogram.tcl
When the file is marked as executable, Linux examines this first line, \ runs the program following the #! (called hash bang), and then changes the standard input of the following program to the rest of the current file. That means you can execute the program by running it from the command line like a binary:
$ ./aprogram
It's worth noting that this trick isn't limited to TCL, and this is a common practice in Linux.
You debug in TCL through the incredibly powerful (or primitive) puts statement. The language doesn't have a built-in debugger, so several tools have come into being to support debugging. The most commonly used tool is ActiveState's Komodo debugger, with RamDebugger a close second. Komodo supports remote debugging, which is handy for embedded development. Even so, the best practice is to do as much debugging on the development host as possible, because remote debugging has communication and resource overheads that can overwhelm some hardware platforms. Plus, debugging locally is quicker even if the target device is a powerful computer with fast communication. If you're the daring sort, pick the latest release and download it. The file is large, about 50MB, so be prepared to wait depending on the speed of your network connection.
The shell used on most Linux system is Bash. It's a powerful language for development in and of itself. As with all of Linux, there are many choices for a shell, including ash, nash, dash, and tcsh. Each shell has its merits and drawbacks, and all offer the same core features with respect to executing files and redirecting input through pipes and files. Bash works primarily by executing commands in the file system and using piping to move data between programs. In this way, Bash is easily extensible and can work with existing programs with ease, because the data output to the console can be filtered through a text-handling program (like awk) to be parsed before being sent to another program. The glue that holds shell scripting together as a language is the simple notion of pipes (|) and redirection (>, <). When you use a pipe, the output of one program is attached to the input of another. The concept of attaching input and output works because Linux programs follow the convention of reading input from a standard in file and writing output to a standard out file. These files are opened for programs automatically, and most programs stick to using them for input and output. The redirection symbols write the standard output of a program to a file (>) or read a file and pass the data to the standard input. Shell scripts don't execute code quickly, but it's easy to write code in C or another language that does run quickly. Thus programs are rarely written as 100% shell scripts, but rather use the shell scripting language as a way to integrate various programs. One of the nicest things about shell scripting is that each program can be independently tested and verified easily; reuse is also more practical, because the program as a whole can be placed in another project wholesale.
Embedding the shell on an embedded device isn't a demanding activity. The Bash shell is statically linked (so it runs under most circumstances); and all distributions come with a shell or some sorts, because this is necessary to run the startup scripts for the system. Using what comes with the distribution is usually a good approach, unless you need a shell other than the default.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Leo Crage at 02012010
1. Explanation of the Embedded Linux development process
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.