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?"

Comments

SDCC

[ozmanjusri]

http://sdcc.sourceforge.net/snap.php#Windows

Re:SDCC

[taniwha]

yes I think SDCC is the only real OS 8051 solution - I've been through this same process looking for tools for a cc2533 recently and this is what I've found works it's not gcc, and 8051 is a crap target, you have to code with all the memory hierarchies in mind.

Re:SDCC

[ozmanjusri]

I'm not aware of any others.

I use the Eclipse version, but tried MIDE-51 for a while. It's a good lightweight option. Jsim-51 is useful too.

Re:SDCC

[taniwha]

I used jmce for simulation - 8051s are all different enough that chances are you'll have to hack on you simulator (and configure sdcc) to match the memory layout and dptr/p2 weirdness of your particular variant

Re:SDCC

[Foresto]

Looks like there's a free 8051-specific IDE that uses SDCC, though I haven't used it.
http://mcu8051ide.sourceforge.net/

Re:SDCC

[Anonymous Coward]

One of the reasons for using Keil/IAR is that their compiler is a bit more consistent across the different microcontroller architectures out there. So you would spend less time learning the quirks of compilers (gcc/gcc-msp430/gcc-avr/gcc-68hc11/sdcc etc) and spent time doing the actual coding. At the end of the day being able to use vendor supplied code (example/libraries) as-is is a good reason. Going for OSS embedded "platform" for the sake of a politican view is a loss clause.

I have played with SDCC over the years and found quite a few bugs in the compiled code. It could even handle the extra register bank for Z80 assembly code! So I really don't want to think about their testbenches. Forget about compiling OS that are intended for Keil/IAR as SDCC output code quality is quite poor/efficient in code/ram usage.

I have used Programmer's Notepad as my editor with SDCC. I am picky on what I use as my personal beef is that half of the so called IDE out there uses TABBED editors does not let the users to use multiple text windows for editing. May be they would fit right in the mindset of Metro in Win 8. ;P

Hand editing makefile for the 8051 is not too bad as it is a 8-bit device and SDCC is relative sane. I would definitely have to use an IDE for gcc that have overly non-human readable compiler scripts.

Re:SDCC

[ozmanjusri]

Going for OSS embedded "platform" for the sake of a politican view is a loss clause.

It's worked out well for me over many years, but I'm not precious about my tools. YMMV.

Re:Bertos

[Anonymous Coward]

I would guess OP is looking for "free" software for the zero cost. (personally I always find it strange when people who supposedly are professionals in their field turn to /. to ask what tools to use or are avalible. Should not YOU of all people know these things? If you do not, should you not know where to find this info. I can help you with 1ct worth of info. /. is NOT the place)

BeRTOS for the First Post

[Jimbookis]

BeRTOS is very nice for the money (free), is going in the right direction and is more than libre enough. Develop for ARM or AVR in Windows or Linux. Don't see why other core's and SoCs can't be added. It has a nice Pyython/QT configuration manager, lots of abstraction and can be debugged with GDB in conjuction with CodeIite though I have used AVRStudio4 to do the same. It just needs some lovin'. http://www.bertos.org/ A pox on my first AC post on the subject.

Make files and emacs

[Anonymous Coward]

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

Re:Make files and emacs

[MadMing]

Seconded.

I've tried a variety of IDEs, including Eclipse and Keil. My favorite is Visual Studio on Windows, and I did sort of get it integrated with the GNU tools but in the end it wasn't worth the hassle.

I'm in the final stages of large-ish embedded ARM project cross-compiled on Linux x86 using nothing but vi, make and free CodeSourcery GCC ARM tools. All of this was on Ubuntu 12.04 running under VirtualBox on Windows or OSX.

Re:Make files and emacs

[Anonymous Coward]

The GNU toolchain does not support most microcontrollers. I love how IT people think they know anything about embedded. And no "embedded Linux" is far from embedded unless you don't care about interrupt latency, priority inversion, or any of the things hard real time systems have to deal with.

There is SDCC but it isn't the greatest and frequently falls apart on complex code that IAR and Keil handle well. But if you are willing to rework your code and verify the assembly output by SDCC it is usable for most projects.

Re:Make files and emacs

[nodan]

I've used both Keil and SDCC, and it turned out the code generation of Keil was much better (years ago though). I'm mostly using GNU tools and my editor is emacs, but for source-level debugging the Keil tools are useful.

Re:Make files and emacs

[thoughtspace]

Except for eclipse completely ridiculous: project import system, auto add files found in directory, and configuration menus all over the place.

Re:Make files and emacs

[mirix]

GCC does ARM and AVR... which is all I use now, because of that fact.

Never going back to the dark ages of closed source compilers and PIC, some of the moto stuff. I did use SDCC with 8051 back then, but I recall it being a little rough. Perhaps it's improved, now.

Re:Make files and emacs

[Darinbob]

Yup, GCC works great on just about all the platforms, 8 to 64 bit. There's not really much that commercial compilers give you as an advantage anymore. They don't even give you decent support which is what people claim you're paying for. GNU stuff does fall down a bit on the documentation side, mostly because it's either out of date or just so huge it's hard to get a good grasp on it (I have a cube neighbor that hates gcc since he's used to compilers that give a anual that's very specific to the chip being used).

You also can't beat make for building stuff. I can't believe people try to use IDEs for these things, it's just so clunky. We used an IDE for a larger system at a previous company and it was just so painfully slow. With visual studio that used an external compiler, the exported makefiles were slower than the hand crafted ones, and it was just plain stupid to open the IDE just to click the make button.

To use these tools on Windows you need to get Cygwin to make it work more smoothly. It's not the greatest system in the world but it's much better than bare bones Windows command line. If you have a choice though, it's easier to just do it all on a real unix system like Linux or Mac OS.

Re:Make files and emacs

