Swirling down the rabbit hole
I’ve grown extremely interested in comparing open source tools and libraries with their commercial counterparts. Are they as efficient, robust, safe and secure? Can developers really save money using open source? I know many companies that don’t even ask the question and just jump straight to whatever happens to be “free”. I thought an interesting place to start would be to compare IoT solutions such as Amazon FreeRTOS and Express Logic’s X-Ware Platform. I’ve recently written several blogs around Amazon FreeRTOS where I’ve pointed out what I considered to be important issues. But then I heard that there had been updates! The code size was dramatically decreased, and the connection speeds were much faster I heard. In order to give everyone a fair chance, I had to update my Amazon FreeRTOS code base to the latest and greatest and that’s when I started swirling down the rabbit hole.
To be fair, I can’t blame Amazon FreeRTOS or the way that they distribute their software. Instead, I have to blame myself for my setup and several mistakes that I made along the way. First, I decided that I preferred to use Atollic TrueStudio over the supported AC6 environment. Even though they are both GCC based, importing the project into TrueStudio still required several steps such as setting the target, setting up paths and several other activities. I had a working environment, so I thought I was all set. When I imported the latest code though, I lost all my environmental settings and the project complained about missing files, paths, etc. No biggy. I’ll refer to my notes on what I did to set this up the first time …. Except that in this instance, I neglected to take notes because
I was in a hurry that day
I figured that if I backed up my project I could always go back to the working copy
With my project royally screwed up, I decided that it would be a good idea to revert what I had and get back to square one. Except when I reverted back to the original project, I discovered that my back-up was not quite as complete as I thought, and I was missing the same settings information! I had used the export tool to back-up my project, believing that it backed up the project and the files, only to find that it had the project but no files. Worse, I always setup a repository first, commit my base, verify and then move on from there. In this instance, since this was just “play” code for articles, I decided to just use the archive files as backups.
At this point, I knew I had to just bite the bullet and start from scratch. It happens but this hasn’t happened to me in years. I’m usually so disciplined and precise but in order to cut a few minutes off my time, I cut a corner. Now several weeks later, those few minutes have ballooned into a several hour debug / setup sessions that I had not accounted for. The trick at this point, was to regroup, get disciplined again and take everything one step at a time with my notebook open and diligent notes being taken and moving one step at a time.
In summary, there are several key lessons that I hope you’ll take away from this:
When using a development environment not supported by your open source code, carefully document all the steps you took to get a working code base in that environment.
Even with test code, take the time to make sure you’ve properly backed up your project. This means opening it in a different workspace and importing it and ensuring it can find all the files and compile successfully.
Test and validate a good update procedure when pulling from open source software. The process I was using for this test code was loose at best, probably because I had never planned to update this code.
Plan for the unexpected. Even if you don’t expect to need that code again, act like you will.
There is always time to do things right.
I hope that the few hours of pain I went through to get my code base back to square one will help you to avoid running into the same issue. No matter how much experience one might have, cutting corners on discipline always comes back to bite you. With everything back in order, my next post will start to dive into my open source and commercial comparisons.
How about you? Did you ever find yourself swirling down a similar rabbit hole? What did you learn? Tell us about it in the comments section below.
Jacob Beningo is an embedded software consultant, advisor and educator who currently works with clients in more than a dozen countries to dramatically transform their software, systems and processes. Feel free to contact him at email@example.com, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.