On Tue, 1 Jul 1997 00:11:00 -0700 Antonio Benci writes: >I am in the process of putting together a Pulse Width measurement >controller for a laser trigger unit. I need to measure an incomming >pulse , 20uS min to 10mS max, delay this pulse by 150uS and resend the >measured pulse. A fixed delay pulse trigger would describe it. I've >got >the delay and output triggers nutted out and working on an 8MHz 16C84. >The pulse measurement side is causing insomnia. I've looked at Andy >Kunz >example for RC Servo's but am having a little difficulty in >translating >the Parallax ASM code to MicroChip format. Sorry, i'm MCHIP asm >biased. >Any help would be appreciated. Cudos to the one who supplies a >solution >with full acknowledgement in possible paper. > Your description sounds like a delay line. A digital soultion would be characterized by the amount of uncertanty in the measurement of start and stop time of the input pulse caused by sampling. A PIC will be able to sample at 1/4 the crystal rate; an 8 MHz PIC could resolve the pulse's start and end to within 500 ns. One could first consider the non-PIC solution of a long shift register which merely shifts the sampled pulse through. To get performance equivalent to the proposed PIC implementation it would require a shift register of 300 stages clocked at 2 MHz. Such registers used to be available in CMOS but are probably specialized items now. A virtual shift register can be built with a RAM and a counter to retreive an old sample, store new sample, go to next address (think of it as a constant-length FIFO). This gets into some complication with needing extra logic to coordinate the reading and writing process. However, higher resolution (on the order of twice the RAM's access time, or 20-30 ns with readily available CMOS SRAMs) is the benefit. Assuming 200-500 ns resolution is acceptable, a PIC will work, having the benefit of being able to use a standard part and add new features easily through software. This looks like an ideal application for the capture/compare unit found in most 28-pin PIC16CXX. Set the timer1 to free-run (timer mode). Set one CCP unit to capture the incoming pulse and one to compare and generate the output pulse. The program would be set for capture rising edge wait for capture S = captured value set to capture falling edge add 150 us to S and set compare to generate rising edge wait for capture E = captured value wait for compare (may have already occurred if input pulse > 150 us add 150 us to E and set compare to generate falling edge wait for compare start over The waits could be software polling if the PIC has nothing else to do, or interrupt-driven. Using interrupt driven will leave almost all of the PIC porcessing time free to add more features such as outputting the measured length of the pulse, etc. There is no danger of the timer overflowing, so use as fast a PIC clock as possible to improve resolution. At 33 MHz the sample period will be about 125 ns. The PIC16C84 does not have a CCP module that makes this task so simple. The job could be done, but it would require considerable use of "tricks" to achieve 1 instruction cycle resolution. I would probably approach it by using the TIMER0 running continuous as a time base, the RB0 interrupt for capture, and software synchronized to TIMER0 for generating the output pulse. For a one-off project it would be much simpler to switch to a PIC having the hardware capture/compare features.