[AmiMoJo]

The best thing Atmel ever did was to license Visual Studio for their 8/32 bit microcontroller IDE. The use GCC as the compiler and their own debugger. They throw in a licenced copy of Visual Assist X as well, and all for free.

Microchip's IDE (MPLAB) was always terrible, and for the latest version they decided to switch to Eclipse but the thing still sucks. Their compiler is terrible as well, and their debugger hardware is awful. I hate having to support software written for PICs because while the PICs themselves are okay the IDE makes me want to do something unspeakable.

Re:Make files and emacs

[Anonymous Coward]

It really depends which microcontroller you're talking about. The GNU toolchain won't help you for PIC, but (if we're all very honest) PIC is a shambles of an architecture. GNU tools for platforms like MSP430 and AVR are good. Add Eclipse if you want. If any aspect lets you down, unfortunately it's likely to be gdb.

Re:Make files and emacs

[Anonymous Coward]

The 6502 and 8051 are used in lots of little embedded applications. Also don't forget chips like the Z80. GCC does fine for chips like M68K/coldfire & ARM but for some of the smaller chips where special C keywords are common it becomes a pain to make GCC generate good code. The PIC is a piece of crap but thanks to the agressive pricing of Microchip sometimes that POS is thrown at engineers so you have to occasionally deal with that too.

AVR is a wonderful small architecture. I am sure now that Atmel has been gobbled up it will be killed or left to atrophy. But the bottom line is that GCC is not suitable for every embedded task. The world isn't so clean to non-software people.

Re:Make files and emacs

[Anonymous Coward]

If gcc doesn't support your architecture I'd consider that a sign you should do your best to use something else. That is independent of whether you'd actually use gcc in the end.

Re:Make files and emacs

[T.E.D.]

To use these tools on Windows you need to get Cygwin to make it work more smoothly

Unless you need fully-emulated Unix on your PC (clear down to Unix signals, fork(), etc.), Cygwin is really overkill. To make matters worse some of the toolchain renders code built with it GPL unless you pay Red Hat for a looser license.

Any Windows developer who doesn't need full Unix emulation should probably be using MingGW.

Re:Make files and emacs

[Anonymous Coward]

The 6502 and 8051 are used in lots of little embedded applications. Also don't forget chips like the Z80.

SDCC has got covered 8051 and Z80. 6502? Well, I am yet to find a MCU with 6502 inside.

AVR is a wonderful small architecture. I am sure now that Atmel has been gobbled up it will be killed or left to atrophy.

Atmel has been gobbled up?[citation needed]

Re:Make files and emacs

[janeuner]

The GNU toolchain does not support most microcontrollers.

This is only true if you don't know what a linker script is.
If you write your own ldscript, the GNU toolchain supports just about every microcontroller on the market.

Re:Make files and emacs

[Darinbob]

For basic development without having an IDE, Windows is amazingly lacking out of the box. There is no equivalent of grep, no basic scripting language like sh, etc. MinGW (and MSYS) is nice. However you can get a small subset of Cygwin as well, and you can even get mingw link libraries with Cygwin, so the size is not any different and is not overkill. The fundamental difference really is the requirement for cygwin.dll to run the utilities.

Since it's a subset you can easily run across stuff you'd like to have that's not in MinGW but is in Cygwin (maybe not required stuff). So it's nice to have more than just the basic commands. For example, I have shell scripts that build GCC cross compilers which use 'wget' to grab the tarballs from the web. If you're used to unix then it's nice to have a development environment that feels like unix. It also makes switching between environments so much simpler, if you go between Windows, MacOS, and Linux.

Re:Make files and emacs

[Anonymous Coward]

If you mean MinGW as an environment with shell/make/python/scons etc.: Setting that up is just a painful mess. Cygwin installer is much, much simpler.
If you're thinking of the compiler part your argument makes no sense: you can just install and use MinGW from Cygwin, and get automated updates for free (which MinGW still hasn't - I don't know about you but I have better things to do than manually check project web pages for updates).

Re:Make files and emacs

[cbhacking]

Findstr is surprisingly close to grep. It's a new set of arcane command line switches to learn, of course, and even if its regex syntax is identical to grep's (unlikely, though I've never done a proper comparison), you have to deal with the oddities of CMD when it comes to character escaping. However, to state "There is no equivalent to grep" just shows your ignorance of the platform. There's actually a lot of Unix-esque commands in Windows that many people don't know ("tasklist" and "taskkill", "mklink" and "robocopy", the hugely overloaded "net" and the powerful "netsh"). That's not even counting all the stuff in Powershell.

I'm not sure what exactly you consider a "basic scripting language" but modern versions of Windows ship with at least four different scripting languages supported: Command scripts (a superset of DOS batch files, and more primitive than Bourne shell scripts but roughly equivalent in usage), Powershell scripts (possibly a little *too* powerful in some cases, and verbose to write, but capable of nearly anything right up to some GUI stuff), JScript (JavaScript plus some extensions, very powerful if used correctly; runs in Windows Script Host), and VBScript (a BASIC dialect somewhat similar to Visual Basic and intended for scripting small macros and such but can be used for larger tasks; runs in Windows Script Host). Windows Script Host is also extensible - there are plugins for many scripting langauges, including Perl and Ruby - and has been built in for even longer than Powershell (which is only included by default in Vista and later, though is available for XP).

I'll grant you that Windows has no decent code editor out of the box (just because Notepad will happily open .c files doesn't mean it should!) and that the compiler toolchain is not installed by default (although it's a free download from Microsoft). However, it's really nowhere near as bad as you seem to think. They really should provide a better editor, though!

If what you really want is a Unix-like environment in Windows, though, consider Interix. Running in NT's POSIX-compliant Subsystem for Unix Applications (SUA), it's only available on the high-end Windows editions, but it's worth looking into. It integrates much better with Windows than Cygwin does (as a random example, setuid/setgid work) while also feeling much more Unix-y (executables do not need extensions, the file system can be treated as case-sensitive, etc.). Interix comes with a working GCC-based compiler toolchain, although you can build SUA executables using Visual Studio and/or the Windows compiler (MSVC) as well, if you want. SUA is based a moderately old POSIX standard and doesn't support some of the newer stuff, but for "give me a shell where I can run my *nix commands on Windows" it does an excellent job. You can read more about it, including getting the download links, at http://suacommunity.com/ (not associated with the site aside from being a forum member there).

Re:Make files and emacs

[jrumney]

As others have posted, sdcc (based partly on gcc) has 8051 and Z80 covered. There are also other custom versions of gcc that provide support for microcontrollers outside of the main gcc tree.

This is not the answwer you were looking for

[Anonymous Coward]

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.

Re:This is not the answwer you were looking for

[Jimbookis]

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.

Re:This is not the answwer you were looking for

[Anonymous Coward]

If they can't even spell SORT correctly, they must be teh st00p3d.

Re:This is not the answwer you were looking for

[Anonymous Coward]

It's a little bit of a hassle, but you can also compile a patched version of GCC towork for the TI MSP430 family of MCUs. Did this a while back and it worked pretty well. Pain in the butt to get working though.

Re:This is not the answwer you were looking for

[Anonymous Coward]

If you pay a small fist full of Euro's ($500 clams US) with BeRTOS, you get

BeRTOS + Codelite + Project Wizards for a few targets, mostly AVR and ARM + Bunch of common libraries + Support. That works out of the box (mostly) if you're doing a paid gig, that's $500 well spent.

That allows you to do everything you said.

One advantage is codelite generates and uses makefiles in a fairly transparent way. Which means you're not locked down by a license to a particular machine or prevented from doing build testing on a server, like you are with a lot of fully propriety tools. And you're not as locked down to a particular processor vendor.

Re:Bertos

[Jimbookis]

Well if free gets you bent out of shape you can *actually pay* for things like BeRTOS and FreeRTOs if you like.

GNU Toolchain + Eclipse = WIN

[Anonymous Coward]

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).

Re:GNU Toolchain + Eclipse = WIN

[Nevo]

A tutorial for the STM32F0DISCOVERY board can be found: http://thehackerworkshop.com/?p=391

not oss but

[crutchy]

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

Re:not oss but

[Alex Belits]

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.

Re:not oss but

[Anonymous Coward]

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.

Re:not oss but

[DeathToBill]

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:

• Jump to definition - the Eclipse implementation of Ctrl+Click is particularly good.
• Show definition by hovering
• Code folding
• Syntax highlighting - editors like Emacs or Notepad++ get you part way, but for completeness your editor needs to understand the build system.
• Integrated debugger - I can use gdb when I have to, but being able to see variable values and code at the same time while you step through code is invaluable

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.

Re:not oss but

[Darinbob]

There are people who just never used anything but an IDE, and can't imagine life without it, even if they don't need visuals. Ie, it's a glorified text editor (yet dumber than vi or emacs) plus a clumsy debugger plus class browser (really the only thing that keeps some people hooked on them).

Re:not oss but

[Darinbob]

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.

Re:not oss but

[Alex Belits]

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.

So does Emacs.

They do static analysis and performance profiling.

No, they don't.

They have easy ways of pausing execution modifying code and resuming execution.

On an embedded system you should not be able to do that at all.

They let you use version control from inside them.

What for?

They have plug-in oriented debuggers that let you write simple visualizations for your own datastructures and much much more.

The less a programmer touches a debugger, the less bugs are in the code.

All of those things save development time.

Those features are training wheels and crutches. If you can benefit from them, you are not supposed to work on the project in the first place.

Thankfully the vast majority of programmers these days have a choice for using an IDE.

The vast majority of programmers these days have negative performance outcome -- more time is spent by others fixing their mistakes than would be spent working without them.

Nobody sane would want to maintain Makefiles, unless it was the only option.

If it's difficult for you to add a source file to a Makefile, it's impossible for you to write that file.

Your opinion of people who use IDEs is outdated propaganda.

Not of people who use IDEs -- people who NEED IDEs.

Re:not oss but

[FyRE666]

This is the most idiotic thing I've read here in a while (excepting the AC posts). An IDE is not a "glorified text editor"; the fact you believe this shows you have little, if any experience of using one. I've spent almost 30 years writing code in various platforms, in various languages, and while I've used vi and EMACS in the past, would never return to that. Those text editors from the 1970's were designed for an entirely different environment, and using them in preference to an IDE is at best like tying one hand behind your back, and at worst a deliberate and willful waste of time and money. Sure, I still use vi to edit shell scripts and config files on a server, and that's where I believe its strength still lies.

Continue to be a dinosaur if you like, swapping between text files in a "dumb" text editor, ignoring all the productivity aides an IDE can provide, but don't try to kid yourself that you're being efficient, or even smart by doing so. Things move on - we don't travel the country in horse-drawn carriages any more, and we certainly don't need to be the janitors in our own development environments.

Re:not oss but

[Alex Belits]

A good IDE helps you read code.

And that's bad. Good code must be readable on its own. If I need a reverse-engineering environment, it should better be not for things that I, or people on my project, write.

Re:not oss but

[Alex Belits]

At worst, I may benefit from cross-referencing, but it does not have to be welded into the guts of my editor, and insist on creating myriad of little windows, so I can't have my favorite layout -- two editor windows side by side, one where I edit code, one where I refer to things, and a terminal window with shell, where I run compilation, target loader, manual, searches, version control, etc.

IDE will fill the whole screen with its decoration-heavy MDI, stuff file window there, symbol window here, allocate three lines at the bottom for console, add six lines of status, tabs and toolbars around it... On a widescreen monitor I end up seeing less of the source code than I did on 1024x768 CRT, and any attempt to close those parasite window break some functionality. Thanks no.

Re:not oss but

[AmiMoJo]

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.

Re:not oss but

[RevDisk]

Yep. Good code should be readable on its own. Except, there's a lot of bad code in production and it's kinda necessary to be able to understand it.

Granted, last bad code I had to deal with, I replaced the entire convoluted C#.net app with a two PHP pages because it was driving me friggin insane and the functionality needed to be online ASAP.

Re:not oss but

[SWPadnos]

That's a great theory.

Good code must work, but looking nice is optional. Additionally, when debugging code (sometimes code you wrote an hour ago), you need to see not only the code, but what is happening in the hardware. At that point, it's irrelevant whether the code looks nice or not. It's also not always true that good looking code will work. There are errata for microcontrollers (and microprocessors, though those are usually handled at the OS/driver level), so the obvious and beautiful solution may not work at all.

Debugging is what you do when something doesn't work the way you expected. This means that, by definition, the code isn't understandable. If it were understandable, there wouldn't be a problem, right?

Re:not oss but

[ebno-10db]

I usually hand-craft my makefiles.

Have you tried Scons instead? Takes a day or two to get used to its different approach, but after that you will never go back. Make is a crude and error prone tool in this day and age. Also, Scons is a very solidly written and tested piece of software. Their idea of alpha is what most people call final release.

P.S. I'm not affiliated w/ the project in any way.

Re:not oss but

[ebno-10db]

Good IDEs have ...

"Good" being the operative word. Many of the proprietary tools for embedded code have horrible IDE's.

Re:not oss but

[Anonymous Coward]

A good IDE helps you read code.

And that's bad. Good code must be readable on its own. If I need a reverse-engineering environment, it should better be not for things that I, or people on my project, write.

Indeed, would that it were so. Unfortunately, someday, you'll graduate from college and you'll have to work in the real world, where you will find lousy code written by vendors, other teams, or (hopefully) former members of the team.

Re:not oss but

[T.E.D.]

Syntax highlighting - editors like Emacs or Notepad++ get you part way, but for completeness your editor needs to understand the build system.

This is because of the unmitigated evil that is the C preprocessor. Avoid it, and you don't have that issue. (Better yet, avoid languages that support preprocessing...)

Re:not oss but

[Anonymous Coward]

Nobody sane would want to maintain Makefiles

Nonsense. In our build environment, it's crucial that everything must be scriptable -- so IDE UIs are not an option. In addition, tools like "automake" are far too inflexible for our needs.

We have a large, well-designed and well-maintained collection of makefiles, and they're a pleasure to use. Eclipse has good support for importing pre-existing makefiles, so our IDE-using developers lose very little functionality.

Re:not oss but

[Anonymous Coward]

For embedded work that's a non-answer. All the magic happens in the pre-processor. Get good tools and it's much less of an issue. IAR is okay, has it's issues but is pretty pricey. Depending on the job this is/isn't an issue. It really comes down to what hardware are you using or haven't you decided yet? List out your hardware requirements (this may include an OSS build environment in addition to RF, I/O, power etc.) and then whittle down the list of available processors from there. For hobbyist stuff, you probably don't have a long list of requirements other than price, so go with what's relatively cheap and works: ARM. ARM is cheap both for hardware and the software (lot's of OSS available.) Sometimes it's not an option though, like say you need an SOC that supports your specific RF target environment... Really though we need to know more about the project.

