Version Control

I'm a developer of yea old ways and old days. Most of my work is in embedded systems that involve no OS at all, or contain  nothing more than a framework to start work from. To make things a bit more chaotic, a lot of my work also involves designing hardware as well as writing appropriate firmware for the hardware that has been designed.

My firmware workflow is more or less set, if the firmware is being written from scratch. It basically involves writing hardware test modules, then laying down the final applications's foundation and then to integrate low level code in the foundation.

Once the low level code starts living together, it boils down to writing higher up interfaces to correctly implement the required functionality. Now, when I am writing so much of code (smallest project being a few hundred lines of assembly code, largest one being few thousand lines of C code) there was always a need of keeping a track of what I have done and when code broke, be able to revert back to the older working version.

In my initiate days (like 15 years ago), I had set up a simple system for backing up my code and maintaining a proper track of changes made etc. Since I was a lone developer on every one of my project modules, this way worked very well, and I never felt real need to start learning any of the fancier VCS implementations like SVN or CVS etc.

However, for the last few years or so, my projects are becoming bigger and there is now need to follow/track/revert/etc. changes made to my hardware designs as well as to my firmware. And to top it off, I have learnt to program in Python and WxPython and now some of my works also involve GUI/Non-GUI applications written in Python. And of course my simple system started showing cracks. Some of these cracks were simply my laziness (:P) and some of them were simply because I am not a thinker with lot of foresight (Hmmmm, maybe I shouldn't admit this in writing!)

So I finally put up SVN (TortoiseSVN, on Windows, because most of my other, software was on Windows). Unfortunately, probably because of my lack of clarity of concepts, I failed to make SVN fit to my workflow! That is when I came across an article by Joel Spolsky (http://hginit.com)

introducing Mercurial.

And in two days time, I was able to wrap almost all (95%) of my workflow in Mercurial. And on top of that I found out that I was able to wrap the remaining workflow (5%) around Mercurial. Today I am a happy user of the excellent tool. I use TortoiseHg (http://tortoisehg.bitbucket.org) on Windows 7, and am able to track/revert/follow everything that I do. Including my hardware designs, todos and code!

This is not going to be a Hg tutorial, because there are more than few resources that teach Hg to even a log! The resources that were useful to me were:

1) http://hginit.com

2) http://tortoisehg.bitbucket.org

3) http://mercurial.selenic.com

Tri-State!D-Uh, what's that?

During the last ten years or so, I've interfaced with literally thousands of students, usually in their last year of engineering or Master's degree program in some college and other, usually in electronics or instrumentation.
What I found surprising was that more than 80% of these students simply had no concrete idea about what Tri-State is about. I think, that I have a reasonable idea about what tri-state is, and I'll get some of my thoughts across.

To begin with let us talk about digital logic. By definition digital logic devices (gates,flip flops etc.) will give only one of the two voltage levels as output. A Logic Zero (Usually within few millivolts of the GND reference terminal, dependent upon how much current is being sunk into the output), and a Logic One (Usually within few millivolts of the VDD reference terminal, dependent upon how much current is being pulled from it).

A typical logic output structure (TTL) looks like the figure 1. TTL stands for Transistor-Transistor Logic and usually is run from a 5V (+/- 5%) supply voltage. This figure of course does not depict a full TTL stage but is good enough for our discussion.

When the output is Logic One, the upper transistor is On, presenting a low resistance path to +5V, and when output is Logic Zero, the lower transistor is On, presenting a low resistance to GND. The logic block driving the transistors makes sure that both transistors NEVER turn on simultaneously. If they were to turn on together the +5V supply would effectively be shorted to ground through a small resistance, and the resulting current would destroy the output stage.

Figure 1

Now, if an additional transistor were added, like in the Figure 2, and if both inputs to the output stage were

pulled low by turning on the extra transistor added at the bottom, then both the output stage transistors will be in the OFF state, irrespective of the inputs presented to the logic block.
Since both transistors are in the OFF state, they would end up presenting a very large resistance (impedance!) to both ground as well as the supply rail. Under this circumstance, if an external voltage (0 < Vext < Vsupply) were inserted on the Vout pin, it would not matter.
Under this condition the output of our logic device is in a high impedance state. This is called tri-state.

