Our brain is wired for image processing and all things visual just reach deep in our mind faster! If there is one moment when I just cannot seem to ever get enough of a “view”, that’s when I am debugging code. The Watch windows, the local variables windows, the stack window are not what I am talking about. The Logic Analyzer window (in MPLAB SIM) and the DCMI (with simulator and emulators) are barely starting to scratch the surface, when I need to debug some complex code, I am willing to use literally everything at my disposal, beyond MPLAB, using hardware (scopes and logic analyzers) but also additional software.
Now, on one extreme, since MPLAB is a pretty flexible tool built in a modern modular fashion, it would be theoretically possible to design ad hoc extensions, or “plug-ins”, to obtain additional data analysis options. But a lot can be done with much less effort working simply with exported ASCII files right out of the watch windows.
In fact if you point the mouse on the Watch window, and in particular on a variable whose contents could use some visual help, the right-click (context menu) will offer the option to save the contents of the variable (array, structure, or selected group of variables) in a simple (ASCII) text file.
The advantage of the text file approach is that any number of tools will be able to pick the data up and process it further. For example, using a spreadsheet you can import the text file (select space separated fields) and produce any number of graphs, pie charts, but also create simple formulas to extrapolate/interpolate the data as needed. You can use any word processor, or simply Notepad, to search for patterns in your data and, of course, you can write small programs/scripts to transform and filter the data.
While writing the book, I found myself writing several graphic examples that required some pretty complex timings and hardware interactions, but I was also confronted with the need to document the project (output) essentially an ethereal image on the screen of my TV. How to obtain an image of what was being formed in the “video memory map” when the video (engine) module itself was being debugged?
So I decided to write a small external application using a … freely available IDE: Microsoft Visual Studio Visual C# Express Edition!
Of all possible options out there you will wonder why did I, an admitted Linux curious/fan, a Modula 2, Occam, Java programmer by education, an old Borland enthusiast… (the list could continue), why would I basically sell my soul?
Well, they say that virtue is not living without temptations, but being tempted and resisting it… I just wanted to “look at the devil in the eyes”, I did it and I will share with you my findings…
First of all, if you have done Visual Basic development in the past (please admit it) you might just choose to continue to do so, it has never been easier actually. Alternatively, Visual C++ is a solid option in the Visual Studio Express (free) suite. But Visual C#, Microsoft supposed answer to the Java threat, had been on my list of new languages to check out for a while.
So I wrote a small application (PIC24Viewer) that would open one of MPLAB generated text files, containing the video memory map of the PIC24, and would reproduce the image on my PC screen, copy it to the clipboard and make it easy to paste into the book’s manuscript.
Developing in a visual environment, I started as expected with the visual interface (form):
Then I flashed out the few functions required to give life to the application buttons and the other graphical elements.
If you have spent any time with an object oriented programming language (Visual Basic, Visual C++, Borland C++ builder…) there are absolutely no surprises here… and especially if you have any past experience coding in C/C++ for Windows, this should all look very simple if not trivial.
We don’t have the time and space here to analyze in detail the code, but here is what the output looked like. On the other hand you have probably seen the fractal pictures in the book already…
So what did I learn from this excursion in Visual C# land? The pros first:
- It was easy, I will admit it. The online help in particular was really extensive.
- Few lines of code, a lot of windows functionality…
- The built in functionality to distribute and revision the code was really impressive
As per the cons:
- My computer slowed down to a crawl … (in the best MS tradition I guess)
- The IDE created an incredibly complex directory tree and filled it with files of all sizes and names. I got lost several times in it while trying to find “my” code.
- The C# language has some strange quirks of its own:
- See the definition of strings containing slashes for example @”C:\C30\”,
- The declaration and instantiation of arrays and objects that requires an annoying repetition as in: “System.IO.StreamReader objFile = new System.IO.StreamReader(sFilename)“
- The unusually verbose expressions that replace some simple C options as in: Int16.Parse(sLine, System.Globalization.NumberStyles.AllowHexSpecifier)
used to convert an ASCII string in an integer ( see atoi()…)
Overall, I would say the ease of use has clearly impressed me although I don’t think the C# language had that big influence over this part of the experience. It was rather the sum of a number of factors in the design of the user interface, the completeness of the IDE and its documentation. The language itself, seems in my very personal opinion, to be the fruit of a constant compromise between compatibility with C and some of the features expected/desirable in a modern interpreted language. In fact it seems lacking in vision (funny to say for a visual tool) and purity, two qualities where Java shines in my eyes.
Will I use Visual C# again in the future? You bet, I’ll give it a few more tries to help me tame the Windows beast, help visualize my data and possibly catch a few bugs too. After all it comes at a price that is hard to beat…