Re:not oss but

[Darinbob]

I'm just saying that some people use an IDE that way. They're not using the full capabilities.

On the other hand, as an Emacs user I have not seen an IDE that lets me edit code as easily. Most IDEs I've used are stuck in a single code window at a time. Others are stuck only capable of dealing with one language or family of languages. Very few have anything near to the customization you get with Emacs or Vim, you're stuck with just a few tweaks to indentation style for example.

Emacs may have originated in the 70s, but so what, it did not stagnate and refuse to improve over time. Unix is from the 70s and after evolution is still around today as one of the most modern operating systems. I used an IDE in 1981, GUIs are from the 70s, so why not claim that those are ancient relics?

Plus you gave no examples of what an IDE does that's superior to the dinosaur drawn cart. Yes, there's a class browser, that can be handy as part of an editor. But most of the other stuff could be separate tools; for example, why does the AVR debugger have to be a part of the IDE instead of a standalone tool that could be used with any tool set you want?

Re:not oss but

[Anonymous Coward]

Yeah, had a few people try that because they "didn't understand" the Makefiles. Afterwards they had a system even fewer people understood an in addition didn't work (parallel builds randomly failing).
Now I am quite certain that's not the fault of scons per se, but it's not an indication that it will actually save anyone having a problem with make.
And if you have a problem with make I'd rather suggest something like cmake which at least can help you with stuff like generating/maintaining project files for VisualStudio if you ever need it.

