Slashdot Mirror
Ask Slashdot: Best OSS Embedded Development Platform
AchilleTalon writes "As many of you may know, there are two main competitors on the Windows platform for embedded software development, namely IAR and Keil. By embedded development, I mean development for microprocessors like the well known 8051 and the likes, not mobile platforms which include a complete OS in first place. I am seeking for alternatives to IAR and Keil in the OSS world. Even if I can find pieces of code here and there, I haven't found yet a fully integrated development platform. Does it exist? What do you use?"
http://sdcc.sourceforge.net/snap.php#Windows
"I've got more toys than Teruhisa Kitahara."
I have used both IAR and KEIL, but I find using gnu tools far superior. For a number of reasons
* Dongles (ok they have license services too, but they are always more expensive).. If you 2 years after release find you need to do a emergency fix of your released software. You start by trying to find that dongle that is needed for the software.
* Licenses, when you need that quick fix, you can almost be certain that your license has expired
* Integration problem on the build servers.. When you are building on your local machine everything is fine and dandy. But trying to migrate that your build farm, good luck with that
* linker scripts.. when you need very esoteric features where you wanna lie your code in ROM, the gnu tools are just far superior in flexibility
* and I love to type make on the prompt and build the artifact.. instead of firing up som clunky IDE
BeRTOS is an RTOS or Real-Time Operating System (no surprise, given its name), and like most RTOS it runs on the embedded microcontroller. That's not what TFA was asking for at all.
What the submitter is looking for is an open source integrated environment (an application) that run on normal desktops, cross-compiles to the microcontroller, and interactively debugs it, typically through JTAG. In other words, just like the proprietary examples (IAR and Keil) that TFA gave but open source.
Well if free gets you bent out of shape you can *actually pay* for things like BeRTOS and FreeRTOs if you like.
I use GNU toolchain (GCC, Binutils, GDB) and Eclipse or Codeblocks. Setting it up takes some time, and can cause some headaches. Also not all hardware platforms and all emulators will work with this setup, but once you get it working, it has plenty advantages over commercial platforms.
One setup example for Texas Instruments Stellaris microcontrollers: http://kernelhacks.blogspot.com.es/2012/11/the-complete-tutorial-for-stellaris.html
When I cannot use GNU tools, I usually use Keil or CodeComposer Studio (this is only for Texas Instruments stuff).
avrstudio is pretty good for embedded avr, or gcc+avrdude.
i'm not sure what you mean by ide for embedded. i tend to think of ide as integrating code with visuals, but there's no forms in embedded, and i imagine it would be a big stretch to simulate outputs when they could consist of anything. you can integrate debugging, flashing, and simulation of chip response. in that case avrstudio is very good for avr chips.
always wanted to get into stm32
GCC cross compiler, OpenOCD (with an Olimex JTAG debugger), GDB. From the perspective of features, openness, flexibility and integration with other systems (build infrastructures, unit testing etc.), nothing beats it.
I've gone through IAR, Kiel, CodeBench and CrossWorks. The former three are absolutely terrible. CrossWorks is probably the best of the IDE offerings by far.
Rolling your own toolchain is a valuable exercise, and if you've been forced to use any of the commercial offerings I just mentioned, you won't be going back.
I've been using the KEIL tools for years now, so I may be prejudiced, but I am very happy with the quality of the code and the support, both device-wise (I've used KEIL compilers from 8051 to ARM on a lot of platforms over the years), and when I need support services.
For some other development projects I have to use Eclipse, and it is a pain in the a**, especially when it comes to debugging. Looking into a chips hardware registers or simulating a devices IO hardware is a BIG advantage when using the KEIL debugger (or an IAR chip simulator hardware). Maybe I missed something big, but with Eclipse I am back in the 20th century using printf and an oscilloscope for debugging. One can see that the GNU toolchain, especially the gdb, was never ever build with embedded systems in mind. Eclipse is nice for playing Java (for which it was invented), with fancy class views and such, but it is simply unuseable for professional embedded work.
Don't get me wrong, I'm really into open source, and I like the Linux system, having contributed to the kernel even before it was 1.0, but Eclipse and the GNU toolchain is of no use if your working on the pure metal. Eclipse is a good hammer for nails like application development, but embedded development is more like screws and you'll definitely need a screwdriver to do the job.
First order of programming: To know which tools to use for a job. You wouldn't use PERL to write an accounting package, would you?
A magnetic needle and a steady hand.
I use eCos + GNU toolchain + Eclipse + OpenOCD (for ARM targets).
I have been using Codelite for a few years for editing and building AVR and Atmel SAM7X stuff. Generally works well but was a bit finicky getting a tool chain setup.
What I like about it is,
Written in C++ based on wxWidgets and the scintilla editor. No Java bullshit.
Very fast and responsive.
Supports multiple projects in a workspace
Doesn't care if files are shared between projects
It has minimal thoughts on where files in a project are supposed to be.
Has code completion, style highlighting.
Supports clang, so you can 90% navigate vai show definition and implementation.
For for in project/files/workspace works well.
Also can come bundled with MinGW which is nice for trying out stuff locally.
It does have a few rough edges. Setting up a compiler requires knowing a bit and fudging. However if you can get something to work on Eclipse you'll be able to get it to work under CodeLite too.
Seriously need an auto-detect compiler feature. Which its close cousin CodeBlocks does have.
I haven't used it's GDB support.
Flip side the other two engineers I tried to get to use it, hated it. One reverting to Visual Studio and the other to Emacs.
There are two reasons for it:
(1) Vendors do not want to document their internals and interfaces, so you can only use their proprietary software.
(2) Vendors would prefer you use their tools, which in turn use their proprietary description file formats for the design files. This increases the expense of switching to another vendor for fungible embedded controllers. A good examples of these are the ECs for laptops available from TI, Western Digital, and FTDI, in particular, those used for battery and power management and 8051 emulation for matrix keyboard decoding.
It's possible to reverse engineer it, but when you are trying to get a product out the door, you care more about time to market than you care about whether or not the tools are available for free. A good vendor example in this category is Atmel. If you want to reverse engineer things so that you can use your Dediprog to program a wide range of microcontrollers, feel free to buy a wide range of microcontrollers, a wide range of SDK softwaare, and have at it.
NB: If you are trying to do this for Samsung ECs, they tend to use ECs that have a cryptographic handshake, and require encrypted load payloads. For things where you can program them without soldering extra wires on them to get to the programming UART, you can pretty much operate in the clear... unless of course the EC does a validity check on the other WCS's, for example a cryptographic checksum of the BIOS using a secret key known to the proprietary BIOS vendor and the EC, e.g. Insyde H2O BIOS used by some motherboard vendors -- probably also reverse engineerable (EE's are notoriously bad at writing robust security code) at great expense.
Unless you are supporting a legacy system or require ultra-high temperature or rad-hard parts, why the 8051? Put another way - why do you need a new tool for an old part? I was using Keil v4 around 20 years ago on some 87x51 part. It was okay.
Keil and IAR do work (though IAR's AVR32 is still rubbish). But they are expensive and often come with a dongle or other machine-locked keys, which are ALWAYS a problem.
However, I'm stuck with it, so that's what I'm using.
Anyone else having CTD issues with IARs IDE?
There are a few free options available, by free I mean as in beer.
For 8 bit work, you can go with Atmel ATMega and ATTiny, using the free AVRStudio.
Theres also MPLAB IDE for PIC micros, also free.
For 16/32 bit work, you cant go past ARM. You have Eclipse and CooCox as options for free IDE's ( coocox is more integrated, and has open source hardware debuggers available that can be easily used). Both are based on GCC toolchain.
Id recommend the ARM route, as the Cortex M series is very good for the price ( esp the LPC1700 series from NXP ), and the programmer and debugging tools are cheap and non proprietary.
Im sure there are other options out there too.
Here's an interesting cross-platform (runs on Windows and Linux) open source IDE that sits on top of the GNU ARM tools:
http://ryansturmer.github.io/cuttlebug/
Just buggy, no more words needed.
There are some OpenRISC based solutions. I've worked with NXP JN5148 (low power wireless). The Toolchain is Eclipse & GCC-based (plus propriatary bits). JTAG support is not very comfortable, though.
That's kinda, like, your opinion, man.
If the dude don't know everything about everything, or knows there are somethings he don't know he can always ask, man. And people, would be all, like, hey, man, here's what I know, and he be like, thanks man. So we all happy now.
http://www.toppers.jp/ Is what I and many many Japanese electronics and automotive manufacturers use. It's said uTron/iTron is the most used OS on the planet actually, due to it's almost universial usage in Japanese electronics. I once heard the Toyota Prius has 5 Tron instances running in each break system alone.
Of course all the information and documentation, despite being very plentiful and for a completely Open Standard (Tron) base and Open Source (TOPPERS, etc.) implementations, is in Japanese. Probably not ideal for you, but I just wanted to mention it exists and is pretty nice.
Vendors of ARM's Cortex-m based micro-controllers tend to use gcc and you get a build of it from them or their third-party partner. IDE wise, some vendors such as NXP and TI have an eclipse based offering, but I've found regular eclipse with the zylin plugin is better. I've even built a compiler from source for the cortex-m0 and managed to get working code from it. (I had some spare time).
Vendors of other architectures often bundle useful libraries and code with their tools. Throwing them away and starting again is a waste of term.
Arduino is the only truly open source micro-controller environment that I've used which works out of the box.
The lessons enumerated at http://deardiary.chalisque.org/multistage-computer-language-evolution/ have yet to be learned in many parts of the current world of computing. This is more important when stringent resource constraints mean that the obvious 'industry standard best practice(TM) stuff' is no longer applicable and you have to work stuff out from scratch.
John_Chalisque
Further reading at http://forums.parallax.com/
I find the IDE has less to do with how much of a utter mess the embedded system's platform is. AVR's are great, but if you program for any of the TI platforms like the MSP chips you will find that the code from TI is a complete and utter nightmare mess that is 100% useless unless you want to spend months trying to figure out how to program like they do... or take a lot of peyote when you program because it seems that is how TI programmers work.
That said, Eclipse is a bit of a "clunky" IDE but it's the best we have until someone makes one that is cleaned up and as compatible with all the platforms out there as Eclipse seems to be.
Do not look at laser with remaining good eye.
Basically you're not thinking small enough.
The minimum cost on ARM-based processors is somewhere around the $2 mark. I can get PICs for down to about $0.30. There's plenty of products where that sort of difference is significant - and easily high enough volume to drown any development time cost difference.
I wasn't aware I was supposed to know everything about everything. Thanks for telling me.
Achille Talon
Hop!
Your minimum cost is pretty dated, I think. *Many* modern Cortex-M0 parts can be had for under $1 (from ST, NXP, Freescale, and many newcomers), and a few under $0.50 in quantity (the only place where such penny-pinching really matters). These parts also have significantly more resources than anything you can find in the entire 8-bit PIC ecosystem, much less the cheapest parts... There is almost certainly a small window of space where the tiniest 8-bit microcontrollers belong, but for most tasks there is now an ARM to fit.
At this point, the biggest legitimate reasons to stick with an 8-bit part are: 1) learning curve of a new processor architecture, 2) appropriate packaging available for only 8-bit parts, or 3) absolute lowest cost part required, in that $0.20 window between the dirt-cheapest 8-bits and the dirt-cheapest 32-bit parts.
In the last few years, ARM has taken over the embedded world. It has solutions that span the entire range embedded problems, and it can be programmed entirely with the GNU toolchain. 8051s and PICs have been loosing dominance for years, and non-OSS toolchains have been declining in quality for years.
ARM has many different vendors and many different cores:
The smallest is the Cortex M-0. These come as small as 2.17x2.31 mm package made by NXP. This a 50 mhz processor with 12 io pins muxed with a few peripherals, and is between 1-4 dollars depending on quantity. There are many equally good and cheap Cortex M-0's.
If that does not quite cut it, you have Cortex M-3 series. There are MANY processors in this series. If you are looking for something good in this series, I would recommend the STM32 processors. There are many cheap and easy dev boards to get one of these processors up and running.
From here ARM just gets more and more powerful. Cortex A8 and A9 processors run at ghz now and run embedded linux. I have used these with linux with great results from Motorola, Atmel, TI (those these tend to require some effort) and Freescale. I have not yet had a chance to test the Exynos chips (this is up to quad core at 1.7 ghz) or the AllWinner chips.
All of these chips can be programmed with the gnu toolchain. The ones without linux os involve building the the gnu toolchain with the newlib library instead of the glibc/uclibc library. This is a bit of an involved process, but normally there are toolchains that are built and downloadable.
Further, any company that builds an ARM micro can be built with the gnu toolchain.
Also, never underestimate the power of attaching a small CPLD or FPGA to your application. That can drastically reduce the complexity of your software when done correctly.
I have used almost every toolchain and IDE at one point or another, and this has been *BY FAR* the most sustainable solution I have found.
These days the pysical interface is mainly JTAG which replaced the venerable (and expensive) ICE (In circuit emulator). In the past, many processor manufacturers would not release specs for their JTAG, to make ppl buy their IDE. TI was notorious for this. This made writing a free and open source IDE really difficult to do.
There are IDEs which are good wrappers for the compiler (Eclipse, Code::Blocks, etc.) but most of them use the generic GNU debugger (GDB) and this has never been my favorite debugger for *embedded* targets where you need to; quickly reset&re-run, perform inspection of variables and RAM contents (memory dumps), add breakpoints on data, not just functions, be able to debug all the way down to the iron, and other tasks.
The challenges in embedded firmware is that, for the most part, you are writing your own kernel and program all wrapped up in one executable, so there is no separate kernel always there in the background. The IDE and debugger have to support this type of basic program.
- I stole your sig.
I don't understand the penchant for an IDE. It is just another layer between me and the finished product. I've ran into too many developers that have no idea how to use an actual compiler...it is terrifying!
I recommend building your toolchain from source and setting up a console build environment manually. This is probably the simplest yet most effective tutorial I've seen; coincidently, it also targets the LM3S product line:
http://kunen.org/uC/LM3S1968/part1.html
Getting a board with a good USB->JTAG part will get you a long way. I have a EK-LM3S6965 board with a FT2232 that has been rewired into a dedicated JTAG+UART dongle. That, with OpenOCD and GDB, is much more flexible than any IDE debugger. But you have to read the docs!