Starting with an idea (see image on the left) you generate a concept and specifications.
Right after this the developer is able to implement the applications according to the given specifications.
Depending on the application type and the skills an enormous number of possible programming languages appears:
In our case the highly optimised FESTO-toolchain supports assembler
, c
and c++
- therefore all further compilation steps refer only to
these selected programming languages.
Let us consider you have following short hello-world application stored in the file helloworld.c
#include <stdio.h> int main(int argc, char* argv[]) { fprintf(stdout, "greetings from your FESTO SBOx :-)"); return 0; }
In order to build the desired cross-compiled binary just enter following line:
arm-linux-gcc -o helloworld helloworld.c
When there is no error upon compilation you should get a working linux-executable ready to run on your FESTO SBOx-smartcamera.
Another way ist described right here below. In this case the source-file(s9 will only compiled (generates .o
file(s)) in the first step. In the second step this(these) objectfile(s) are linked together.
arm-linux-gcc -c helloworld.c arm-linux-gcc -o helloworld helloworld.o
Sometimes it is necessary to link some parts of an application stored in libraries. This task will also be fulfilled by arm-linux-gcc
. All you have to do is to specify the library with the compiler-linkoption -l
. Attention! The naming convention for libraries under Linux is lib<name>.a
for static libs and lib<name>.so
for dynamic loadable libs respectively. Let's assume you have a lib called libmylib.so
and you will have to link it to your application helloworld
then use following commands:
arm-linux-gcc -c helloworld.c arm-linux-gcc -o helloworld helloworld.o -lmylib
As you can see in the last command line to specify the library you just have to specify the library-name without preceding lib
and the extension.
To debug your application there are additional options recommended to be set during compilation:
-g
to include program symbol information for the debugger-static
to create a statically linked application without dynamic libraries to load. This is especially necessary whenever you step through code using glibc
library functions. These libraries are installed on the camera without symbolic information to dramatically save space. When you try to step behind library functions the debugger gets lost without this information. Building static executables often delivers very large application binaries. It is recommended that you store this binaries on a NFS share and work from there.Here is the compiling syntax for helloworld:
arm-linux-gcc -g -static -o helloworld helloworld.c
Once compiled and linked you start your new application on your camera in this way:
~ $ gdbserver <host ip>:<port> helloworld
whereas host ip
specifies the ip-address of your host-pc and port
determines the used TCP/IP socket port. You optionally can leave host ip
blank to accept connections from any debugging host.
On the host-pc change to the directory where you have compiled your executable that is being debugged. Then start the arm-linux-gdb helloworld
(the gnu debugger contained in the camera's toolchain) with the executable as an argument. arm-linux-gdb
will load program symbols and as usually - you will get following prompt:
GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"... (gdb)
To connect to gdbserver
an the camera just type
(gdb) target remote <camera-ip>:<port> Remote debugging using 192.168.2.10:4711 0x000080d0 in _start () (gdb)
whereas camera-ip
is the IP-address of the desired camera and <port> is the TCP/IP port the camera is waiting for incoming connections.
Set a breakpoint to the main function and run the program until main has been reached:
(gdb) break main Breakpoint 1 at 0x81e8: file helloworld.c, line 5. (gdb) cont Continuing. Breakpoint 1, main (argc=1, argv=0xbefffea4) at helloworld.c:5 5 fprintf(stdout, "greetings from your FESTO SBOx :-)"); (gdb)
To finalize the connection and quit arm-linux-gdb
(gdb) detach Ending remote debugging. (gdb) quit
Using arm-linux-gdb
as your debugger works perfect, but may be inconvenient to people who like graphical user interfaces. Fortunately nearly every GUI debugger available under Linux is based on the concept of using GDB underneath the graphical front end. Depending on the debugger you should be able to specify a path name to the underlying debugger executable (in out case /opt/sbo/gcc332/bin/arm-linux-gdb) in those front ends. Another possibility is to specify the debugger executable on the command line when starting the graphical debugger. Here is a list of debuggers already seen working with FESTO cameras: