I`m looking for alternatives programming languages (from assembly, C, C++ and basic) to embedded (microcontroller) programming.
Is it possible for example, to programm microcontrollers in C# or Java? Maybe Ruby or Python?
If possible, please post development tools and hardware used.
Thanks
If you're programming microcontrollers you will almost always want C or Embedded C++, anything else just takes up too much valuable on chip flash. Those are the only two languages I would recommend, if you're not hand assembling things (and really, who does that these days?)
I use Embedded C++ just like everyone else, on Arduino for instance, I also use C for the most part on an ARM board I make use of.
If you count JavaCard as a microcontroller, then you can program it in Java.
You can write code in C# under .NET. You must use .NET Micro Framework.
But I preffer C language for this stuff like things. I writing in C on ARM7Cortex-M3 processor with Keil Framework and this working good, this framework supports many programming interfaces and processor's.
Note: Micro Framework is NOT a realtime OS (by Matthew Whited from comments)
FORTH has been popular in embedded systems for a long time. I have no specific experience with it but it is very cleverly designed to provide a lot of functionality in a small amount of space even on difficut microcontrollers, using threaded code interpretation methods. It is easy to get development environments for FORTH, and it is pretty easy to port it to new systems.
People love or hate it, because it insists that you code in a reverse polish notation (basically its a stack machine with a big pile of predefined operators).
This SO thread seems relevant: http://stackoverflow.com/questions/122292/forth-love-if-honk-then
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.
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.
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?
I've used custom pcode interpreters on smaller machines to save code space.
Most embedded systems have some part which may be high performance, and a lot of stuff that runs rarely or for which performance doesn't matter.
I've implemented a number of applications in which the hard core fast stuff was written in assembler (because that's all I could get as a development tool), and then coded a pcode interpreter for my own private instruction set typically with stack machine orientation.
Pretty much all you need to get started are opcodes for PUSH/POP operand (of 8 or 16 bytes), ADD/SUB/MUL/DIV, CMP, IF/GOTO, and call, and these are easily coded even in ugly instruction sets. After that you try to write subroutines using CALL, and only add opcodes to do those things that the pcode can't otherwise do (device I/O), or that require some faster compuation.
Coding in such a pcode interpreter is pretty easy even with an assembler; you simply write "BYTE " assembler directives interspersed with "WORD " directives depending on what the opcode wants.
This answer is essentially the poor man's variation of the FORTH answer I gave earlier.
There are several physically small devices that run a more-or-less full version of Linux. You can program them in pretty much any programming language that runs on Linux, i.e., practically any programming language known to mankind.
For microcontrollers with tiny amounts of RAM, far too small to run Linux, see StackOverflow: "What are the available interactive languages that run in tiny memory?".
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.
I think there are (at least) two answers to this question. First I want to emphasize that if you are programming close to the hardware and with limited resource, you will find that C or C++ is the tools that will suite you best. High-level languages does not make it easy to do bit-level manipulation etc, but these things are easily done in C. Part of the solution is to figure out which tool is the best for the job, and for low-level stuff Python or Ruby is not what you want.
On the other hand if what you want to do is simply to write an application that run on a micro-controller, then you may have several options depending on the target you are working on. Many so-called embedded platforms are far more powerful than only a few year old workstations and therefore run stock Linux which gives you a large number of language options.
For Python there used to be an interesting project: Deeply Embedded Python, but I think it has been dead for sometime now.
You can take a look at very powerful AvrCo Multitasking Pascal for AVR. You can try it at http://www.e-lab.de. MEGA8/88 version is free. There are tons of drivers and simulator with JTAG debugger and nice live or simulated visualizations of all standard devices (LCD, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER...).