PC productivity tools for embedded programmers
As embedded programmers, we all write firmware. Small projects are not so hard to manage. But as projects get bigger and with more than just one programmer involved, it’s time to look around for tools to help keep the team’s productivity high.
To write this blog, I simply dig into my computer and pick out the tools I use often. Here they are, in random order…
Comparing files, well, the worst way to do is to open up two source files and compare them by eyeballing. Comparing files is often needed when working with other people, you want to see what others have changed. Even by yourself, you may want to compare the file you are using today against the file from 5 days ago. Something was working, now it’s not, what’s changed? I personally use Beyond Compare from, http://www.scootersoftware.com. This is not free, but very affordable. It can compare files, folders, you name it. It shows result in a very intuitive manner, can’t live without it. Alternatively, you could use WinMerge, http://winmerge.org. WinMerge is free. Check them out.
Next is version control. At work, the team I’m with uses SVN, http://subversion.tigris.org, and TortoiseSVN, http://tortoisesvn.tigris.org. Both are free. First is the server side software, the heart and soul of the version control system. Second is the client side GUI interface. Nothing too fancy, they just work. Also make sure to backup the SVN repository regularly. Other choices are also available, such as CVS, etc. You can also set TortoiseSVN to use any file comparison tools, in my case, I set it to use Beyond Compare.
Another neat tool we started to use recently is the UniversalIndentGUI, http://universalindent.sourceforge.net. This tool helps in formatting codes, by processing them per the formatting rules given. If you need to publish your code, whether publicly or just to your customers, this tool helps make everything looks consistent as though the codes were written by just one programmer. UniversalIndentGUI doesn’t solve all the consistency issues, like variable and function names. For that, your team need to have a coding style policy to follow in the first place. But for indentation, parenthesis, and other formatting related items, this tool takes the meaning of the word quality to another level.
Moving on to text editor. In all likelihood, your computer has the Notepad program that comes with Microsoft Windows, and you also have an IDE (Integrated Development Environment) installed. Your source code files are probably associated with the IDE. But there will be times when you just want to browse folders, and all you want to do is to quickly inspect a source file, both Notepad and IDE may not be a good solution. Notepad doesn’t highlight syntax, and IDE doesn’t load quickly. In this case, I use another text editor that can highlight syntax, better than Notepad, but also light-weight when compared to an IDE. The program I use is Notepad++, free and can be found at, http://notepad-plus.sourceforge.net. Many other options are also available, such as EditPlus, TextPad, etc.
Talking about editor, another good tool to have is a hex file viewer/editor. I use XVI32, http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm. Not everything you work with is in a text readable form, so something like the XVI32 is a must have.
Another good tool is TreeSize Free, http://www.jam-software.com/freeware/index.shtml. This tool helps you analyze the disk size allocation of files and folders. I typically use this tool to scan code repository before each public code release. It helps me to understand the file organization from the size perspective. I also tend to use it to look out for any unexpected files that may get introduced to the SVN repository unintentionally. This is helpful when the code distribution is large, and you want to keep the installer package size within a reasonable level.
When it comes to documenting APIs, there was a time when we documented our function APIs by writing them out again manually in a separate document, be it a Microsoft Word or Acrobat PDF. This was an insane way of doing things. Mistakes can happen left and right. Synchronization between the actual code and help file was also very hard to keep up with. When an actual function API changed, we would have to remember to update the documentation too. Typographical errors were also very common, which made the document harder to understand for the end readers. The whole process of tracking and editing was also very time consuming. Fortunately, those were the old days. Now we use Doc-O-Matic, http://www.doc-o-matic.com. The tool scans source codes for comments and function headers and use them to outputs documentation help file in various formats automatically. Doc-O-Matic is not free, but a great investment that helps save countless hours of manual work, which makes it a cheaper choice in the long run. A free alternative is Doxygen, http://www.stack.nl/~dimitri/doxygen. If you are not using a help authoring tool, you should start, today.
Lastly for packaging an installer, we use Nullsoft Scriptable Install System (NSIS), http://nsis.sourceforge.net, which is free. For a programmer, learning how to use NSIS should be easy, as you will be writing a script. Many functions and templates are provided. We use the Modern UI template. You will see this template once you have installed NSIS. I’d highly recommend this template and I believe most NSIS users use this template also. To learn the in and out of the Modern UI template, start by reading here: http://nsis.sourceforge.net/Docs/Modern%20UI/Readme.html.
The list above shows just some of the tools we have used within our work environment, some maybe applicable to you, some may not. At some points in the past, we never used to use them either, but we observed where we could improve our productivity and efficiency, and started introducing these tools into our work culture. You could do the same. If the tool doesn’t exist, consider in building one.