PHY 406 - Microprocessor Interfacing Techniques

Module 4 - Time and Timers

In this module we look at some issues with counters and timers. There is only so much time and therefore we can only look at a few issues, but it is important to realise some of the problems and successes of the use of time as a variable.

Preparation

You will need the following VIs

Functions>>Data Acquisition>>Digital I/O>>Read From Digital Port.vi

We will be using an interface which will be used for the next two modules. It contains a counter and a digital-to-analog converter. In this module we will only be using the counter part. Make sure (by asking if necessary) that you understand the circuit diagram for the keypad and display interface timer_da.pdf

You are asked some questions which assume some knowledge of digital logic and how things are put together. In particular you should know about "ripple" counters and their foibles. If you are uncertain - or just need a refresher - look at the document counters.pdf

You will have realised from module 1 that the computer system has some troubles with timing. Just relying on the time it takes the computer to do something is not reliable at all, it may not be as obvious that relying on the computer timing is also a problem. The computer clock only has a finite resolution (1mS for Win95) and can also go wrong! In general the more you can move the timing into hardware, the better.

Equipment

You will need the timer and digital-to-analog converter interface which is kept in the cupboard. For this practical all the interfaces should be identical so there should be no need to record the number of the interface unless the thing doesn't work!

The interface consists of a ripple counter which is clocked by a 1MHz clock. The computer reads some lower bits of the counter which are counting at such a rate that you can see the individual counts.

There is a general issue with LabVIEW that it has problems distinguishing between various types of integer (they all have blue wires!) and this can lead to some very "mysterious" problems. I suggest that in order to avoid these, you convert your digital inputs to 16-bit signed integers as soon as you take them and proceed from there. Also watch out for type conversion "dots" on inputs which you didn't expect to be there.

Make a Clock

There is a demonstration program - timer_da_test.vi - in the e:\l_view\examples which shows you roughly how the timer and the d/a converter interface works.
There is also a program - clock_face.vi - in the same directory which shows you the face of a clock, but has no wiring.
Construct a wiring diagram to use the counter as the timing element for the clock. You will need to find out the rate at which the timer "ticks" in order to set the clock rate correctly. Your clock should be capable of being accurate to +- ½ second or better per day if the input frequency is steady at 1MHz and the speed control is set to zero. The main issue here is that the 'ticks" don't occur at convenient intervals and you have to arrange to accurately convert ticks to hh:mm:ss.
Make sure that the control to adjust the speed of the clock works correctly. You do not need to actually wait for 24hours to verify the operation of the clock! What I suggest you do is attempt to convince me by calculation and argument that your control works as advertised. Under certain circumstances you may be able to demonstrate that the control works by temporarily increasing the "coarseness" so that it has a much more dramatic effect.

Does the Counter Work?

Run the VI timer_error.vi from the examples directory. The VI has roughly the following strategy: i) Read the timer three times in rapid succession. ii) If the first and third reading differ proceed, otherwise go again. iii) If the difference between the first and the third is one, proceed, otherwise go again iv) If the middle reading does not agree with one of the first and third - yell!
Explain what exactly is being probed here.
Note a few of the "errors" which are displayed. Depending upon the weather, what you had for breakfast, and other uncontrolled variables, this might take a short or a long time.
Adjust the VI to include the case of 255->0 as a valid transition.
Note a few more errors, particularly those (if any) with 255->0 as the transition
Calculate the probability of an error occurring when the counter is read.
Comment on the likely causes of these errors (Hint: there are several causes of errors and different interfaces might display different weighting to the various problems)
Devise a simple strategy for ensuring that the number you read from your counter is always correct
Apply it to your clock.

Advanced

This section is for the intelligent/bored or otherwise fascinated. There are no marks for this section - only the satisfaction of solving a problem or two.

Find out about the difference between "ripple" counters and "synchronous" counters.

Notes

This practical talks about two issues.

What happens when an input isn't quite what you think and needs "adjusting" - your clock would have been much easier if I could have guaranteed a 1.0000000000Hz input, but I couldn't.
The trouble with machines that make hundreds of thousands of reading is that low probability events become more of a nuisance. In the example above, the chance of an error is low, but with so many readings, the chance cannot be neglected - "nearly perfect" isn't perfect enough!