Post by thread:Building a PIC Timer Queue

First, I'd like to thank all of you who responded to my first query regarding PIC development boards. All of the ideas were good, but I finally decided on a SIMMStick board from Wirz Electronics. Since I don't design hardware for a living, and, in fact, hadn't soldered anything for a year or two, I was mainly interested in setting up a "building block" that I could simply use, without worrying too much about my design skills; I expected to spend most of my time on the software. As I have (;-). What I'm building is an X-10 data logging unit using a 10MHz 16F84. IF I can cram it all into 1K of instructions, it will do async serial I/O (probably at 1200 baud), sample the power line 120 times/second, talk to a real-time clock, and drive a printer at 19.2KB (this may be a bit ambitious, and the printer interface may have to be offloaded to a separate 16F84). Most of the interfacing requires reasonably accurate timing. I've built an interrupt driven timer queue based on TMR0 which _should_ handle up to three independent events, and it seems to function (in MPSIM) pretty much as I expect it to. Events get queued, are posted, and the queue gets updated. My first test was to try generating three independent square waves from Port A fed into a piezo "speaker" unit via .05 uF caps. Pretty simple, each event just inverts a particular output bit, then enqueues the next inversion. And three low tones: 262 Hz, 330 Hz, and 392 Hz. Nice C/E/G chord, right? Well, sort of. After cleaning up a few bugs (;-), what I wound up with is three tones, but they are all fairly distorted, as if a background "buzz" were getting mixed in from somewhere. My first thought was that the loss of the prescaler when I re-loaded TMR0 was causing (mildly) erratic timing, so I descreased the prescaler size. down from 128 to 32. Worst I could lose would be 32 Osc/4 clocks, right? Well, using a five-bit prescale counter made the distortion _worse_! And I haven't found anyone I can borrow a 'scope from, which would give me a clue as to what _kind_ of distortion I'm seeing. Now, I have no plans to build an electronic organ (;-), but if I can't get reliable timing with something as simple as this, how can I expect to clock serial bitstreams this way? The reason I'm posting this to PICLIST is that I've been beating my head against this for several days without getting anywhere. I'm hoping that someone can advise me as to whether what I'm trying to do is: a) simple (e.g. I'm fighting a massive design error on my part (;-)), b) A little complex, but doable (with limitations), c) Not practical due to limitations on the PIC 8-bit TMR0, or d) Something else entirely (;-). It _feels_ like I ought to be able to do this. Somehow. I'm just missing something obvious. Microchip App Note 555 uses something similar, and presuably it works, but all of its code is run as part of the ISR (Interrupt Service Routine). I had hoped I could keep the ISR short (65-odd instructions) and put most of the work outside it. Anyway, hints, clues, and pointers to code that does something similar would be appreciated. Or even a good reason why I'm hitting a brick wall. In the meantime, I'll go back and re-read AN555; maybe something will leap out at me. Frank McKenney / OS/2 Advisor (OS2BBS) McKenney Associates / Richmond, Virginia / (804) 320-4887 Internet: spam_OUTrrs0059TakeThisOuTibm.net / TalkLink: WZ01123

On Fri, 13 Mar 1998 23:31:42 -0500 Frank Mckenney <.....rrs0059KILLspam@spam@ibm.net> writes: >My first thought was that the loss of the prescaler when I re-loaded >TMR0 >was causing (mildly) erratic timing, so I descreased the prescaler >size. >down from 128 to 32. Worst I could lose would be 32 Osc/4 clocks, >right? >Well, using a five-bit prescale counter made the distortion _worse_! This type of uncertainty can be minimized by always resetting the timer at the same point in the ISR. If the timer interrupt is the only interrupt, the timer register will be zero and the prescaler a constant value (probably 3 or 4) when the first instruction in the ISR is executed. If the time delay from the interrupt to resetting the timer is always the same, then the number of cycles lost from the prescaler will also be always the same. Thus the timing will be consistent, but not necessarily exact unless a further analysis is done to make sure that the timer is written only when the prescaler is zero. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]

In his reply of Sat, 14 Mar 1998 14:59:19 -0500 Mike Keitz <mkeitzKILLspamJUNO.COM> commented: >On Fri, 13 Mar 1998 23:31:42 -0500 Frank McKenney <.....rrs0059KILLspam.....ibm.net> >writes: >>My first thought was that the loss of the prescaler when I re-loaded >>TMR0 was causing (mildly) erratic timing, so I descreased the >>prescaler size. down from 128 to 32. Worst I could lose would be 32 >>Osc/4 clocks, right? Well, using a five-bit prescale counter made the >>distortion _worse_! >This type of uncertainty can be minimized by always resetting the timer >at the same point in the ISR. If the timer interrupt is the only >interrupt, the timer register will be zero and the prescaler a constant >value (probably 3 or 4) when the first instruction in the ISR is >executed. If the time delay from the interrupt to resetting the timer is >always the same, then the number of cycles lost from the prescaler will >also be always the same. Thus the timing will be consistent, but not >necessarily exact unless a further analysis is done to make sure that the >timer is written only when the prescaler is zero. Mike, Thank you for the reminder-of-the-obvious about the prescaler always being (near) zero at the start of the ISR. It's embarassing to admit I hadn't thought about that part of it (;-). At least I have some degree of control over that particular end of the code. Trouble is, if I'm going to implement a general-purpose timer queue, a timer event could be scheduled from _any_ point in the code. Are there only the two choices, then: 1) Ignore the prescaler, and restrict my "timer queue" to events which can live with ther resulting "jitter" (whose magnitude will depend on the prescaler size), or 2) Clean up my ISR to make sure all paths to the TMR0 re-load instruction have the same length, AND put a "busy wait" loop in the Enqueue routine to wait for TMR0 bit 0 to change (ensuring the prescalar is at-or-near-to-0 when I update TMR0). Two odd items which may have some bearing on this... Per the 16F8x PDF file, When {the prescaler is} assigned to the Timer0 Module, all instructions (e.g., CLRF 1, MOVWF 1, BSF 1,x ....etc.) will clear the prescaler. When assigned to WDT, a CLRWDT instruction will clear the prescaler along with the Watchdog Timer. Oddity 1: The MPLab simulator does not set its displayed 'prescaler' value back to 0 when a value is stored into TMR0. Oddity 2: In the MicroChip AppNote 555 (interrupt-driven serial I/0) code, the CLRWDT instruction is used _following_ a store into TMR0 - which should have just set the prescaler back to 0. Item (1) could just be a bug in MPLab, and (2) could be a result of the author of the code misreading that section of the 16F8x PDF file regarding switching the prescaler from TMR0 to the WDT, or the reverse. But I thought I'd bring them up to see if anyone can confirm this. Frank McKenney / OS/2 Advisor (OS2BBS) McKenney Associates / Richmond, Virginia / (804) 320-4887 Internet: EraseMErrs0059spam_OUTTakeThisOuTibm.net / TalkLink: WZ01123