13
\$\begingroup\$

Functional languages like Haskell, LISP, or Scheme allow a programmer to work quickly using the functional programming paradigm. They do have their inefficiencies, but my application places greater emphasis on programmer efficiency than efficiency of the program itself.

I'd like to use functional programming on a microcontroller to do machine control, etc.

What limitations are there, such as minimum system resources?
What example implementations of these languages are available?

\$\endgroup\$
12
  • 1
    \$\begingroup\$ If your question is "Isn't it worth it to program any machine with the most powerful programming language you can get your hands on," the C++ and Java questions are recommended reading (about OOP rather than functional programming). \$\endgroup\$
    – Kevin Vermeer
    Jan 27, 2011 at 17:45
  • 1
    \$\begingroup\$ Your first paragraph comes across as argumentative, which has netted you a few close votes. Consider rewording to something more passive ("I'm interested in using functional programming for machine control, what examples are there of Haskell/LISP/Scheme implementations for embedded systems") or removing it entirely. \$\endgroup\$
    – Kevin Vermeer
    Jan 27, 2011 at 17:46
  • 2
    \$\begingroup\$ I don't buy your "inefficient" statement. You seem to exhibit extreme bias towards the hobbyist/prototype side--low volume (aka: 1). C/C++/asm results in smaller, faster code that is amplified thousands or millions of times when you can use processors with just enough speed and space. Embedded is embedded. You are not programming on a general-purpose OS. \$\endgroup\$
    – Nick T
    Jan 27, 2011 at 17:51
  • 4
    \$\begingroup\$ @Nick T - "C/C++/asm results in smaller, faster code that is amplified thousands or millions of times when you can use processors with just enough speed and space" - what about maintenance? A functional language can frequently do in a single line what a C-program requires 10s to do, meaning less room for bugs. In addition, they can be complied (ie Haskell), and made to run on the target, which is faster than interpreters. I wanted to explore this topic a bit because a compiled-Haskell might be just as fast, but quicker to develop than say a C app. Wanted to question the status quo a bit. \$\endgroup\$
    – J. Polfer
    Jan 27, 2011 at 21:28
  • 1
    \$\begingroup\$ @Sheepsimulator Unfortunately, comments like your last one make questions like this argumentative. \$\endgroup\$
    – Kellenjb
    Jan 27, 2011 at 21:39

8 Answers 8

Reset to default
12
\$\begingroup\$

ARMPIT SCHEME is an interpreter for the Scheme language (lexically-scoped dialect of Lisp) that runs on RISC microcontrollers with ARM core. It is based on the description in the Revised Report on the Algorithmic Language Scheme (r5rs), with some extensions (for I/O) and some omissions (to fit within MCU memory). It is further designed to support multitasking and multiprocessing. Armpit Scheme is expected to be well suited to educational settings, including student projects in courses on control and instrumentation, or capstone design courses where microcontrollers are needed. It is meant to enrich the spectrum of interpreted languages available for MCUs (eg. BASIC and FORTH) and can be an alternative to MCU-based bytecode interpreters (eg. for Scheme or Java) and to compiled languages (eg. C).

http://armpit.sourceforge.net/

You say:

Using C, C++, assembly, etc. is quite inefficient compared to languages like Haskell, LISP, or Scheme

Using high level languages is a more efficient use of programmer time, but can often be a less efficient use of computing resources. For embedded systems manufactured in volume, cost and performance are often higher priority than development effort.

\$\endgroup\$
8
\$\begingroup\$

You also can program AVR controllers with Haskell using Atom/Copilot, for example http://leepike.wordpress.com/2010/12/18/haskell-and-hardware-for-the-holidays/

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Haskell really is good stuff <3 \$\endgroup\$
    – Trygve Laugstøl
    Dec 11, 2012 at 16:43
5
\$\begingroup\$

C, C++, and Assembly are all very close to machine language. By using a higher level language, you are adding additional overhead in exchange for more rapid/easier/etc development.

\$\endgroup\$
4
  • 3
    \$\begingroup\$ -1: I don't really agree with this answer. Although your right about Assembly being close to machine language, C and C++ are very different high level languages. \$\endgroup\$
    – BG100
    Jan 27, 2011 at 17:37
  • 1
    \$\begingroup\$ @BG100, I'd actually draw the "high level/low level" line somewhere within C rather then just call it a high-level language. When performing arithmetic, pointer (string) operations, and other common basic tasks, the instructions that compilers generally produce have the CPU directly manipulating the data without any layers of abstraction. \$\endgroup\$
    – Nick T
    Jan 27, 2011 at 21:58
  • \$\begingroup\$ @Nick T: I see your point, but consider this: if you write an interrupt routine that generally needs to execute as quickly as possible, in C you would have no idea how long it would take to run, but in assembler you would can just count the instructions. I think low level is knowing EXACTLY was is going on in your program, you don't know this for sure if your using C. \$\endgroup\$
    – BG100
    Jan 27, 2011 at 22:33
  • \$\begingroup\$ @BG100: the same assembler instruction can take different numbers of cycles to execute based on operands and their addressing modes. Though in C, once you compile you get static code that does not (can not) change. True, this is a somewhat tenuous argument, but if we're going to argue the minutiae to try to draw a big red line... \$\endgroup\$
    – Nick T
    Jan 28, 2011 at 3:29
