Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Best OSS Embedded Development Platform

samzenpus posted about a year ago | from the a-little-help-from-my-friends dept.

Programming 128

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

cancel ×

128 comments

Bertos (-1)

Anonymous Coward | about a year ago | (#43578523)

For the price Bertos is not too shabby. http://www.bertos.org Develop in Windows or Linux.

Re:Bertos (0)

Anonymous Coward | about a year ago | (#43578551)

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)

Re:Bertos (1)

Jimbookis (517778) | about a year ago | (#43578561)

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

Re:Bertos (5, Insightful)

Anonymous Coward | about a year ago | (#43579137)

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.

Re:Bertos (3, Insightful)

AchilleTalon (540925) | about a year ago | (#43580235)

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

This is not the answwer you were looking for (1)

Anonymous Coward | about a year ago | (#43578559)

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 (4, Informative)

Jimbookis (517778) | about a year ago | (#43578569)

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 (0)

Anonymous Coward | about a year ago | (#43582503)

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 (0)

Anonymous Coward | about a year ago | (#43579077)

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

SDCC (5, Informative)

ozmanjusri (601766) | about a year ago | (#43578545)

Re:SDCC (1)

taniwha (70410) | about a year ago | (#43578697)

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 (1)

ozmanjusri (601766) | about a year ago | (#43578733)

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 (1)

taniwha (70410) | about a year ago | (#43578929)

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 (0)

Anonymous Coward | about a year ago | (#43580129)

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 (1)

ozmanjusri (601766) | about a year ago | (#43580499)

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:SDCC (1)

Foresto (127767) | about a year ago | (#43579041)

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

BeRTOS for the First Post (0)

Jimbookis (517778) | about a year ago | (#43578555)

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/ [bertos.org] A pox on my first AC post on the subject.

Make files and emacs (5, Informative)

Anonymous Coward | about a year ago | (#43578557)

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 (5, Interesting)

MadMing (731835) | about a year ago | (#43578651)

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 (2)

AmiMoJo (196126) | about a year ago | (#43579463)

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 (1)

Anonymous Coward | about a year ago | (#43578685)

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 (2)

mirix (1649853) | about a year ago | (#43578909)

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 (1)

Anonymous Coward | about a year ago | (#43579763)

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 (1)

Anonymous Coward | about a year ago | (#43580891)

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 (1)

Anonymous Coward | about a year ago | (#43579671)

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 (0)

Anonymous Coward | about a year ago | (#43579805)

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 (1)

janeuner (815461) | about a year ago | (#43581789)

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 (1)

nodan (1172027) | about a year ago | (#43578717)

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 (1)

thoughtspace (1444717) | about a year ago | (#43578805)

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 (5, Insightful)

Darinbob (1142669) | about a year ago | (#43578937)

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 (1)

T.E.D. (34228) | about a year ago | (#43580553)

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 [mingw.org] .

GNU Toolchain + Eclipse = WIN (4, Informative)

Anonymous Coward | about a year ago | (#43578587)

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 (1)

Nevo (690791) | about a year ago | (#43579681)

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

GNU Toolchain + vi = Sufficient (1)

janeuner (815461) | about a year ago | (#43581619)

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 [kunen.org]

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!

I am seeking for (-1)

Anonymous Coward | about a year ago | (#43578607)

"seeking" doesn't directly replace "looking" in this case. You should say "I am seeking alternatives..."

not oss but (1)

crutchy (1949900) | about a year ago | (#43578681)

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 (4, Insightful)

Alex Belits (437) | about a year ago | (#43578831)

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 (4, Informative)

Anonymous Coward | about a year ago | (#43578899)

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 (1, Informative)

Alex Belits (437) | about a year ago | (#43579067)

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 (1)

ebno-10db (1459097) | about a year ago | (#43579973)

Good IDEs have ...

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

Re:not oss but (0)

Anonymous Coward | about a year ago | (#43581131)

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 (4, Insightful)

DeathToBill (601486) | about a year ago | (#43578903)

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 (1, Redundant)

Alex Belits (437) | about a year ago | (#43579461)

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 (1)

Alex Belits (437) | about a year ago | (#43579501)

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 (1)

RevDisk (740008) | about a year ago | (#43579535)

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 (1)

SWPadnos (191329) | about a year ago | (#43579929)

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 (0)

Anonymous Coward | about a year ago | (#43580319)

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 (1)

ebno-10db (1459097) | about a year ago | (#43579955)

I usually hand-craft my makefiles.

Have you tried Scons [scons.org] 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 (1)

T.E.D. (34228) | about a year ago | (#43580601)

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 (0)

Anonymous Coward | about a year ago | (#43581215)

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 (2)

Darinbob (1142669) | about a year ago | (#43578971)

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 (2)

AmiMoJo (196126) | about a year ago | (#43579527)

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 (1)

Darinbob (1142669) | about a year ago | (#43578965)

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 (1, Troll)

FyRE666 (263011) | about a year ago | (#43579153)

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.

GCC (1)

Anonymous Coward | about a year ago | (#43578683)

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 (0)

Anonymous Coward | about a year ago | (#43578711)

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

Anonymous Coward | about a year ago | (#43578781)

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? (1)

Anonymous Coward | about a year ago | (#43578797)

A magnetic needle and a steady hand.

eCos (1)

edgargri (2698399) | about a year ago | (#43578849)

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

Codelite and maybe CodeBlocks (1)

Anonymous Coward | about a year ago | (#43578879)

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 (2)

tlambert (566799) | about a year ago | (#43578881)

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 (3, Interesting)

serviscope_minor (664417) | about a year ago | (#43579063)

(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 (1)

Anonymous Coward | about a year ago | (#43579345)

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 (0)

mjwalshe (1680392) | about a year ago | (#43579657)

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 (0)

Anonymous Coward | about a year ago | (#43580381)

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 (1)

serviscope_minor (664417) | about a year ago | (#43581023)

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 (0)

Anonymous Coward | about a year ago | (#43581683)

> 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 (1)

serviscope_minor (664417) | about a year ago | (#43580991)

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 (1)

AmiMoJo (196126) | about a year ago | (#43579497)

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 (1)

Matt_Bennett (79107) | about a year ago | (#43579747)

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 (1)

AmiMoJo (196126) | about a year ago | (#43581773)

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 (1)

AmiMoJo (196126) | about a year ago | (#43579481)

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.

Why 8051? (1)

residents_parking (1026556) | about a year ago | (#43578883)

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? (2, Informative)

Anonymous Coward | about a year ago | (#43578995)

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? (4, Informative)

serviscope_minor (664417) | about a year ago | (#43579089)

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? (-1, Flamebait)

residents_parking (1026556) | about a year ago | (#43579289)

Do you think it's possible my world is different from your world? So lay off the ad-hom.

Re:Why 8051? (2)

AmiMoJo (196126) | about a year ago | (#43579563)

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

Ihlosi (895663) | about a year ago | (#43578901)

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 (2)

ThePeices (635180) | about a year ago | (#43578927)

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 (1)

kbrafford (2634775) | about a year ago | (#43578943)

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/ [github.io]

PIC32, not 8051 (0)

flyingfsck (986395) | about a year ago | (#43578991)

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 (1)

Anonymous Coward | about a year ago | (#43579005)

Just buggy, no more words needed.

Re:Not Code Composer Studio (1)

Eddy_D (557002) | about a year ago | (#43581483)

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 (1)

Anonymous Coward | about a year ago | (#43579127)

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.

uTron (TOPPERS) (4, Insightful)

Kagetsuki (1620613) | about a year ago | (#43579177)

http://www.toppers.jp/ [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.

Insightful but low reading comprehension? (0)

Anonymous Coward | about a year ago | (#43581717)

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

Right tool for the job (1)

Anonymous Coward | about a year ago | (#43579285)

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 (0)

Anonymous Coward | about a year ago | (#43579333)

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 (1)

John Allsup (987) | about a year ago | (#43579381)

The lessons enumerated at http://deardiary.chalisque.org/multistage-computer-language-evolution/ [chalisque.org] 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 (1)

evanh (627108) | about a year ago | (#43579399)

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

Re:GCC for the Propeller/Prop2 (0)

Anonymous Coward | about a year ago | (#43579479)

AVR Studio with Atmel AVR microcontrollers ?

Netbeans, believe it or not... (0)

Anonymous Coward | about a year ago | (#43579445)

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 (0)

Anonymous Coward | about a year ago | (#43579469)

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

Lumpy (12016) | about a year ago | (#43579553)

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

Anonymous Coward | about a year ago | (#43579597)

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

james_a_craig (798098) | about a year ago | (#43579875)

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

Anonymous Coward | about a year ago | (#43580337)

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? (0)

Anonymous Coward | about a year ago | (#43579663)

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.

There are good solutions (3, Interesting)

porcinist (1847634) | about a year ago | (#43580485)

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 (2)

Eddy_D (557002) | about a year ago | (#43581617)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...