Configuring all three counters on a 8254 chip

[joshdoe]

I've got an 8254 timer/counter chip that is part of a DAQ system.

What I want to do is generate a 15kHz signal, but have it put out only a very precise number of pulses, in a range from 100,000 to 2,000,000. However, I am getting a wide range of pulses, so when I ask for 200,000, instead I get 153,743 or 185,436 or some other seemingly random number. You can see an image of my setup here:

http://img277.imageshack.us/my.php?image=counters1qg.gif

Counter 0:
set to mode 3, and loaded with 523
clocked by an 8MHz source
gated by the inverted output of counter 2
out tied to counter 1 and puts out the desired pulses

Counter 1:
set to mode 2, and loaded with 1000
clocked by counter 0
gated to run freely
out tied to counter 2

Counter 2:
set to mode 0, and loaded with the desired number of pulses divided by 1,000
clocked by counter 1
gated to run freely
out line inverted to gate counter 0


So the output from counter 0 should be 15kHz, which then gets divided by 1000 by counter 1, which then causes counter 2 to be decremented. The number of pulses divided by a thousand is loaded into counter 2 to start the pulses, and should put out (counter 2 count value)*1000 pulses.

Any ideas of what I'm missing? Thank you all

 

[joshdoe]

I've made some headway. I've now got it so that it reliably spits out pulses in multiples of 1 000, just not the number I want, i.e. I say 200 000, but i get between 150 000 and 195 000. So it seems like counter 2 is being decremented too quickly.

 

[itsmoked]

joshdoe; I have used that dang 8254 for years in many projects. They have lots of undocumented gotcha's and "nevermind what the doc sez, you can't do that!" things about them. I shudder to think about it even. I will look at the problem tonight (PST) and see if I can provide some more *useful* info. Meanwhile I hope you solve it!

 

[joshdoe]

Thanks itsmoked, not solved yet. I thought it might be a problem with speed, but it doesn't matter whether I have the first timer going at 15kHz, 1kHz, or 1MHz.

 

[IRstuff]

Is your part actually rated for 8 MHz?

TTFN

 

[joshdoe]

IRstuff: the 8254 counter is actually rated for 10MHz, but the DAC card which this is built into provides an 8MHz clock.

 

[felixc]

I don't know what instruments you are using to test your setup. If you remove the feedback to counter 0, are you able to measure if the counter outputs are at the frequencies that you expect?

 

[designchain]

Oh my...I know this won't be a useful post but I had responsibility for quality and reliability of the 8254 at Intel over 20 years ago...this is an ANCIENT (but useful) device...redesign now! ;o)

Mike

--
Mike Kirschner
Design Chain Associates, LLC

http://www.designchainassociates.com

 

[joshdoe]

felixc: I'm using a 25MHz counter (nuclear equipment) to count the pulses and a digital o scope. With and without the feedback counter 0 produces the expected frequency correctly.

designchain: It may be ancient, but it seems to work very well for my purposes, except for the current problem, just have to figure out where those 5k to 50k pulses are going to.

 

[itsmoked]

Well I looked over the whole data sheet<shudder> and I saw nothing in particular that I can see you doing wrong.

I'm sorry that I can't say, "just write this instruction in this order and your problem is over".

So I can only give the approach I would use sitting *there*.

First make sure your meter-counter is triggering for-shore-rocky. Try a different one if you've got it.

Next I would print out the data sheet and work my way thru it with a highlighter. I would mark every mention of caveats and there are a cr@p load of them.

Example 1:
Low-going glitches that violate tPWH, tPWL may cause errors requiring counter reprogramming.

Example 2:
In Modes 2 and 3, if a CLK source other than the system clock is used, GATE should be pulsed immediately following WR of a new count value.

It is some minor detail you have overlooked that you have to ferret out. You have run the hardware enough to have a clear understanding of how you expect it to work and how it does work. Now you have to go back,(something most people are loath to do), and re-read the spec stopping to think about each instruction it has. Pay particular attention to those highlighted caveats.

Keep us posted.

 

[joshdoe]

itsmoked: Thanks for all the info.

I've now got counter 1's GATE pulsed low right after I write the new count value.

My meter-counter seems like it might be a little flaky, so now I'm using another 8254 on the DAC card which counts the pulses, and an ADC (which also has an 8254) being triggered by those same pulses. The numbers match consistently, except for once in a while they are off by 1.

My situation now is that I'm getting 984 counts too many (or maybe 16 counts too few, given that counter 1 divides by a thousand). Sometimes the number is 981 or 985, but it's always in the same range.

Now that it's (mostly) consistent, I suppose the problem with those 984 pulses could just be a timing issue. The next course of action for me is to trace through each gate, out, and clk signal for all three counters. Sounds painful, but I must do it.

 

[itsmoked]

joshdoe; keep slugging there. Let me move out of the box for a moment. The task you are trying to accomplish would be nearly trivial to do with a small microprocessor.

You could use a PIC. Set it up with an 8 bit bus to easily match it to the bus running to your existing 8254, which you pull out and stomp into the linoleuum. You then set up one pin for an output to your DAC. You can setup the PIC to run the exact number of cycles with counters in RAM as large as you want. With the pic running around 20MHz it has a 200ns instruction cycle. 15KHz is 66us. That's over 330 instruction cycles per output pulse to your DAC. Child's play! With that much to spare you could probably add some *features*. I would bet that if you know anything about PICs you could do it in a day... Which would be less time than it will take for you to wring the "54" out!

 

[joshdoe]

itsmoked: Thanks for the suggestion. I have programmed Atmel AVR's before, and even considered using one in this system. It would be very elegant, which I would love. However, there are a few concerns keeping me back. One is the ease of making changes in the future. I won't always be around, so everything has to be easily changed by "the next guy." More importantly, I'm not confident enough in my soldering skills to remove the 8254 and solder in a microprocessor on a $400 circuit board.

As of right now I have it so that it puts out the pulses I want, but also extra, between 500 and 1500. Here's the pseudo code:

Clear everything
Gates 1 and 2 high
Write mode 3 to counter 0
Load counter 0 with 523
Write mode 3 to counter 1
Load counter 1 with 1000
Write mode 0 to counter 2
Load counter 2 with 1
Sleep 1 second (to allow counter 2's OUT to go high, making counter 0's GATE low via the inverter)

Ask user for number of sweeps
Load counter 0 with 523
Load counter 1 with 1000
Pulse the GATE of counter 1
Load counter 2 with $sweeps (50, 200, whatever)


This gives me $sweeps*1000+some. The output of counter 0 actually goes to an ADC, where another 8254 gives a 16us delay, then triggers an acquisition. I fed the waveform that the DAC generates into the ADC, and it seems like those 900 some odd extra pulses are coming in at the end of the $sweeps*1000 pulses.

At this point I'm ready to take what I can get, and just disregard those extra points of data. Not the cleanest, but it works. I'm guessing there's some sort of delay between counter 2's OUT going high and the gate of counter 0 going low.