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
Fine, don't use BeRTOS (or whatever RTOS). Ditch that and still use the free AVR avr-gcc compiler suite from Atmel along with Codelite and gdb that comes along for the ride.
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.
And just regular gcc, avr-libc and avrdude is still better without any shitty environment on top. With whatever editor you prefer.
Really, what is this obsession with integrated development environments, with their crappy UI, editors that can't let me have two windows with different parts of a source file side by side, implemented in Java or worse, and with no redeeming qualities other than letting a user to mash one button to start the build? Do people really expect that much handholding while doing very complex kind of software development, dealing with hardware, interrupts, concurrency, etc. in the minimal environment, but they cant write a makefile? What kind of bugs do they write, ones that cause them to endlessly compile and recompile code, making random changes until something seems to work? Really? That's their workflow?
Screw that. Learn to use command line, and don't recompile every second. Use your head.
Contrary to the popular belief, there indeed is no God.
Good IDEs have ways to search across symbols, source files, etc. They allow you to quickly search for references to symbols. They allow integration of one-click compiler-error/warning-to-source jumps. They do static analysis and performance profiling. They have easy ways of pausing execution modifying code and resuming execution. They let you use version control from inside them. They have plug-in oriented debuggers that let you write simple visualizations for your own datastructures and much much more. All of those things save development time. Thankfully the vast majority of programmers these days have a choice for using an IDE. Nobody sane would want to maintain Makefiles, unless it was the only option. Your opinion of people who use IDEs is outdated propaganda.
Yes, I do. Don't get me wrong, I code in vi regularly and in some ways prefer it. I usually hand-craft my makefiles. But the idea of an IDE is not just to give the user one button to start a build. A good IDE helps you read code. There's still lots of progress to be made in this, but here are some features that make me more productive in an IDE:
Your fallacy is in assuming that complex code requires working always at a basic level, but the opposite is true - the more complex the code, the more helpful tools improve your productivity.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
(1) Vendors do not want to document their internals and interfaces, so you can only use their proprietary software.
This is wh I love PIC micros. The datasheets are enormous and tell you _everything_, there are good closed and open tools. They are well documented. The programmer is even another PIC and they give away the source code as well as document the programming interface!
PIC seem to have figured that by making it easy, cheap and realising that they don't have expertise in super proprietary and extraordinarily buggy development tools (like just about every prior microcontroller vendor) people might actually want to use their stuff. You know, use it witout wanting to roll up to the Vendors's HQ with a chainsaw...
Oh, and a sleep power of 2nW does't do any harm either :)
Of course, they don't go very big, but for deep embedded stuff they are realy handy.
I gather ATMEL are pretty good too, but I started with PIC, so i've stuck with them due to being good enough and mild intertia.
SJW n. One who posts facts.
Unless you are supporting a legacy system
You really don't know about the embedded world :)
8051s are everywhere, and growing in number, astonishingly. For instance, the latest bluetooth low energy endpoint controllers from Phillips come with... an embedded 8051. Basically every piece of hardware that needs some sort of noddy low power controller and isn't especially demanding on it will probably use an 8051.
The thing is they are cheap, unencumbered, plenty of cell and layout libraries exist, development tools ar ready made, they clock into hundreds of MHz and do the job well enough.
I would not be overly surprised if the 8051 instruction set outlasts x86, to be honest.
Sure, you don't get free-floating 8051s any more (on the low end there are other controllers like PIC which are cheaper and lower power) and on the high end, everything beats them. But for everything else, they are ubiquitous.
SJW n. One who posts facts.
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.
I wasn't aware I was supposed to know everything about everything. Thanks for telling me.
Achille Talon
Hop!
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.