Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse CDT

• Report rights infringement
• published: 10 Apr 2012
• views: 206620

A new version of this video is available (Jan, 2015) See: https://www.youtube.com/watch?v=T9yFyWsyyGk This video introduces C and C++ programming on the Beaglebone platform, which is applicable to any embedded Linux development. I quickly introduce how we can program directly on the beaglebone using a terminal window and point out the limitations. I show the steps that are necessary to set up the Eclipse CDT environment and use the Target Management RSE (Remote System Environment) plugin to communicate with the Beaglebone. I then demonstrate how we can use Eclipse CDT IDE to cross-develop (using arm-linux-gnueabi) applications for the ARM architecture. To do this, I write a short program that flashes the user LEDs on the Beaglebone. Finally, I demonstrate how we can set up a cross-debug environment, where we use gdbserver on the arm device and gdb-multiarch on the client device to establish a full debug environment. TangoBravo has pointed out that some paths have been changed in the current Angstrom image (June 2013). For instance, the path to the brightness properties has been changed in the latest version of Angstrom. The old path: /sys/class/leds/beaglebone::us­­­r3/brightness ...is now this: /sys/class/leds/beaglebone:gre­­­en:usr3/brightness So you have to make the change to get the LED to flash. Check your path to verify. If you use this video in your research, please cite: Molloy, D. [DerekMolloyDCU]. (2012, Apr, 10). Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse CDT [Video file]. Retrieved from http://www.youtube.com/watch?v=vFv_-y... One common problem that arises with this setup: If bash reports "file not found" when executing an executable file that exists, the reason is that it doesn't recognise it as a binary file, and attempts to treat it as a script. The hypothetical script should start off with #!/path/to/interpreter and bash cannot find the (non-existent) interpreter so it returns "file not found". This could happen if for example you are running a 64-bit executable on 32-bit machine, or an x86 executable on an ARM target. In Eclipse your executable should display in your source directory as "HelloWorld - [arm/le]" in the project explorer window. If it does *not* then there is a problem with your compiler setup and you need to watch the steps again. If it *does* then one likely problem is if that you are using an ARM Linux platform that uses "hard floats" and that you have compiled using my setup which uses "soft floats". Here are two possible solutions: - Graemefisheratwork let me know that he has found that when using the ubuntu armhf distros, applications should be cross-compiled using arm-linux-gnueabihf- and not arm-linux-gnueabi-. This seems to have worked for him on the ubuntu 12.04 armhf build. - I'm using "Linux omap 3.2.18-psp14 armv71" in this video that I built myself which has defaulted to soft floating point numbers. There are floating-point options in gcc that you have to set when using hardware floating point numbers -- you should add " -mfloat-abi=hard" to your compiler options.