Alternative languages for embedded programming

Question

I`m looking for alternatives programming languages (from assembly, C, C++ and basic) to embedded (microcontroller) programming.

Is it possible for example, to program microcontrollers in C# or Java? Maybe Ruby or Python?

If possible, please post development tools and hardware used.

Answer 1

First, asm and C are the primary choices, and for good reason. Start there and build a foundation to fall back on.

We noticed the wikireader, is fourth driven or at least has some forth components. A language I have never learned but might some day.

The Dallas Semiconductor TINI board (dallas semi has been assimilated by maxim) was purpose built to be an embedded JAVA board. As a result they had to put tons of ram and flash on it relative to a normal microcontroller/board. I think those boards are still out there.

At the time the TINI came out the argument was there that java could be embedded. Perhaps it can. My understanding is that Python is similar to java in the sense that it is interpreted or compiled down to a common byte code or machine code. In the case of JAVA, the jvm is the emulator of that common machine language for a specific target. If that is the case with python then in theory python can be as embedded as java. I am told that forth is stack based or stack like which is what java is, so that would also imply that forth can work embedded as well java can. So long as you have enough ram for the stack and enough program space and bandwidth for the vm/emulator. And there in lies the problem. And there in lies the problem. ram and rom are expensive, the dominant price and power consumers of the part. Who wants to pay $10 for something so that it can use java when they can get more out of a $1 part using C/asm? At least that is what the market is going to tell you.

On the other hand, there is this notion that linux can be embedded and people are using it that way. That means mega or gigabytes, where kilobytes would have done the job faster, better and more reliably (although arguably at a higher up front development cost). So some of the newer embedded ARM's and mips are going to have the resources you are looking for.

My understanding is that gcc and perhaps eventually if not already llvm may have java and other frontends (ada for example, maybe pascal). which means you can write in java for example but have it compile down to machine code for the target processor and not the generic java byte code or whatever it is called. That would be your ideal situation to get from the scripty language to real machine instructions (assuming you continue to pursue something other than C/asm).

Short answer: Possible? Yes, possible. The Dallas TINI is or was a specific example using java. Look at the wikireader as well, using what appears to be forth.

Answer 2

There's also Lua. See eLua.

Answer 3

You could try python-on-a-chip, supported on mbed or STM32 platforms, portable to other platforms as well.

Like most things in the embedded world, your options depend on your constraints. Have you committed to a platform? How much code space/RAM do you have available? Can your chip support an operating system?

Answer 4

I used to program Zilog Z180's in FORTH. I would not want to do it again!

C# can be used on .NET Micro, but you will need a 32bit processor with at least 256Kb of RAM, and it is not good for real-time applications. High productivity for teh right application however, and it is possible to employ coders without extensive embedded expertise if that is in short supply and C# expertise is not.

Java is feasible, especially on a part with hardware bytecode execution such as the Jazelle unit on some ARM9 and higher end ARM devices. However it still needs a JVM port, and that can be expensive. It is usually used as part of an embedded Linux port, so you have all that overhead as well, so is probably even more resource hungry than .NET Micro.

Intel used to produce a very simple language called PL/M (programming language for microcomputers) for various Intel processors from the 4004 to the 803286 but it is no longer available or supported, and has no benefits over C.

Ada is widely used, especially in military, aviation, and safety critical applications.

Embedded Pascal is available for some targets.

You can use NI LabView as a code generator for embedded systems. In fact that is what Lego Mindstorms is based upon. The industrial version is somewhat more sophisticated and full featured than the toy version however! Likewise you can generated embedded code using MATLAB and SimuLink. These are not necessarily the most efficient, but more thinks like precision motor controland signal processing, SimuLink can be highly productive.

Answer 5

For PIC's there's JAL, it comes with some nice libraries.

Answer 6

FORTH has it virtues on small machines, but there is a bit of a learning curve.

FORTH has many sides, any or all of which can be used for embedded development.

Part of the struggle with FORTH is dealing with the dichotomy that is presents.

On the one have, the small, raw FORTHs of yore, ye olde Z-80 FigForth threaded interpreters, are VERY low level in terms of the environment they provide you, the developer. They are certainly higher level than assembly, but, arguably, (in some case) than C.

For example, out of the box, FORTH (these little, older FORTHs many people think about with small CPUs) doesn't let you allocate dynamic memory, or do (easy) pointer arithmetic. It doesn't even have "structures" as a language concept. You basically get to play with offsets via constants. Initially, you couldn't even do recursion. Arguably, it's biggest limitation is that it has no real data types. It's not typed at all, it's all numbers that may or may not be pointers to memory that may or may not be data or characters or whatever.

Of course, at the same time, you can get the full system, with an assembler and editor, etc. all within 8K of RAM.

So, in that way, it's, yes, higher level than assembly, but lower than C.

But (and it's a big But)...

While it may start low level, you, as the programmer, can lift it up to whatever level of abstraction you are happy with -- you can take it pretty much as far as you want to go.

You want structures? You want a heap to malloc from? You want an object system? Those are all available for the building upon the foundation.

You want first class support, at the language level, for your little ISAM based record system? Easy.

Consider Common Lisp. Two of its most powerful features are Macros and the Reader, which give you the opportunity to convert arbitrary text into code that's then compiled.

FORTH has the same capability, only it goes even farther. In the older FORTHs you even have access to the compiler itself, not just the input to the compiler. The threaded interpreters are pretty damn simple, and easy to modify. You have such "raw" access to the memory image you can literally do whatever you want -- all from the FORTH system itself.

This is how FORTHs can "port themselves" to other architectures easily, how they can optimize specific data structures. Many older FORTHs are Threaded Interpreters, but there's no reason they have to be. You can compile FORTH in to pure machine code (i.e. no interpreter at all) if you like.

Of course, on modern "micro" controllers, you could likely simply port the entire dev environment over to the device. Never copy an image over the wire again (until you back it up of course).

All of this takes work, of course. Maybe too much work, that's up to the designer/coder to decide. It's a primitive toolkit that can be used to make very powerful things.