Posts

Showing posts from November, 2013

Rust is back in the game

Forget about Haskell, Rust is now the front runner, basically, because I found armboot . It seems like Rust's ability to boot with no (or a minimal) runtime is  fairly new . Since this implementation has no GC, I might indulge in writing one. I've been thinking about it quite a bit lately. For Rust this might require some more thought, however, because it's designed to give garbage collectors a lot more leeway than most languages. I need to get my head around rust's memory model. In the meantime, I think I'll try to write the code for my balancing robot in Rust, without memory management, to see what I learn.

Accelerometer notes

Just some links relating to accelerometers, gyroscopes and balancing robots: I have an STM32F3 discovery board equipped with both L3GD20, and LSM303DLHC. Here's a Chibios based demo which logs their values via the USB port. I've just built and installed it on the board,and it works. Ignore the 'when chibios supports i2c' note: it already talks to the LSM303DLHC. There's also this in the Chibios forums for the L3GD20, which looks a little more structured. I also like this article , which describes building a balance bot based on a Raspberry Pi. The general explanation of balance bots looks good.

Haskell for micro controllers

I wrote a little rant on my employers blog the other day, lamenting the need to develop embedded applications in C or C++. I've written C and C++ professionally, and I'm not planning to do it again, unless it's directly towards the goal of not writing C in some new problem domain in the future. I've done some Arduino programming recently, and it amazes me how painful it is. I looked at loads of options for embedded development, specifically targeting some cheap ARM based boards: the STM32 Discovery line. eLua looked OK, and there's Espurino , but neither are up to the task of handling interrupts, and hence writing drivers. If the drivers don't exist for your platform, or you need to extend them, your back to C. Also, a lot of interpreted systems use precious RAM to store programs, when they should be in ROM, which tends to be more plentiful. I should say that eLua does have an interrupt handling mechanism, but it's not all that fast, and throws interrup