Many of our modern conveniences are dependent on some internal digital processing. Smart phones, microwave ovens, garage doors, remote control quad copters, and even Lego Mindstorms all have some “embedded” processing that controls, guides, and ultimately provides service or entertainment. These systems are complex and require planning, development, and testing. An embedded project may start with simply the microcontroller (the heart and brains of embedded development) and few test programs – no user interface!
My Embedded Learning
I’m experimenting and developing a small embedded project for a hobby of mine. I do both development and testing. Of course this leads to some mischief in the systems I create but I can usually determine how and what caused it. I also learn a lot about myself by performing both roles. While I enjoy my projects from a hobby aspect, I find embedded testing more challenging than client-server, it broadens my technical base, and sharpens my testing skills.
The Motivating Question
Recently, I completed a successful integration of a microcontroller, GPS and transceiver.
The purpose of this system was to transmit GPS coordinates from a remote station to a base station. I showed a short video of this system “working” to a colleague (the video shows the system with lights blinking – that means its working doesn’t it?). After viewing the video, he asked how I tested it.
Mildly embarrassed, I wasn’t sure how to reply. While it was a great question, I couldn’t describe my test approach, or even a test strategy. My only reply was a short, incomplete description of my development that didn’t begin to answer his question.
An Approach of Necessity
When I started in this hobby, it required a lot of time. I was soon reminded I have things to do around the house, and two boys whom I might provide a fatherly experience. When I was able to work, I was occasionally interrupted. It was frustrating and often I had to stop at an inconvenient place. And worse, many times I had to recreate some context of what I was doing.
Over time, I learned to review what I wanted to do, and how to break it down into small bits of work. By doing that, I found
- I wrote smaller – and testable – chunks of code
- I experimented first and designed second
- I enjoyed the process and the product more
- I had a better balance of my time
With this process, testing was more integrated and natural in my personal development process. I was evaluating smaller changes and verifying operations frequently.
How Do I Know What’s Going On? There’s No GUI!
I also discovered embedded development is a lot less transparent than client-server. There is no screen to review the result of a process, and no log file to review when errors occur. Indeed, all I had was the microcontroller and a method to upload a program for it.
I knew I needed to see things happen or I would be guessing and wasting time. Guessing, it seemed to me, would lead to low confidence in a final product. So, I bought a small Liquid Crystal Display (LCD) display to provide transparency. A few lines of code later, I was able to display information on the LCD screen.
From Small Chunks to Integrated Function Blocks
I saw my project development accelerate since I could easily confirm the operation of new or changed code by displaying relevant information on the LCD screen. Small experiments became small, tested chunks of code. With many small chunks, I was able to confidently integrate them into functional blocks
There’s Something Familiar Here
If you are working on a project that has limited resources, I encourage you to
- Think about the work and how to break it down
- Experiment often
- Compile and test frequently
- Seek transparency
- Share your discoveries
- Build on small successes
These practices have helped me manage my time, build cool stuff, and improve multiple project skills.