Re:not oss but

[FyRE666]

"Most IDEs I've used are stuck in a single code window at a time."

So which IDEs have you used then? Because either you haven't used any, or you haven't even bothered to learn the most basic features. One of the most popular and well known IDE's - Eclipse - can display as many code windows as you like (hint:click on tab, Window menu, then new Editor - there, that was easy, wasn't it? If that's too difficult, you can drag the tab sideways and it'll open another editor), hell you can even drag them out of the main UI and spread them all over the desktop if you like.

"Very few have anything near to the customization you get with Emacs or Vim, you're stuck with just a few tweaks to indentation style for example."

Where do you come up with this rubbish?! I've read a few of your comments now, and either you're a troll, or totally ignorant about most of the subjects you're gifting us with your opinions about (your post claiming that Windows has no scripting language is just... wow). Honestly, have you actually used an IDE in the last 10 years? You're being beyond ridiculous.

"GUIs are from the 70s, so why not claim that those are ancient relics?"

I would if they still looked and functioned almost exactly the same as the ones we have today. The fact is, that vi and EMACs were designed to be used on dumb character terminals connected over slow serial/parallel cables to relatively slow servers. They still work well over ssh, as they're pretty lightweight and there's no need for a GUI. However for developing on a desktop, it's ludicrous to use them in preference to an IDE for anything except the most basic editing.

