Archive for October, 2006

Egward G. Niles has a vivid short story on his blog.  I don’t know how factual it is, but I can see it ringing true in certain circles.  Now that the high tech economy has picked up some since the bubble burst, such scenarios might be less prevalent, but what do I know?  You’d expect something like that to show up at F***edCompany.

If you like low-level stuff, this is for you. A micro-controller with a built-in voltage comparator can be used for a cool little hack: use the comparator as a RS-232 serial receiver without the need for a RS-232 to TTL adaptor.

For those of you unfamiliar with what I just said, here’s a little primer. Most microprocessors with I/O pins support TTL: 0V is negative, 5V is positive. RS-232 (aka your PC’s serial port) specified that -15V to -3V is positive (a mark) and +3V to +15V is negative (a space). Incidentaly, most PC implementations will actually not meet that spec as a mark is only about -1V.

How does the little hack work?  Connect the RS-232 RX pin to the Voltage Comparator Pin on your microprocessor.  Set the reference voltage to be about 3V.  Depending on your particular, anything above 3V will be considered a 1 and bellow 3V will be a 0.  Hook-Up an Interrupt Service Routine to read the comparator output and bit-bang read the bytes.  Note that only fairly slow baud rates is supported with bit banging; 19,200 bauds is the upper limit with this technique.

Why would you ever want to do this?  Small physical package, with no spare circuit board space is one possible reason…

Another interesting article by James Grenning: using tests to explore an API. This is such a great idea, I’m wondering why it’s not used all over! Write a bunch of small tests, to see how the API works, to learn the quirks, etc… Keep the tests. You can use them to validate the next release from the vendor works like you expect it to. Powerful idea indeed!

We have an extensive C++ code base for our data acquisition back-end.  You could euphemistically call it “organic”. We’re trying to improve the code base by refactoring.  If you deal with legacy C++ code, you really need to get Michael Feather‘s book Working Effectively with Legacy code.  The man is a genius!

Since this code base had no unit tests, and we don’t like refactoring without some tests, we decided to investigate what was available in the windows C++ world.  We decided to use CppUnitLite simply because it was easy to integrate with our vintage tools.  We soon ran into a minor stumbling block…
Our back-end consists of multiple DLLs, mostly involved with acquiring data from various devices (e.g. a plug-in type of architecture). We wanted to run the Unit Tests on objects internal to the DLLs; those objects are not exposed to the DLL clients.  It is simply not practical (or advisable) to expose those objects.

The solution:  put the unit tests inside the dll, and expose a single function to perform the actual test execution.  You then have a simple external driver program load the dll and call that function.  No need to expose your guts.

Clearly, you want to be careful to not have the unit tests in the version of the DLL you ship out.  Simply have a #define controlling wether the tests are compiled in or not.

Just a neat little technique for those running into this problem.

I have been catching up on my ButUncleBob reading (do check it out, it’s full of good stuff, even if you’re not into Agile).  As I was navigating the site, I cam across James Grenning‘s comments.

His latest post comments on the lack of continuous learning (in the software development arena) on the part of embedded developers.  This caused me some pause.  Is it true?  Are we, as a group, not embracing advances in the software development arena? He quotes Jack Ganssle’s poll on the use of OOP and C++.  Concentrating on the 16 & 32-bit micros, it shows that 2/3 of designers don’t use any Object Oriented aspects of C++.  Over 15 years after the wide spread availability of compilers.

Looking back on my experience, when I was working on a large embedded C++ telecom project, back in the mid-90s, we were simply using it as a better C.  Sad to say, but it looked like I was one of the only designers interested in applying OO principles.  Here we had a language that allowed you to do things to improve the maintainability and architecture of your design, but no one was making use of it.  The one use they did make of inheritance was in a command hierarchy, which is so horrendous to contemplate that I have blocked it from my memory. One of the reasons I moved to a smaller project…

I guess things have not changed much in 10 years.