A practical application of tri-state is that it allows many logic gate outputs to be connected to the same bus, and then by enabling only one gate at a time, keeping other outputs in tri-state, it is possible to poll many outputs. Read up on 74LS125 to get an idea. The same technique is used to tri-state data bus outputs in many parallel interface chips (e.g. the 74xx245 bus driver or 64256 like SRAM chips, LCDs etc.)

A quick way to check tri-state is to measure the voltage at output of a logic gate with a simple DMM. The high impedance of the transistors will effectively form a voltage divider (loaded to a small extent by the DMM's input impedance) and would end up showing a voltage approximately half of supply voltage.
This test can fail sometimes, if there are leakage paths available on the board. The leakage paths will end up providing enough current to either pull-up or pull-down the output of the gate. Under these circumstances, simply touch the DMM probe (the one that is put on the Vout node) with your finger. If the voltage changes then the output is almost guaranteed to be in tri-state.
This trick will NOT work very well if there are low value (< 10k) pull up resistors connected on the pins, or if there are other devices connected to the same output that might drive the output to some specific voltage.


If you find any obvious mistakes in what I have written here please do get back and bite, so I can correct those mistakes.

Eh! Back me am!

Hopefully, I will be able to keep my promise of blogging more, this time around! Let's see what has happened with me in the last year and half (since my last blog)! In a chronologically random order :P and obviously not complete!

1) I delivered some training kits to CCOEW.
    USB powered, 8051, Parallel ADC/DAC, LCD, 7 segment, Serial ADC/DAC/EEPROM/RTC,
    Keyboard, a test program in assembly that made me feel good about myself.
2) I had to restart programming on lower end PIC micro-controllers (Yuck)
    How can a company manufacture a 8 pin micro-controller that costs @50/- per unit, and NOT give it at
    least one hardware PWM channel, is beyond me!
3) Read Inferno by Dan Brown.
    Another Robert Langdon novel with a storyline similar to Arun Shari's old novel in Marathi (from like
   1975) but with a very unexpected and welcome twist at the end. Loved it. After reading through trash like
   Digital Fortress and Deception Point (Both by Dan Brown) felt good to know that he can still write pretty
   well.

Oh my god! I am boring people with random bits and pieces of my life. That is sick. Yuck.
Next thing you know I will be detailing about what colour shirts I am wearing and asking for opinions!

Maybe people will be more interested in technical stuff that I do sometimes?

I recently  completed testing a spark arc based ozone generator. Uses a Tiny44 controller to drive a small 12V compressor and a HV spark gap drive mechanism (18kV output into a 10mm gap) that generates a continuous spark in a glass tube. The compressor drives air over the spark allowing ozone generation by the UV generated in the spark. Let's see if I can somehow make this into a more commercial product.

Also worked on a LVDT drive circuit recently, that used a completely analog solution, for generating the sine wave (using a Wein bridge oscillator) at 1kHz and synchronous rectification and phase detection that eventually generated 0 to 2V for a 2mm stroke length. The guy who was into manufacturing the circuit had major temperature related issues in the oscillator (sudden shutdowns, frequency drifts, changes in distortion levels and so on so forth).
We tried to temperature stabilize the oscillator gain with a appropriate temperature varying resistive element in the feedback (a tungsten lamp :P). The idea did work, but then there were start-up problems and peak oscillator output related issues.
So I ventured ahead with a simple sine-pwm scheme that used a ATTiny45, running it's output PWM at 100kHz, at 8 bit resolution (Yep, the controller does do that with it's internal PLL etc. etc.) generated a looked up pwm to get a nice low distortion sine wave. And since the person in question has not come back screaming after selling a number of units, I think it is still working. I'll put up all the relevant details soon.

I used LibreOffice Calc to generate the lookup table. Dumped the generated file to a CSV output file. And then generated the output include file (C format, avr-gcc) using a small Python script that used the csv file as input. The Python script was used primarily to arrange the file in a readable form and to make it look nice, put commas and brackets at required places, insert newlines and few comments as seemed appropriate.
Python was an overkill frankly, because the same same task can be done equally well in AWK and in fact even in SeD. But I know both AWK and SeD pretty well, I don't know Python that well and was trying to learn it.

Anyway, now I am working on a KiCAD tutorial as part of the presentation I am to give in my drive to Corrupt Young Minds (with ideas like design your own PCBs instead of paying enormous sums to outsiders, draw neat schematics instead of hand drawn scrawls and similar stuff). I will be posting the tutorial here on the blog as well by end of July first week, sometime.