"...why does the AVR debugger have to be a part of the IDE instead of a standalone tool..."

Here's a clue; try looking up the "I" in "IDE".

You've obviously completely missed the point of IDEs, and seem unable to accept change, even when the vast majority of professional developers do understand it. There are many things beyond a "class browser", so break out your copy of lynx or gopher and see if you can find a "search engine" like Google. You can then type stuff into it and it'll give you information. You're different and special, and quite frankly I don't have the patience.

And I'm not a "vi hater". Like I say, I've used it for over 30 years, along with EMACs (though nowhere near as often) on various flavours of UNIX and Linux - probably a damn sight more than most people here. I'm fully aware of their limitations, and the fact they cannot compare to an IDE for serious development work. If you're using them, and still manually creating makefiles in the 21st century, you're some kind of masochist, or you enjoy fiddling around with scripts more than getting stuff done(tm).

Re:not oss but

[crutchy]

surely even the die hard cli coders would concede that syntax highlighting is a pretty cool feature at least... code should be readable without it for sure, but it does make a lot of code easier to look at, particularly if your looking for that stubborn bug.

i don't do a lot of embedded (used avrstudio in windows but haven't had the motivation to work through the issues getting avrdude working for an et-avr development+stamp board from futurlec) but plain ol' gedit is pretty good for most other programming (eg php/html/sql/js/css). don't need any plugins and whatnot... just syntax highlighting. the tabs across the top make it pretty easy to switch between files too, and there's a little asterisk next to the filename if there are unsaved changes. it might be nice to be able to choose the fonts/colors of different elements (having been a delphi coder for years i was a bit spoilt) but the default scheme in gedit is pretty nice anyway. there also isn't any debugging tools but it just forces me to use the debugging tool sitting on my shoulders a little more :)

looking at a wall of black and white all day is a surefire recipe for eyestrain.

Re:not oss but

[Darinbob]

So which IDEs have you used then?

Visual Studio couldn't when I had to use it. Eclipse had it but you were still confined to the editing area as I recall, though maybe later they added a way to detach to an independent window or even alternate monitor, but it's been awhile since I used it.

Where do you come up with this rubbish?!

Visual Studio has the worst customization I've seen and it's the one I was forced to use the most. Eclipse at least gives you partial emacs like key bindings, though in many customizations you still need an external plugin. AVR Studio has very little customization, so I basically only use it to load code and debug.

I would if they still looked and functioned almost exactly the same as the ones we have today. The fact is, that vi and EMACs were designed to be used on dumb character terminals connected over slow serial/parallel cables to relatively slow servers. They still work well over ssh, as they're pretty lightweight and there's no need for a GUI.

But vi and emacs do have GUIs, they are not just for dumb character terminals. Why do you say that IDEs have evolved yet imply that vi and emacs are stuck in the past?

and still manually creating makefiles in the 21st century, you're some kind of masochist, or you enjoy fiddling around with scripts more than getting stuff done(tm).

The automatically generated makefiles I've seen from IDEs are very inefficient and clumsy compared to a well made makefile. Maybe there are some good ones out there but I just haven't seen them then. Visual Studio in particular was just awful. I've seen project files for IDEs mess up badly when mutliple people tweak them and then checking, and I've see them fail to build until I've edited the project files by hand. Maybe these were just buggy IDEs, but I've rarely seen someone screw up a makefile merely by adding a file name to a list. And it's essentially mandatory to have some sort of way to automate the build, preferrably on a variety of operating systems (including those that aren't Windows), and make does this very well.

I created a makefile system to replace Visual Studio; mainly because the compiler we used was so abysmally slow we wanted to get to gcc, but at the same time have a better build system than those project files or externally generated makefiles. When done quite a lot of people really loved the makefiles for being easier to manage when adding a new file to a project. I don't think anyone on the team disliked going to makefiles, not even the Visual Studio fans, and the people who wanted to use Eclipse as a replacement were able to easily use the makefile. The time spent creating it paid for itself very quickly.

Re:not oss but

[Darinbob]

Amen there. Some IDEs are pretty nice, if you get around the quirks, such as eclipse. But the ones that come with a proprietary compiler or tool set for tiny embedded CPUs just seem to be awful. The company that creates the hardware is not necessarily the best company to create usable software to develop for the hardware. Sometimes it seems like these are just additional revenue streams; once you've got their proprietary debugger dongle you're stuck using their proprietary toolset.

Even worse if you're not on windows and have to use those IDEs, so you're stuck with a loaner windows laptop or a poorly performing VMware windows emulator.

Re:not oss but

[Darinbob]

I evaluated a lot of make alternatives awhile back. I just found that they all sort of run into troubles making them a hassle to adapt to an existing project. Ie, they made things very easy if your project was the sort that the authors intended, but if you did anything too far out of the ordinary then they seemed much more difficult than the equivalent change to a well written makefile. There are lots of builtin rules for make but they're reasonably easy to understand and override, whereas builtin rules in things like scons or ant were a lot more involved.

Most of the things people hate in make are due to badly written makefiles anyway, or older versions of make (should stick with GNU make in general). Ie, no one should need to do "make depend" anymore, and you can avoid the recursive make and the headaches those cause.

