Barcamp Tampa Bay '09 - Future of Microcontroller Programming

As I understand it, this is an investigation into developing a cross-compiler using Python along with a language specifically designed for the purpose. I think that this could be a valuable exerise to the participants as an exercise, but am admittedly skeptical as to the practical implications.

The project seems based on the premises that:

  • the stack is evil (their word, not mine)
  • a closed source compiler is bad
  • minimal code space (32k of flash) somehow makes the goal easier
First, I think that the condemnation of the stack is too broad. For many applications that may be a consideration, but embedded projects are often designed to solve very specific problems of limited scope. There is nothing intrinsic to embedded development that should lead one to believe that the stack is evil - perhaps difficult to work with, but not inheritly evil.

Considerations of the compiler ultimately have to come down to code efficiency. Programming workflow is definitely a consideration, but if you are trying to fit your code into 2K of Flash and function properly with 256 bytes of RAM you really want an efficient compiler. Realistically, the manufacturer of the microcontroller is in the best position to produce a compiler that makes best use of its particular hardware characteristics (of course, not necessarily the case). For instance, a TI MSP430 has 16 index registers whereas the Freescale S08 family has a single index register and an accumulator so their respective compilers will use different algorithms for optimization.

I was struck by the statement that the limited codespace of the target microcontroller (An Atmel ATmega328 on the Arduino development board) is an advantage. The expressed thought was something along the lines that only having 32K to worry about meant that the compiler output should be relatively easy. I suppose the thought is that if I only have to worry about 32K then it would be easier than, say, an application that might compile into several megs. First, 32K is pretty big for an embedded chip. Second, I'm thinking that life gets harder, not easier, as the available space shrinks. Who typically complains about having too much room? I would think that the requirement of squeezing the code into tighter spaces would tend to be more of a curse than a boon.

Anyway, I'm not experienced with Python, except for the high praise it receives from xkcd, so I can't add anything meaningful to the decision to use it as the basis of the compiler. I think the effort will provide a lot of meaningful experience to those that do it. And it would be super cool if I am wrong and they produce a kick-ass solution that makes creating embedded applications that much easier. Still, I think that I will continue to try to better understand C and Assembly for my embedded programming efforts.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
BlogCFC was created by Raymond Camden. This blog is running version Contact Blog Owner