6

Pardon my naïveté, but it seems like most programmable devices (FPGAs, PLCs, PICs, etc.) are programmable using the C or C++ languages, or a variant of one of these. Are there any devices out there that use something like D, Mozilla Rust, or Google Go? I realize that the latter two, especially, are immature languages; but surely someone, somewhere has released an experimental product.

Does anyone have any suggestions?

arussell84
  • 163
  • 5
  • 1
    Do you like Forth? That's a popular language for embedded devices. There was a recent article [here](http://www.forth.org/lost-at-c.html) and discussion on Hacker News [here](http://news.ycombinator.com/item?id=2574204), with very informative comments. Don't have time to bring any of that over here at the moment, though. If someone wants to craft that information into an answer, I'd be much obliged! – Kevin Vermeer May 23 '11 at 03:12
  • @reemrevnivek I actually saw that article earlier today, and I don't think Forth fits my personal taste, but definitely thanks for sharing that! – arussell84 May 23 '11 at 04:06
  • @arussell - Yeah, I wasn't sure it fit the mold of D, Rust, or Go. – Kevin Vermeer May 24 '11 at 22:14
  • 2
    What would the modern languages bring to (really) embedded programming? PS. In this context by embedded programming I mean programming in which a Cortex-M3 is a screaming performance beast and you only ever use on-chip SRAM and Flash. – jpc May 24 '11 at 21:54
  • related: [What are good options for beginning hardware programming using high-level languages?](http://stackoverflow.com/questions/366991/what-are-good-options-for-beginning-hardware-programming-using-high-level-languag) – davidcary May 28 '11 at 03:48
  • related: [What are the available interactive languages that run in tiny memory?](http://stackoverflow.com/questions/1082751/what-are-the-available-interactive-languages-that-run-in-tiny-memory) – davidcary May 28 '11 at 03:50
  • @davidcary I was looking more for answers about system programming languages rather than higher-level or interpreted languages, but there's still some good info in those links. Thanks. – arussell84 May 28 '11 at 22:04
  • @jpc It seems to me that rather than being genuinely curious, you're simply implying that you aren't interested in the answers to my question. If you aren't interested in anything but C, you can just ignore my question. Otherwise, I'd be happy to answer more specific questions. – arussell84 May 28 '11 at 22:14
  • @arussell84: I am genuinely interested in the answer to both your question and mine. Also: believe me that I really am fed up with plain C in embedded programming. I believe there is much to improve in the field of embedded programming languages but I do not believe that "normal" programming languages for big computers will offer much of this improvement. This is why I asked how do you expect them to help. – jpc May 30 '11 at 01:10
  • @jpc In that case, bear with me, as comments are only allowed to have so many characters. D is supposed to be an improvement on C++. I don't mean higher-level such as C# or Java. Can still manually manage memory and use pointers. Read the [D overview](http://www.digitalmars.com/d/2.0/overview.html). Two features I'm particularly interested in are closures and anonymous functions. Go and Rust I believe might become popular, but might not actually be suitable for embedded devices. Too soon to tell. Objective-C might work, though; I haven't looked. – arussell84 May 30 '11 at 22:00
  • I was always under the impression that closures without garbage collection are a pain. Maybe you should look at blocks (a recent LLVM feature from Apple). You may check Objective-C since it has some nice replacements for closures (the target/action protocol) and I believe an embedded-system-friendly libobjc would not be much work. OTOH when you start writing things like HTTP servers or such (where I believe dynamic binding and modern languages to be most useful) then you will quickly run out of memory with or w/o a modern language. – jpc Jun 01 '11 at 10:52

9 Answers9

14

You don't need different devices to use these languages, you just need the appropriate software system.

The main issues why this is not done more often are:

  • These languages typically need more resources (memory, runtime) for the same task. For large volumes the reduced effort in programming would be more than offset by higher hardware costs.

  • Most higher-level languages need dynamic memory allocation with garbage collection, which is hard to do in a real-time setting.

  • It is harder to get embedded developers for these languages.

That said, there are such things as Real-Time Java, which are used in real embedded systems.

starblue
  • 6,462
  • 2
  • 21
  • 35
  • 1
    While not providing all the details I was looking for, your answer ultimately led me to my answer. Taking a PIC as an example, there are multiple steps in between the process of writing code on your computer and having that code running on the PIC. You have to compile it and upload it, and there are different ways to do even these. In order to, say, write with D for a PIC, someone would have to write an equivalent of [SDCC](http://sdcc.sourceforge.net/) for D. – arussell84 May 22 '11 at 22:36
  • Additional point: In Embedded systems, (especially small ones with no OS etc.) many of the features (and overheads / penalties) of higher level / more modern languages are at best irrelevant or actually undesirable. – John U Oct 06 '14 at 17:24
4

There are open source projects working on such goals. There is a project for Ada on Atmel MCUs (though I couldn't get it to work). One of my coworkers is programming his 68HC11 MCU with a scaled down version of Ruby he has been working on himself. And there is a company, BlueSpec, that has a new HDL for FPGAs/ASICs that is based on Haskell. But it is not a tool that most would have access to.

Vendors tend to stick with C because there is a large audience for C and it is widely accepted. Likewise, for FPGAs/PLDs, VHDL/Verilog are widely accepted and proven. Instead of having to support many different languages, most prefer to focus on their chips, trying to improve the performance of their C compilers and offer better tools for configuring and managing resources on their chips. I kind of agree with this approach myself. I much prefer that Texas Instruments improves their tools for configuring advanced peripherals on their chips than implementing advanced template metaprogramming on their minimal C++ compiler.

Dr. Watson
  • 794
  • 9
  • 22
3

You are pardoned.

The reason that C, and less C++, (among other language as VHDL) is used for these kinds of devices is that it is easy to translate from the language constructs to the underlying hardware. C is considered lingua franca, understood by many and to port a new language to the device, especially if reading/writing to registers is awkward, is not worth the effort if the language isn't much better at expressing useful constructs.

The examples that you use as newer, shinier languages, D, for example, could be a candidate for a "low-level" language if more programmers use it. D is touted a the modern C++ without all the compromise with C and implemented right from the start. Unfortunately without all the C++ libraries. I think you can call C libs from D.

The question isn't if it is newer, the question is if they are better tools. As far as I can see, it isn't the case.
edit
When I have written embedded code (in C) I have wished for a better macros/templates than C can offer. As it is a compile time construct, it really has nothing to do with the underlying hardware. But much more complicated to implement in a compiler.

  • You could use an external macro-processor, such as m4. It's very powerful. – Leon Heller May 21 '11 at 11:24
  • I've found myself wishing for the ability to overload inline functions based upon whether the compiler can evaluate a parameter as a constant. In a function like "raise x to the power y", it would be worthwhile for an inline version to special-case constant powers of 0 to 3, and call a library function for other powers. It would not be worthwhile to generate inline code to test for those constants, though. Unfortunately, I don't know nay compilers, for any language, that can distinguish overloads based upon constant values. – supercat May 21 '11 at 21:19
  • @supercat: You can do template specialization in C++ to address some of these issues, but when doing so your arguments have to be in the template instantiation "<>" instead of the function arguments "()", which is not ideal. Can't have your cake and eat it too. – TRISAbits Aug 27 '15 at 15:37
2

Take a look at Micro Python http://micropython.org/

Micro Python is a lean and fast implementation of the Python 3 programming language that is optimised to run on a microcontroller. The Micro Python board is a small electronic circuit board that runs the Micro Python language.

It was successfully funded as a kickstarter project in Dec 2013 and they have a reference board.

Peter Gibson
  • 1,800
  • 1
  • 12
  • 14
2

Devices have been designed to use other languages efficiently, such as LISP/Scheme, Forth and Java. I don't believe that any have been designed for those languages you mentioned, perhaps they are not suitable for embedded systems (apart from D which should run efficiently on anything designed for C/C++). They could, presumably, be implemented on any suitable MCU, if someone wished to do so.

Leon Heller
  • 38,774
  • 2
  • 60
  • 96
  • Perhaps Go and Rust ultimately won't be suitable for embedded programming. They are a bit new, I guess, but they claim to be systems programming languages, which is why I listed them as examples. There's also been some news regarding these languages recently in programming circles, so I tried to pick languages that weren't too obscure. – arussell84 May 25 '11 at 07:38
2

There's always netduino, which lets you code in .NET.

jamesotron
  • 121
  • 5
1

There is a proof-of-concept application running under Rust on STM32F4xx ARM microcontrollers. The surprisingly minor changes necessary to port Rust are available in this Rust fork.

Kuba hasn't forgotten Monica
  • 32,734
  • 1
  • 38
  • 103
1

You are looking for a microprocessor. Intel sells them, so do AMD and ARM. You can use any programming langue on these devices.

As for FPGA's: your choice of languages is limited. This is because you need a synthesis tool that will translate your code to a netlist. In addition to VHDL, Verilog and (restricted C), you can go with more modern languages like MyHDL (built on Python) or Bluespec (Haskell-like).

Philippe
  • 1,412
  • 2
  • 13
  • 26
  • 2
    Microcontrollers are merely low-power microprocessors with integrated peripherals. You can't run any old programming language on an FPGA (with soft core, I think we're assuming) or microcontroller because they're too slow, too small, and too low-level for other languages to work well (and, consequently, they don't have compilers written for those languages. Microprocessor vs. Microcontroller isn't the distinction we're interested in here. – Kevin Vermeer May 23 '11 at 03:17
  • I did not say microcontroller, I said microprocessor, which includes microcontrollers, but also your regular Intel Core i7 processor. As for FPGA's with soft cores or hard cores; they come in many different sizes and yes, the can run any language. They run an entire Linux operating system. – Philippe May 24 '11 at 08:23
  • Your citation of Intel reminds me of that old chip : 8052AH-BASIC. http://www.dusko-lolic.from.hr/i8052fract/sbc1.jpg. It had a BASIC interpreter in ROM ! – TEMLIB Oct 07 '14 at 00:52
1

Firstly your examples are small devices that has a limited set of resources, then the old languages that is close to hardware like c and vhdl does the job well.

The new "cool" languages need more resources to run well, so my guess is that what you are seeking will come quite soon since the MCU is getting more powerful over time.

My point is that right most MCU:s is still programmed in C, and the cool guy has just started to play with C++ on those devices.

But if you have a look at the 32-bit ARM based MCU that has a lot more resources than the old 8-bit onces you can find crazy project like eLua, that tries to run the script language lua on a Cortex-M3 based mcu...

So we will get there, but it is going to take a couple of more years. And I don't think that any of those crazy project is ready for production use (yet), but some of them will be since it is faster do develop in languages with s higher abstraction level.

Johan
  • 2,385
  • 2
  • 25
  • 27