And I do think there can be something better than make, if it's kept simple and doesn't try to do too much. Ie, disambiguate tabs vs spaces, make variable handling simpler (though the normal "=" assignment in make that people find so confusing is one of its most powerful ideas), saner text manipulation builtins, alternate ways to tell if a file needs to be rebuilt (for those times when timestamps aren't working), a more explicit tree of build actions so that recursive or parallel can be used more, etc. But I'd rather not use a full programming language like python for this, as the make syntax is pretty simple ("CFLAGS = -x" preferrable to "env.Append(CFLAGS = '-x')").

Re:not oss but

[Darinbob]

Yup, if your code is ported you're very often going to need a preprocessor support. If not in the language then at least you need it in the build system. Ie, header files are not called the same thing in all systems, different targets will require different approaches in the code, etc.

Everyone hates this stuff, and occasionally someone will proclaim that there must be a way to avoid all this, but pragmatically you have to deal with it and just do your best to minimize the headache.

Re:not oss but

[Darinbob]

Yup, the real world intrudes. I remember being frustrated at some forums in the past when I'd ask "how do I solve this problem" and the idealistic readers would respond "this problem will never exist if the code is been written properly." Pragmatically, one should be prepared to deal with worst case scenarios :-)

Re:not oss but

[Darinbob]

Syntax hilighting is done very well in vi and emacs and slickedit and all sorts of other non-IDE editors, along with lots of customization. You don't need an IDE for that.

Yes, I'll admit that until compile time you won't really know what the preprocessor will do, but some editors manage a stab at doing that. IDEs are going to fail at that problem too beyond the simple case. Ie, if the code has a wide variety of builds that it can be used with or is portable across a variety of targets, then which of the preprocessor options should the IDE choose when hilighting the code? However in practice it may not be a big issue because usually code is written so that highlighting isn't messed up if the wrong preprocessor options are chose; this is more of a problem that occurs with code folding or indentation.

Re:not oss but

[Darinbob]

I should clarify (I wrote it at 2am). By "stuck using" I mean that you must use the IDE in order to compile. Some IDEs will export their builds into a makefile or something similar and allow building the project without using the GUI.

I have seen IDEs that don't have this option though, very often those for small embedded CPUs, and they can really annoy the build engineers until you find an alternate set of tools that work better.

Re:not oss but

[Darinbob]

There are editors like emacs that will do code completion. Lots of them that will do very good cross referencing too, every bit as good as an IDE. Sometimes it's basic, like ctags or etags, sometimes it's much more extensive. I find that some of the stuff people tout as advantages of using an IDE are things that emacs did first in some fashion.

Re:not oss but

[Alex Belits]

Indeed, would that it were so. Unfortunately, someday, you'll graduate from college and you'll have to work in the real world, where you will find lousy code written by vendors, other teams, or (hopefully) former members of the team.

I have graduated from university in 1993, and in 20 years I have found nothing to contradict my position on this. An asshole who writes buggy code and applies software development practice equivalent of bogosort, is in no position to adopt such a condescending tone while talking to me.

Re:not oss but

[Alex Belits]

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.

Anf it still has myriad of parasite windows, tied to Microsoft toolchain that is worthless for embedded systems, and we should expect next version to be touchscreen-based or something similarly idiotic. No, thanks.

Code completion is a really nice feature that only IDEs offer.

If you need code completion, then either you are retarded, your environment is retarded, or both.

A text editor that doesn't constantly guess what you are trying to fat-finger can't give you very much help in that regard.

FTFY.

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.

In a sane project, a second window is a much better way of looking at referred code. You should never try to look for referring code, because it should never matter in a proper design except when you are changing the interface -- and then no GUI will help you.

If you have to constantly look at definitions, you have inconsistent interface in your product, and you should not use it in the first place. Except when it's Windows, but embedded systems developers already fixed that little problem.

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.

Every shit programmer says that. The truth is, Visual Studio is designed for developers Microsoft wants to have -- dumb and churning out loads of tightkly coupled spaghetti code.

And yes, Atmel Studio will still let you use a makefile and command line compilation if you really want to.

So will Emacs, but it won't impose retarded internal "tools" on the programmer.

Re:not oss but

[crutchy]

omg you mentioned visual studio

-1e12 shill :)

for compiled software i use delphi (if i had a need for linux versions i would use lazarus/freepascal), but for scripting web apps (php/html/sql/js/css) i have gedit on one screen and a browser open on the other. that way i can hit ctrl+s and then tab to the browser and press F5 to see the effect. i guess everyone developing web apps probably uses 2 screens nowadays. at work i only have one screen on the development server, with the other screen with the browser open beside it but connected to a workstation. same but different.

Re:not oss but

[Alex Belits]

i guess everyone developing web apps probably uses 2 screens nowadays.

Maybe. When I had to do that, it was three screens -- editor, non-IE browser, IE6. Because IE6 is special.

GCC

[Anonymous Coward]

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.

Geany

[Anonymous Coward]

Geany, works like a charm. Although you still have to hassle with makefiles and stuff. Wouldn't touch eclipse though, it's slow as hell and not intuitive.

Eclipse? Pain in the A** with Embedded Systems.

[Anonymous Coward]

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?

Best way?

[Anonymous Coward]

A magnetic needle and a steady hand.

eCos

[edgargri]

I use eCos + GNU toolchain + Eclipse + OpenOCD (for ARM targets).

Codelite and maybe CodeBlocks

[Anonymous Coward]

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's no good option

[tlambert]

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.

Re:There's no good option

[serviscope_minor]

