I often get emails from students asking me how to get started in a career in embedded software. I have to assume that they think that this is a path to a well paid job and a corresponding glamorous lifestyle. I would hate to disillusion someone who is just setting out on life. I guess that I had great expectations too.
I am never able to give detailed advice on what to do and just comment that embedded software engineers actually come in several flavors. At one extreme, they are engineers with a deep knowledge of hardware and only do a bit of software when necessary; such skills are ideal for developing drivers and other low level code. At the other extreme, there are programmers who have no idea about embedded systems, but are focused on the application domain; there skill set is not very different from a software engineer working on applications for Windows or Linux. And, in the middle, are guys who understand real time behavior and real time operating systems.
The nearest to advice that I can give, apart from obviously recommending my book, is to explain how I got into embedded …
It started when I went to university. That was [wait for it] way back in 1975. I had no real idea what I might want to do for a job/career, but I had always been interested in science and technology, so I went to study materials Science, as this seemed quite broad. The course was OK, but I made some friends who were studying computing and this got me interested. I had had no exposure to computers before; this was new and fascinating.
So, I had a new hobby. I started our writing FORTRAN and send off my programs on punched cards, getting a printout hours later. I dabbled in other languages and got to use interactive terminals [not screens – noisy teletypes]. Then I discovered that I could gain access to minicomputers – DEC PDP-11s and a PDP-8. I really liked having exclusive use of a computer and getting a chance to really understand what was going on, instead of having a monster mainframe OS doing it all.
So, a typical day for me was lectures and labs all day, spend the evening with my girlfriend, then play with the computers into the early hours, snatch a bit of sleep and then do it all again. I learnt a lot. Having sole control of a computer with either no OS or, at most, a lightweight monitor program, was exciting. I started using more low level languages – BCPL [a precursor of C] was a favorite – and assembly language, of course. I even programmed the PDP-8 in binary from the switches on the front panel. I still have a lingering feeling that a real computer should have a line of lights and switches on the front. Looking at my iPad on the desk next to me makes me think that we have come a long way.
When it was time to look for a job, I had a choice: follow my degree and become some kind of scientist or find somebody to pay me for doing my hobby. Needless to say, the latter won. And I had no shortage of opportunities. I did not know enough about the software business to make a rational choice, but broadly I had to select between the “commercial” world [COBOL and mainframes – all seemed quite glamorous] or “real time”, which looked more fun. I am glad I took the route that I did.
So my first job was programming mini-computers controlling materials testing machines [so there was even a vague nod to my degree]. In due course, I started working with microprocessor based systems – embedded systems as we would call them now. From then on, fuelled by my historic interest in electronics [another hobby when I was a teenager], through a couple of job changes, I gradually became more specialized in this area.
In some ways, things have come a full circle. Few embedded systems nowadays, except smaller 4/8/16 bit devices, have no operating system. I am quite comfortable with a lean RTOS, like Nucleus, but I am much more wary of the trend towards more complex options, like Linux/Android. As I mentioned in another posting recently, it can be hard to figure out what is actually happening with a heavier weight OS. I also wonder where my career might go next.