We have some beefs about how Texas Instruments does things, the biggest of which is their lack of support for development under Linux operating systems. But if they build it, someone will try to get Linux involved in one form or another. This time around, [BLuRry] put together a guide to developing for the Evalbot under Linux. He got a shove in the right direction from the code package that went along with that nunchuck-controlled Evalbot. Picking apart that example to the bare essentials he wrote up the process of setting up the cross-compiling toolchain in a virtual machine so as not to clutter your system. From there he details how to set up and use Eclipse when starting a new project. What what did he choose for a Hello World experience? Well a plain “Hello World” was first but right on its heels is the “Hello Hack-A-Day” seen above. So if you’ve got one of these on hand get out there and start coding for it.
19 thoughts on “TI Evalbot Development Under Linux”
I just got the IAR compiler to build one of
the uC/OS-III examples, and I wanted to use
my regular old Linux systems to continue developing.
PERFECT timing. Thanks man.
Free cookies for anyone who gets eLua working on the evalbot using the SD slot and/or a usb thumbdrive!
“cross-compiling toolchain in a virtual machine so as not to clutter your system.”
What the heck?? Cross-compiling in Linux should be as simple as normal compiling much less cluttering your system..
I didn’t read TFA but I suggest people to use Gentoo Linux for building a cross-compiler, inside a virtual machine or alternate chroot.
This is why I come here. Excellent work!
@MrX: Yeah, I know. It’s a puh-tato/po-tato thing. But my laptop is a work machine and if I screw up something fundamental like my normal GCC build path then it’s going to make for a very bad monday. If people follow my instructions and slip up somewhere, then at least they only broke a virtual machine. Granted, you can use whatever distro or installation method you want. The build instructions all probably apply to Windows as well, but I certainly don’t advocate that. :-D
I see.. Well in Gentoo you simply create a working cross-compiler by doing:
FEATURES=”sandbox” crossdev -t arm-none-gnueabi
This will (using stable versions) build a working (gnu libc based) C/C++ cross compiler. The sandbox setting will ensure the build process takes place inside a sandbox and thus preventing damage of your running system. The install paths are also checked..
Then you can cross-compile any package available in portage (the package manager and repository of Gentoo) by simply using the package manager:
Sorry for insisting in Gentoo.. but it really makes cross-development a snap for me so I thought it was worth sharing :)
VERY IMPORTANT: Your microcontroller is actually an ARMv7M so you are wasting some of the CPU power by building the toolchain with a generic arm target! It means fancy stuff that your ARMv7 CPU supports (like thumb mode etc..) won’t be enabled.
The correct toolchain version for your CPU is
armv7m-unknown-linux-gnueabi, when in doubt check here:
Oh.. By the way, crossdev also supports uclibc so you can just replace the gnueabi suffix with uclibc to create a uclibc based cross-compiler.
@Spork: Yeah, isn’t it ironic I didn’t put up a fuzzy cellphone pic of some sort? :-D I used the stock lens that came with my Rebel XTi (18-55mm). I figured it was worth the effort so that you could see the pixels of the screen and enough refraction and such to indicate it wasn’t some crap photoshop job.
@MrX: Crosstool was the first thing I tried. But I kept getting failures, both with an older copy and with the most recent copy. I wasn’t able to work out what the exact problem was. :-( I agree that having a custom-build toolchain is the best way to get all the power out (and thanks for the tip about the processor type flag! The eclipse plugin doesn’t offer it, so I need to add it as a supplemental parameter or email the plugin author to add it.)
@MrX: The build process I describe puts -mcpu=cortex-m3 in the GCC arguments. Isn’t that sufficient to have it build ARM7-specific code? (Remember, I’m not using a toolchain built by crosstool — I’m using CodeSourcery G++ Lite)
using -mcpu=cortex-m3 will restrict to instructions supported by the cortex-m3 so, yes, ARMv7 instructions will be generated which is better than what arm-none-gnueabi implies :P . But you can still do better:
use -mcpu=cortex-m3 and -mtune=cortex-m3 this will use cortex-m3 supported instructions AND optimize the generated code for your CPU respectively. An alternate way is to just specify -march=armv7-m
Since we are at it you can also add -O2 and -pipe to your gcc CFLAGS to optimize the code for execution and use pipes during compilation (using RAM at expense of hdd files). So,
CFLAGS=”-march=armv7-m -O2 -pipe”
if you are low on flash or RAM, use -Os instead to optimize generated code without increasing the generated code size.
By the way, -mcpu was deprecated so I guess you are using an old gcc?
Waiting for more :)
I’ve only assembled mine and used the internal program.
Oh my! This is good timing. I got my evalbot yesterday :)
I love your doghouse array at the end
Getting a toolchain for the Stellaris uCs working in Linux is pretty easy.
I used the tutorials at http://fun-tech.se/stm32/gcc/index.php but replaced STM32 with ARM in all cases – other than that the steps are exactly the same. (I also manually built everything instead of running that script.)
If anything, the Stellaris dev boards are some of the easiest to use in Linux since, unlike some of the STM32 and LPC dev boards, their boards just use an FT2232 for the JTAG interface which is fully supported by OpenOCD.
The biggest issue regarding TI’s Stellaris line and open source is that while TI has been very open-source friendly with other product lines (such as the BeagleBoard effort for OMAP), the product lines inherited from Luminary have utterly horrific licensing terms for their peripheral driver libraries that explicitly bash the GPL as part of the license.
Admittedly, almost all of the ARM Cortex-M3 microcontroller manufacturers are offenders here to some degree, nearly all peripheral driver libraries for CM3-based chips have a “you can only use this with our chips” clause that makes them GPL incompatible unless you believe they fall under the “system library” exception, but the Stellaris license goes above and beyond by explicitly calling out the GPL.
I figured out how to automate OpenOCD deployment from Eclipse as well and added another section. It’s basic shell script fu, but it could save an otherwise frustrating hour or two…
If anyone is interested I have an EvalBot and I have ported/adapted following drivers/examples for it:
1) Ethernet+(uIP) (with OLED output)
2) SDCard (SDcard Driver+FatFS) (with OLED output)
3) USB Host(mouse & msc) (with OLED output)
4) USB Device(mouse)
5) Wav Player (with OLED output)
I still just need more motivation to create a github to post all those drivers/projects.
Benjamin, I’d be very happy to help you get these projects up on github or at least have a look at them. I haven’t been able to do much lately and could benefit from better working examples. By chance, have you done much with the Can bus? (I’m hoping to hack my Prius with it, assuming it is indeed the same can bus protocol)
Sorry i haven’t tested CAN bu
For information TI has released few days ago a full downloadable EvalBot Package including CAN driver on http://focus.ti.com/docs/toolsw/folders/print/eks-evalbot-cd.html
Please be kind and respectful to help make the comments section excellent. (Comment Policy)