(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.

Re:There's no good option

[Anonymous Coward]

I don't know, the tool support for PICs seems really crummy compared to alternatives. Especially the compiler is a major pain point, everyone else (eg AVR, MSP430, ARMs from M0 to A10) is using GCC, but with PIC you are stuck with some crappy proprietary compilers instead. The PICs might be good chips and Microchip a nice company but without GCC toolchain it's all for nothing.

Re:There's no good option

[AmiMoJo]

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.

Sorry, it wasn't clear if you were saying that Atmel is good at documenting their interfaces or not. Older Atmel parts use SPI and the newer ones have two wire interfaces (PDI or TDI), all of which are well documented. There are open source programmers (hardware) and an open source command line programming application called AVRdude. Even the debug interface stuff is well documented and supported on Linux.

Perhaps that is what you were saying, I'm not sure.

Re:There's no good option

[AmiMoJo]

The programmer is even another PIC and they give away the source code as well as document the programming interface!

The problem is that their debuggers are absolutely terrible. I have to support some products using old 8 bit PIC18s that are not supported by the ICD3, and the ICD2 doesn't work on 64 bit platforms so I have to use it via a virtual machine. Both of them are flaky, often stop responding or fail to connect properly and don't seem to be very robust.

On top of that they both seem very limited in terms of the number of breakpoints you can set, lack of data breakpoints and so forth.

If they could just sort their hardware out they might have a nice platform there.

Re:There's no good option

[mjwalshe]

er do you even know what PIC's are? IE a Harvard architecture with tiny amounts of memory is not going to be programmed vial the bloated C++ Linux tool chain most people use the PIC assembler there are hyper cut down versions of HLL to help with this if you cant hack assembly language.

Re:There's no good option

[Matt_Bennett]

On top of that they both seem very limited in terms of the number of breakpoints you can set, lack of data breakpoints and so forth.

If they could just sort their hardware out they might have a nice platform there.

Breakpoints and other debugging features are a matter of hardware- it adds silicon, and therefore cost. Some PICs come with embedded debugging hardware (in every part), some have special debug parts ($25-$50 US)- compared to the development parts of yesteryear, these are super-cheap.

The ICD2 is a *really* old design- it is now obsolete, unfortunately, there are lots out there. The ICD3 is a far more robust platform, from the drivers on up.

Re:There's no good option

[Anonymous Coward]

The PICs go up to a few kB of memory, and 4 kB memory devices are perfectly programmable with gcc (though you should be using stuff like whole-program optimization). There might be some specific issues you might want to fix up by switching to assembler, but if you write everything in assembler you're probably wasting a lot of time.
And honestly if you program the 512 kB PIC32 one in assembler I think you must be farily crazy unless you have very specific needs.
Of course if you want to use C++ you have to _really_ know the language or it will be a horrible failure.

Re:There's no good option

[serviscope_minor]

It's mildly annoying, but I use PICs for the really small stuff (e.g. the 12F875). once you get to that stage, since there's 1k of program space and 64 bytes of RAM, the programs are barely big enough to make C or C++ worth it over ASM.

And the reason for no gcc is because of the banked memory. It's nasty, but probably one of the reasons they're cheaper and lower power.

Re:There's no good option

[serviscope_minor]

bloated C++ Linux tool chain

You know that the Atmel chips can be and are frequently programmed in C++, using GCC, right?

there are hyper cut down versions of HLL to help with this

The cut down version of C++ is called C++. Don't want exceptions? No problem. Don't want virtual functions? Don't pay for what you don't use.

Re:There's no good option

[Anonymous Coward]

> er do you even know what PIC's are?

Do you even know what attiny or msp430 series are? Both go lower than PICs and yet can be programmed with GCC-based toolchain

Re:There's no good option

[AmiMoJo]

Actually we find we have more problems with the ICD3. It seems like the boost circuit for generating programming voltages is flaky. Also it doesn't support huge numbers of older PICs, so we have products that are only five years old but can't be debugged on 64 bit machines.

Re:There's no good option

[Anonymous Coward]

1 k flash/6 byte RAM is not smaller than an Attiny, and writing C code works mostly fine for that, even if you can discuss if it is worth it.
It does give you things like whole-program optimization and thus automatic decision on whether to better inline some code or use function calls for example.
And I doubt it's impossible to hack gcc to handle banked memory. There are other architectures that need to cobble together addresses as well, e.g. ARM thumb. So you have the additional constraint that the highest bit must be in a special register. (though it might make sense to just treat it like a separate memory instead. Either way I can't see why it would make it impossible for gcc to support it)

Re:There's no good option

[mjwalshe]

I was talking about PIC's the PIC16F84 only has two banks of 128 bytes of ram

Re:There's no good option

[Matt_Bennett]

I take issue with the 'doesn't support huge numbers of older PICs' Microchip has something on the order of 600-700 different PICs in production (and which rarely if ever get obsoleted) - looking through the latest MPLAB 8, I see a few rfPICs and some PIC18s that are not supported by ICD3. But if the part you're using isn't supported, that can be a huge issue.

I've seen quite a few issues with the boost circuit, they haven't traced back to an issue with the ICD3 itself- they were due to the resistor on the MCLR pin being too low, and dragging down VPP. The datasheets pretty universally (now) specify 10K on the MCLR pull up. The boost circuit on the ICD3 is more controllable, but not as strong as the one on the ICD2. With some of the newer parts, the ICD2 can very easily over-voltage MCLR.

Re:There's no good option

[AmiMoJo]

This is a PIC18 part, I don't have the exact part number to hand.

The VPP on the ICD2 is completely broken. You need an external PSU to get it up but often times it just fails to switch. Removing the external power several times will eventually make it work and then programming is okay. Maybe you are right about the ICD3 one, but we followed the advice given in the datasheet at the time and are not about to retrofit resistors on tens of thousands of units.

It's all nonsense anyway. Atmel tools don't have these problems. Texas tools don't have these problems. NXP tools don't have these problems. Only Microchip debuggers.

Why 8051?

[residents_parking]

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.

Re:Why 8051?

[Anonymous Coward]

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.

Re:Why 8051?

[serviscope_minor]

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.

