RTOS for dummies

This week, Collin Walls from Mentor Graphics, published an article from guest columnist Meador Inge in his blog. The blog post is called “C is great, but…“, and it goes on to highlight how embedded software programmers should get into languages other than C, the premise is that doing only C will make you a bad programmer. I agree and I have a lot to learn. I’ve played with Python in the past (not with embedded software purposes) and it’s been fun and educative.

On a similar note as Meador’s post, I believe developers should not limit themselves to a single software architecture. so I’ve also been learning the pleasures of RTOS. Coming from the low-end embedded world and having worked with 8 and 16-bit microcontrollers for most of the last 6 years, I’ve become used to forcing myself to do resource constrained software, with bare-schedulers at most. While this has been fun, I think I really need to get going with bigger systems. So I started playing around with MQX by Embedded Access, which is currently being offered by Freescale on several MCU and MPU. I believe MQX is a really nice step towards bigger and more complex RTOS, it has all the basic functionalities an RTOS is supposed to have as well as integrated communications stacks (ethernet, USB) that make suitable for a lot of projects. Freescale is putting a lot of effort into releasing a lot of enablement material.

Even with such a nice option, many of us are less than beginners in the world of RTOS. If you are one such case you should take a look a the Friendly Little Interrupt Tasker (or FLIRT), it’s a very small and simple RTOS ported to Freescale’s S08 architecture. The author, Dave Armour, published an article on Embedded.com about it, the article explains the operation of this great little RTOS in clear and simple language so that even the least knowledgeable of us can understand. A recommended read.

 

How about you? What’s your experience with changing your development paradigms? Leave a comment and let me know your experience with new languages, software architectures, RTOS, etc.

No andaba muerto, andaba de parranda

We have a saying in Mexico: “No andaba andaba “>muerto, andaba de parranda”, which is roughly equivalent to: “he wasn’t dead, he was just out partying”. I haven’t written in some weeks, but there is, I think, a good reason for it: I was out partying…

No, really, I just joined a citizen action group called “Ciudad para Todos” (City for All). We’re a non-profit organization dedicated to promoting a healthier city through increased use alternative transportation like bicycle and public transport as opposed to the car-centric view of modern life. Aaanyway, the first couple of months working with this group have been particularly intense and taking up a lot of my free time. But I’ve decided I have to also commit to my blog as I am also an engineer, and this is what this post is about.

How do you define yourself, as engineer? As an “also engineer”? As an engineer and ‘x’? I have always had trouble with the idea of describing who I am, because I consider myself to be too many things, and I like it like that. I like to see myself as some sort of musician and some sort of writer. I also see myself as a free-thinker, an avid reader, a coffee addict. I will probably even be a family man some day (who knows, right?) When I was in college I had a lot of friends doing the social work thing. I was drawn to it, but considered my studies too important to do it. I was also doing an internship that eventually got me a part-time job that eventually got me my first full-time engineer job. I was career oriented, and still am, but I always felt I sacrificed a bit too much by doing so. On the other side of the equation, I also know people who definitely did more engineering than me during college. After almost 5 years of having finished college I came to the conclusion that I need to start doing stuff to change my contribution to life, because essentially I would implode if I didn’t. I am not JUST and engineer and this is just part of me. Some people have the drive to come home and start programming a random, self-motivated embedded software project. I admire them a lot, cause I don’t. When I come home I have the drive to grab the guitar and pluck at it for a couple of hours, that’s just who I am. I also am worried about the environment and how irrationally my city is growing, so I went and joined a group that is trying to change things.

I believe the world is made up of different types of people. I know that, because of my engineering training, I can satisfactorily do engineering work and be good at it. Yet, I don’t see myself as just that person. Some people are more of the just-engineer type, I know my brother spends more hours per day programming than me, some people are better suited for that. How about you? What type of engineer are you?

Is pair programming for the embedded folk?

I just read an article in Obbie Fernandez’s blog about pair programming and how it is not for every company (10 Reasons Pair Programming Is Not For the Masses). I don’t usually read his blog cause I’m not a web developer, but my brother (who does do web development) tweets the articles he likes and I read them…(except when they talk about high level ruby code that my lowly embedded-C brain can’t or doesn’t want to understand).

Aaanyway, pair programming has always been something that intrigues me. The article basically states why it is difficult for most development teams to adopt the pair programming method. It just requires too much commitment and so much non-traditional focus that most shops are just not ready to do it. Even so, I bet there are embedded software companies out there willing to try the model out and that actually have the resources and commitment to make it happen. This leads me to (dreamily) wonder, is embedded software development adequate for pair programming? Most of my reasoning points towards yes, embedded software is, for all purposes, software, so the model should work even if it is not the ideal world of web (for more on why pair programming is so good for the web software folk, read this article by Rod Hilton). I felt particularly devastated by “the no-asshole rule” cause, let’s face it, the embedded development community is full of these types (all of them, the prima donnas, the smelly ones, the antisocial ones).

I also see a big problem with the overall maturity of the embedded software industry. From my very personal point of view, there are currently two types embedded software shops:

