I do not know how you feel, but I have never had as much fun doing MCU development as I have lately. I can't believe I have been doing this for almost 25 years, and I thought I was having fun back when I started.
For those too young to remember, we used to have to burn software in EPROMs on an EPROM burner. If you got it wrong, you erased the EPROM under UV light for 10 or 20 minutes and tried again. Please note that I am not quite old enough to remember actually using PROMs, but not by much.
To debug software, either you were on your own, or you had to buy an expensive emulator. These consisted of one or two full-length cards that plugged into your PC, along with a pod that plugged into your target PCB's processor socket. Between the two were several wide, stiff ribbon cables. Emulator costs started at around $5,000 for an 8051 target.
Some simpler models were just EPROM emulators. You could set break points and sometimes single step through your code, but you could not look at registers. You could use those with older processors that did not have internal program memory.
I thought the emulators were great, but they were expensive, and you did not always have access to one. If you did not have an emulator, you had to be really smart or really patient to debug your software. That's where I learned that a generous helping of on-chip debug routines was valuable. (I blogged about this earlier.) Nowadays, you can find a bug, fix it, and try the fix sometimes in less than a minute. And still we complain.
The cost of entry into the world of microcontroller projects also has gone down considerably. Most evaluation kits I have used in the last five years were between $10 and $50. That includes a variety of eight- to 32-bit processors and FPGAs. Quality development tools are free under open-source or GPL. Of course, sometimes you can get your product working faster with the commercial tools that are available, but at least you have options, which is great for students and self-taught individuals.
Though I would not go back to those early days for anything (at least as far as having to program in assembler and burn/erase EPROMs is concerned), there was a real value in the experience that I and others gained. Because the burn-test-fix-reburn cycle was so long, we had to think much harder before committing code to EPROM. And sometimes, in that hard-thinking process, we found more bugs than we were seeking.
Nowadays, the abundance of resources of all kinds -- from on-chip debug to so many free, quality tools like GCC and GDB and their extended family -- certainly makes like easier. I am not so sure overall code quality (as in absence of bugs) has improved significantly, though. Most applications are considerably more complex today, with requirements that were unimaginable in the old days, like Internet connectivity, location services through GPS, the wide variety of wireless protocols and interfaces, touch-controlled color displays, multimedia, and the like. The opportunity for bugs has increased exponentially, as has the average project's code size. Making sure that your project's code is good is a complex task by itself -- in many cases harder than writing the code in the first place.
Along those lines, please look at Rich Quinnell’s blog about software testing, and imagine his little quiz scaled to the size of a project like a smartphone operating system. Try to imagine how that software is tested.
What do you like most about modern software development? Comments are invited.
Related posts:
Tweet This
