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.
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.
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
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.
Plus if you're stuck using an IDE then you can't create an automated build environment very easily, or automatically kick off tests, use the same environment for different projects if they are in different languages or for different chips. Once you use an IDE then you're pretty much mandating that every single developer on the project use it, and you can make a lot of enemies that way if they're not on board.
One very seldom uses the standalone 8051 but rather the 8051 core.
Because of the simplicity and small size of the core there are plenty of specialized ICs out there with an embedded 8051 code.
The most obvious application is one chip radio solutions. Instead of having to use both a 1-chip radio and a micro-controller you get them both in a single package. This is great for high end small size remote controls where you might want to do some bidirectional authorization or just signal back that the message got through in cases where the result isn't obvious.
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.
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?
Well, Visual Studio can have two (or three, or four) windows side-by-side showing different parts of the source. It has good multi-monitor support and isn't written in Java.
Code completion is a really nice feature that only IDEs offer. A text editor that doesn't understand the language can't give you very much help in that regard. Even basic stuff like being able to right click on something and see all references to it and jump directly to the definition is a huge improvement over hunting through files in a text editor.
Visual Studio isn't what you would call "light weight", but it does a lot for you that is really, really worth having. Not in a hold-your-hand my-first-program way, but in an experienced-engineer-with-a-large-complex-project-to-work-with way. And yes, Atmel Studio will still let you use a makefile and command line compilation if you really want to.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
The thing is they are cheap, unencumbered
I'm not sure about that. As far as I am aware Intel still license the design. It is probably a question of licensing a certified implementation, as some other vendors do. Most companies won't develop one themselves, which makes me wonder why no-one else has made a really serious attempt to get into that market.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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!
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.