• The stick-to-the-process, extremely formal type of place: these are the places where they are making really “important” software, for example: automotive, aero-space or networking (some) industries would be here. These types of shops have a rigid process and way of doing things all focused on clearing all sorts verification, validation and tests. Would they be willing to commit to the big change that would be jumping to a pair programming model?
• The rest: sorry for the ambiguity but most other shops (again, from my perspective) are just completely random, with all sorts of people following all sorts of processes and/or not following any at all. There are of course varying degrees of truth to this, but the fact is that as an industry, we are way behind in jumping to an actual “software engineering” culture, most people come from an electronics engineering background, which doesn’t help either, and most of the people don’t really know or care about the benefits of formal processes (and I’m not talking about the IEEE, RUP, ISO type thing, but just a set of light and easy-to-follow steps like requirements-architecture-design-code-test). In this (admittedly) gruesome and negative panorama, does it even make sense to throw in a paradigm changing model? Not sure.

What do you think? Are embedded developers mature enough to pull pair programming off?

Real masochists program in 8-bit assembly

So I’ve been programming some mathematical functions in assembly for the Freescale HCS08 core for the last couple of weeks. It’s been a really nice experience because I had not programmed in assembly for a while. Before you start judging me on not using C, consider that mathematical functions are one of the few places where assembly does makes sense, particularly when performance is a priority (like in motor control applications).

Apart from the horribly fun process of remembering the instruction set, the great thing about this project is that I’ve been able to go back to the roots of the CPU. I got to remember the cost of declaring a variable in a function and of passing too many arguments instead of pointers or structures. I also remembered how nice it is to have a CPU with several registers instead of only having three. But by far, the most valueable thing I got to remember was just how much an 8-bit CPU has to do to handle 16 bit variables. It’s almost ridiculous. A simple shift operation will take some 18 CPU cycles if done in variables stored in the stack. Depending on the input values, a 16 bit division could take from 100 to 900 CPU cycles depending on the algorithm being used.

All in all, a valuable (and gray-hair-inducing) experience. But I would definitely would recommend it to anyone who has gotten too comfortable with the high level languages.

Side note: I also love compilers a lot more now.

Are embedded systems for the “do it yourself” person?

Most of my friends know I play the guitar (and those of you who don’t are bad bad friends). I’ve always loved tweaking around my guitars, desoldering and soldering them back, playing with the internal electronics and what not. I recently started thinking about “going all the way” and building a guitar out of scratch. It’s a pretty big project considering I don’t have wood working tools (or experience), I’ll eventually do it. Couple of weeks ago a friend remembered he had an article on building an acoustic guitar, so he sent it to me. Turns out it was from a November, 1964 issue of Popular Mechanics. It got me thinking, will there ever be do-it-yourself articles in magazines about building embedded systems? I know there are some electronics kits out there, but there is no programming involved. I mean some more “hardcore” embedded development with compilers, watchdogs and maybe even a small do-it-yourself oscilloscope. That would be fun, but I’m not sure if it makes sense. Embedded systems are custom hardware based, will there ever be really generic microcontroller modules that you can plug into whatever external hardware in a generic mechanical format? Or will embedded systems be always constrained to having the knowledge and budget to build your own hardware?

College students…

All through college I never thought of sending an email to technical support of any semiconductor company, it was some sort of “student modesty” that I thought I should have, so all my stay in college the only contact I had with semiconductor companies was to get samples, and then I battled for hours with their demo boards. Today someone reminded me that I was one of the go-to guys to get the HC908QT4 demo boards we had in our school lab to work, good times.

Nowadays I’m a technical support engineer and we constantly get requests from students asking for all sorts of support, although I’ve read some really interesting questions from college students, most questions are of the please-spend-an-extra-hour-figuring-this-out-instead-of-bothering-me sort. Maybe it’s my pride talking, but it really gets me angry when students treat technical support like their own personal code monkeys. College is the time when they are learning to do that (learn their technical skills, becoming a code monkey or a manager is a combination of luck, decision, hard work, etc.)

I once had a student ask me to write their homework code for them (without even a small attempt to hide the fact that it was a school assignment). We have a politic to not develop code for students, it’s not that we don’t want to, it’s that we just don’t have enough personnel to write every code snippet request we get (although I do enjoy telling them we won’t be doing their homework), but we do send code snippets that have already been written. This particular request was for something that was very similar to something I already had available  (let’s say he needed a USB HID mouse and I only had an HID keyboard example). I sent it to him, told him which files he needed to modify and sent him on his way. A week later I received a “very dissatisfied” survey from him, saying he didn’t like that fact that I didn’t send exactly what he was requesting. Per our policy I had to call him or email him to request feedback. His phone number was bogus and he never answered my email. I wonder what grade he got for that project.

Same product, different wrapping?

A couple of days ago I decided to change the theme for my blog…I tried a few templates and then I decided I should make a new template…being the graphically challenged person that I am I opened up my trusty MS paint, and got to work. The result, was, for my standards: amazing.

I kept thinking about this cycle of redefinition everyone lives. We are essentially the same, but with more experience, different body (some of us tend to get heavier, some of us try desperately to get thinner). The technology industry also works in a similar fashion. I thought of semiconductor product lines, and they do the same thing. New microprocessors are released with just a little tweak different from the previous one, then another tweak and then another, until suddenly a new core is released. Then that core gets new tweaks, and eventually a new core ends up having the same features as an old core had, but with more power, optimized peripherals (more experience), new packaging technology (different body), but it essentially does the same. It’s an LCD controller, a mobile processor, an RF IC. It just does the same thing but it’s better at it, pretty much like a person throughout his/her lifetime. Until we get obsolete and we stop adding new features and wait for the new cooler core to be released…sorry, for our children to be born…mmm…younger coworker to take our place…mmm…the possibilities seem endless…aaanyway, just a thought.