Re:Why 8051?

[AmiMoJo]

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.

IAR issues.

[Ihlosi]

I'm using IARs IDE. However, starting with version 5.50 (EWARM) it seems to have an issue drawing its GUI elements which, over time, leads to interesting screen corruption and an eventual crash to the desktop (running under XP, when running under W7 the screen corruption doesn't happen, but the crash eventually occurs, too). Version 5.42a was still fine.

However, I'm stuck with it, so that's what I'm using.

Anyone else having CTD issues with IARs IDE?

Some Options

[ThePeices]

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.

Open Source IDE for ARM tools

[kbrafford]

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/

PIC32, not 8051

[flyingfsck]

The reason you cannot find anything is because you are stuck in the dark ages. The are gazillions of PIC based boards out there. Anybody with half a google clue can find them.

Not Code Composer Studio

[Anonymous Coward]

Just buggy, no more words needed.

Re:Not Code Composer Studio

[Eddy_D]

it used to be.. true. They recently moved to become a wrapper for Eclipse though, so it should only be as buggy as Eclipse is now.. knock on wood. FYI, I used to use CCS in the early 00's working with C5x DSPs, man whata a pain in the @SS it was to use! - Eddy_D

OpenRISC

[Anonymous Coward]

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.

Re:Bertos

[Anonymous Coward]

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.

uTron (TOPPERS)

[Kagetsuki]

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.

Right tool for the job

[Anonymous Coward]

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.

VS2010 + NETMF

[Anonymous Coward]

Visual Studio is not itself OS but NETMF (the .NET MicroFramework) is open source. The most common but far from only implementation is the ARM9 based Netduino.

You can all sneer about performance if you like, but among the shields for the Netduino Plus is a Xilinx FPGA board. As for stability, the same habits required for stable C work nicely for C# ie don't do dynamic anything and resource demands will be 100% predictable. Or you can extend the framework, it being open source, and get your performance that way. Prototyping is quick and easy and you can use the VS2010 step-through debugger with all the mod cons of desktop C# while the code runs on a Netduino. Variable inspection and value editing are available whether the code runs on hardware or in an emulator.

This only helps with SoC Arm9s

Relevant humour

[John Allsup]

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.

GCC for the Propeller/Prop2

[evanh]

Further reading at http://forums.parallax.com/

Re:GCC for the Propeller/Prop2

[Anonymous Coward]

AVR Studio with Atmel AVR microcontrollers ?

Netbeans, believe it or not...

[Anonymous Coward]

works out pretty well for C/C++ cross development. It will also, if properly tricked up, run
remote GDB so you can just build gdbserver for your target and debug throug that.
Takes a bit of tweaking. Eclipse is also popular, but not my choice.

yocto project

[Anonymous Coward]

All this and no one has mentioned the Yocto Project?

https://www.yoctoproject.org/

One of the best embedded systems organizations, Wind River, contributes a lot to this and their own VxWorks is a kick ass RTOS. If you want to build a complex extreme performance high reliability real-time application, VxWorks is the way to go. Large chunks of the telephone system and the 'net run on VxWorks. Just sayin'.

Pick your poison.

[Lumpy]

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.

The GNU ecosystem is just cost effective.

[Anonymous Coward]

Fully fledged 32-bit ARM's are dirt cheap. Run them with MMU & Linux or just a closed loop program, really does not matter.
I just don't get why anyone would not go for something like the 8051 and IAR and not the full GNU tool solution with a real competent ecosystem.
Going proprietary just doesn't make any sense whatsoever unless you have tons of cash to spend paying licenses and paying developers to write code for your own ecosystem.
Some might make a case of it, but for the 99.99 percent of the rest, I just don't see it.

Re:The GNU ecosystem is just cost effective.

[james_a_craig]

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.

Re:The GNU ecosystem is just cost effective.

[Anonymous Coward]

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.

Divering embedded meaning?

[Anonymous Coward]

Embedded once upon a time used to mean, embedded micro controllers. They'd be running some esoteric OS or just a closed loop.
Nowdays everyone calls everything that is not a PC, embedded.

Just a suggestion.

Embedded SYSTEMs - Large systems with fully fledged OS's and tons of software capable of doing GENERIC things.
Embedded MICROs - 8051's (and similar), running closed loops or small esoteric RTOS's

This would greatly enhance readability.

Re:Bertos

[AchilleTalon]

I wasn't aware I was supposed to know everything about everything. Thanks for telling me.

There are good solutions

[porcinist]

I have used, at one point or another, almost every type of embedded system there is. My company specifically targets clients with embedded needs and I solve those applications entirely in OSS (except for programmable logic, where OSS is not an option).

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.

On free good tools

[Eddy_D]

Just my two bits, I have been using Embedded IDEs for over 10 years and not found any good free ones. The issue is that it takes a lot of effort to get an embedded IDE to be not only useable, but really seamless. The points of difficulty are usually in the debugger and in the physical connection to the processor

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.

GNU Toolchain + vi = Sufficient

[janeuner]

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!

Re:GNU Toolchain + vi = Sufficient

[maxwell demon]

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 don't understand the penchant for a compiler. 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 assembler...it is terrifying!

Of course, real programmers use cat > a.out :-)

Insightful but low reading comprehension?

[Anonymous Coward]

"alternatives to IAR and Keil" and "a fully integrated development platform."

He didn't ask for an OS. He asked for the equivalent for IAR/Keil, as in an IDE with JTAG/ISP.

Ass-Backwards

[Anonymous Coward]

You don't start with an ideological solution and then try to find a problem. You start by finding the best solution and if you are lucky it's OSS. Doing it the former way assures you'll have substandard solutions and it means you are a shitty engineer.

Interesting

[Anonymous Coward]

Im not using any of them, I have not heard about those platform
but, I would like to know the use of them.
alarmas