Effective Scripting in Embedded Devices Steve Bennett WorkWare Systems http://www.workware.net.au/ [email protected] April 2010 ABSTRACT For these systems, an application that is 10MB in size is going to take a fairly substantial amount of RAM and flash. It is Scripting can be a valuable tool for embedded systems, but possible that this is acceptable for the primary application—the when is it most appropriate and which scripting languages are raison d'être of the device—but if the application simply best under what circumstances? provides an ancillary management function, then likely not. This paper provides answers to these questions, along with case Consider a common requirement for these embedded devices; studies of situations where scripting has been used effectively in SNMP support. The simplest and most common approach is to embedded systems. use net-snmp. On Linux, this is a simple matter of compiling and installing. So what is the size of the installed application? 1. INTRODUCTION Here are the sizes from a typical device. Anyone who has written a short shell script to rename some -rwxr-xr-x 1 563688 14:35 /lib/libnetsnmp.so.5 files, send a signal to a running process or to extract and -rwxr-xr-x 1 268380 14:35 /lib/libnetsnmpagent.so.5 reformat some messages from an apache log file knows that -rwxr-xr-x 1 121104 14:35 /lib/libnetsnmphelpers.so.5 there are tasks which are far more easily achieved with a -rwxr-xr-x 1 446488 14:35 /lib/libnetsnmpmibs.so.5 scripting language than with C or C++. Many embedded -rwxr-xr-x 1 22900 14:35 /bin/snmpd systems can benefit from the use of one or more scripting languages, even those that are relatively slow, have limited This is 1.3MB just for SNMP support. While this doesn’t seem resources or no-MMU. like much on a 50GB hard disk, or even a 1GB SD card, it quickly adds up for a device with only 8MB of flash. Creating an application in an embedded system generally involves accepting more tradeoffs and compromises than Once a number of other common components are added, the creating an application for a server environment, which is system has a moderately large footprint even before any typically larger, faster and less mobile. As an embedded product-specific components have been added. developer, it is always necessary to design a total solution to match the constraints of the environment, such as CPU speed, openssh server 241K memory, flash, reliability, response time requirements, and cost. libssl/libcrypto 1177K bash 513K Different scripting languages have different strengths and iptables 115K weaknesses—possibly more so than compiled languages since strace 250K most compiled languages strive to be general-purpose tcpdump 247K languages, whilst many scripting languages do not. By choosing an appropriate scripting language and using it in appropriate Larger applications means more RAM, more flash, larger ways, building an embedded product can be significantly faster upgrade images and increased application load times. and simpler. In the context of choosing a scripting language for an embedded system, size is one of the most important factors. The following 2. WHAT IS EMBEDDED ANYWAY? graphs gives a rough estimate of the size of several popular Or, Size Really Does Matter scripting languages as a percentage of space available for 1 Our company works with a wide variety of embedded applications on a device with 8M of flash . platforms. Some developers consider a Core 2 Duo with 1GB of RAM to be “embedded” if it has a microATX form factor with Perl no screen and keyboard, but that is a far cry from the typical Python embedded platform we work with. Tcl 8.4 Here are some fairly typical embedded platforms. bash 1. IXP425 533Mhz, 128M RAM, 32M Flash. ash 2. Coldfire m5282 66Mhz, 16M RAM, 4M Flash, SD card. TinyTcl 3. Microblaze soft CPU 100MHz, 32M RAM, 16M Flash. lua Jim Permission to make digital or hard copies of all or part of this 0% 50% 100% 150% work is granted without fee provided that copies are reproduced in full and bear this notice. To copy otherwise requires prior specific permission. 1 Includes only minimal language core. Excludes non-core packages, modules. Assumes 50% compression (e.g. squashfs) 3. SIZE AND SPEED ARE RELATED 4. BUILDING A REAL EMBEDDED Consider the following simple test: PRODUCT puts "hello world" Our company spends a significant amount of time helping customers build and deploy real products. Almost all of these hello.tcl products run embedded Linux because of the fantastic leverage to be gained from a flexible kernel ported (and portable) to many platforms, and a large set of open source applications that $ time tclsh hello.tcl are available with minimal work. real 0m0.270s However, from the point of view of our customers, the most Intel(R) Core(TM)2 Duo CPU @ 2GHz, 2GB RAM important aspect of the product is how it is differentiated, both in hardware and in software. This requires the development of Not too bad. 270ms. custom applications for the product. I often see two different approaches to building applications for $ time tclsh hello.tcl embedded devices. real 0m0.043s 4.1 The embedded minimalists Intel(R) Core(TM)2 Quad CPU @ 2.33GHz, 4GB RAM These are the developers who will write everything in C from Much better. Only 43ms on this faster system. scratch to make it as small as possible. Every significant program contains a linked list implementation, a recursive $ time jimsh hello.tcl descent parser, a configuration file parser and a TODO item, real 0m 0.03s ‘should use a hash table here but a fixed size array will do for now’. No 3rd party libraries are used because the application XScale-IXP42x (v5b) @ 533MHz, 128MB RAM contains proprietary IP and all the useful libraries are GPL. These projects spend lot of time tracking down crashes (I hope Now we're getting somewhere! An embedded system can do it you have an MMU!) in newly written, poorly tested code. in only 3ms running Jim Tcl. Remember Greenspun’s Tenth Rule [2]: $ time jimsh hello.tcl Any sufficiently complicated C program real 0m 0.01s contains an ad-hoc, informally-specified, bug- ridden, slow implementation of half of a XScale-IXP42x (v5b) @ 266MHz, 32MB RAM scripting language. This slower system managed it in 1ms! 4.2 The application porters Why is this so? The big systems are running recent versions of On the other hand are the developers who don't really know Tcl, 8.4 or 8.5. These have lots of capabilities, but even starting anything about embedded systems. They just need to port their the interpreter requires loading large binaries and/or shared custom application from a Linux server (or Windows!) to the libraries and parsing many initialisation files. The embedded embedded system. So they start by trying to compile boost, php, systems are running a tiny version of Tcl. Around 150KB. The postgresql and 10,000 lines of custom C++ which resists being time to load and initialise the interpreter can be significant. cross compiled, assumes little-endian byte order and accesses fields in structures at odd byte boundaries. The questions to the Now it can be argued that there are many reasons why these mailing list usually start, ‘I can't seem to get busybox to results can’t be used directly. compile postgresql. I just get 'elf2flt: ld.real not found’. Once the binaries and libraries are in the page cache, they will Can someone please post the binaries’. run much faster on subsequent invocations. The time to load from disk is significant compared to running Given the choice, I prefer the former approach to the latter. But from flash or ramdisk. does it need to be so hard? C is a great language for systems However experience has shown, that in real-world use, a small programming. Its ubiquity and maturity means that porting a application that loads quickly and does small job is far faster well-written C application to an embedded target is often and less resource-intensive than a larger application doing the reasonably straightforward. But some of the core weaknesses same thing. Consider an application written in Perl, Python or of C are string handling, built-in data structures (i.e. none) and Tcl 8.5 on a 266MHz ARM system with 32MB of RAM. You memory management. Yet, these are exactly the strengths of a should not be surprised if the system runs out of space or the typical scripting language. application runs too slowly. Marrying a C application that does what it is good at (bit Small systems can be very fast as long as twiddling, efficient storage of data) with a scripting language they don't have to do much. can provide a best-of-both-worlds scenario. It is easy for the overheads to swamp the potential performance improvement of a more complex system. For example, there is no doubt that uClibc is generally slower than glibc for a number of operations. However if your application comes into existence, has a small amount of work to do (say, a handful of system calls) and disappears again, you will likely get better performance with uClibc than glibc. 5. CASE STUDY: AUTOMATED TESTING 6. CASE STUDY: WEB FRAMEWORK Some years ago I worked at a company which produced a line At WorkWare we have a product, µWeb, that makes it very easy of embedded Linux firewall-routers. As the number of models to build web interfaces for embedded devices.