3
\$\begingroup\$

I've been programming an ARM board in Python recently, and I think it's great. It's no good for real-time control, but I'm doing more web-related stuff, which is far more pleasant in a high-level language than in C.

\$\endgroup\$
3
\$\begingroup\$

The majority of microcontrollers are still 8 and 16-bit devices (although this is slowly changing). The two instances of higher-level languages (Scheme and Python) mentioned in other answers so far are both running on 32-bit ARM cores. The smaller 8 and 16-bit devices (which may cost only a couple of dollars) don't have enough RAM to support the languages being mentioned -- typically they only have a few KB of RAM.

Also, these higher-level languages are not designed for writing low latency interrupt handlers and the like. It's not unusual for a microcontroller interrupt handler to get called hundreds or thousands of times per second, and each time required to perform its task in tens of microseconds or less.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Scheme was developed in the mid-late '70's and very early '80's. By no means does Scheme require a 32-bit processor or megabytes of memory. Scheme was available for AT-class PCs in the mid-80's. Recent implementations might be optimized for more resource-rich environments, but there's clear examples of Schemes that run on what are nowadays "miniscule" computing platforms. \$\endgroup\$
    – The Photon
    Dec 11, 2012 at 20:10
  • \$\begingroup\$ @ThePhoton I stand corrected. Although I was aware of the BIT project, which targets processors with tens of KB of memory (more than what is available on most small microcontrollers), I just discovered PICBIT, designed by a couple of students at the Université de Montréal and Université Laval, which allows real Scheme programs to run on PIC processors with as little as 2K of RAM. Pretty amazing. \$\endgroup\$
    – tcrosley
    Dec 12, 2012 at 12:28
3
\$\begingroup\$

It's possible to do some functional programming with the Lua language. Really, Lua is a mutli-paradigm language; Wikipedia claims that it's a 'scripting, imperative, functional, object-oriented, prototype-based' language. The language doesn't enforce a single paradigm, but instead is flexible enough to allow the programmer to implement whatever paradigm is applicable to the situation. It's been influenced by Scheme.

Lua's features include first-class functions, lexical scoping and closures and coroutines, which are useful for functional programming. You can see how these features are used on the Lua users wiki, which has a page dedicated to functional programming. I also came across this Google Code project, but I haven't used it (it does claim to be influenced by Haskell, another language which you mentioned).

eLua is an implementation which is available configured for a number of development boards for the ARM7TMDI, Cortex-M3, ARM966E-S and AVR32 architectures, and is open-source so you can configure it for your own platform. Lua is implemented in ANSI C and the entire source weighs in at under 200kB, so you should be able to build it for most platforms with a C compiler. At least 128k of Flash and 32k of RAM is recommended. I'm working on a PIC32 port for it (still in the 'Get the PIC32 board' stage, though) at the moment.

The great thing about Lua is that it was designed as a glue language, so it's very easy to write C extensions for the stuff that needs to be fast (like interrupts etc), and use the dynamic, interpreted features of the language to do rapid development in the program logic.

Lua isn't a purely functional language, but you can do a lot of functional programming in it, it's fast and small (compared to other scripting languages), and you don't need to reflash your device to try out a program. There's even an interactive interpreter!

\$\endgroup\$
1
\$\begingroup\$

"Are there ways to do functional programming with a functional language on an MCU to solve difficult problems?"

Yes, there are ways. But the downside is you need a 32-bit processor, MMU, 128MB RAM, SSD, an RTOS, and $$$.

Microcontrollers are different than microprocessors. The microcontroller may only be a 8-bit CPU, 1K RAM, 8K ROM, but it has a built in UART, PWM, ADC, etc. And it only costs $1.30.

So you could have all that high-level languages running, but it costs a lot more to make.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ I think you need to revisit your definition of microcontroller. Many microcontrollers now have 128kB or more of Flash, and 64kB or more of RAM, plenty of space to run an interpreter for some smallish languages. It looks like you're giving specs for an embedded Linux device; I think the OP was asking for a dedicated port. \$\endgroup\$
    – Kevin Vermeer
    Jan 28, 2011 at 15:52
  • 1
    \$\begingroup\$ If you are paying $1.30 for a 8-bit MCU, then there are several 32-bit MCUs that are cheaper. Also, take in account that most 8-bit MCUs on the market are horribly code-ineffective architectures, with designs inherited from the early 80s. \$\endgroup\$
    – Lundin
    Dec 12, 2012 at 7:57
0
\$\begingroup\$

This book provides some way to do programming with a light feel of FP. http://www.state-machine.com/psicc2/

But real FP require to have an ability to construct functions in runtime and pass them across your program. Here we have a problem: how can we represent this constructed function? and how we can effectively execute this function? On a large system, we can use dynamic compilation which generates real machine code on a first function application. On MCU we have only RAM to implement very primitive compilers like Forth language core.

The only way you can use FP or OOP if you prefer it is the metaprogramming: write complex functional/OOP programs that generate programs for MCU (C source code for example, or LLVM IL). In this variant, you are not limited by paradigm or programming methods complexity.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.