Post by thread:[EE]: adding an external counter

embedded engineer wrote: > > Hello, > > I am in need of an additional 16 bit counter. T1 is already used. > Anyone know of an inexpensive external counter that I could interface > with I2C? This probably sounds dumb, but why not use timer0 or timer2, then just use interrupt on overflow to increment a second byte, to give a 16 bit counter? Or just implement a 16 bit counter in software? It's only a few asm instructions. I apologise in advance if your particular needs make this not possible. :o) -Roman -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> I am in need of an additional 16 bit counter. T1 is already used. > Anyone know of an inexpensive external counter that I could interface > with I2C? How about using timer 0 and extending it in software? ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, spam_OUTolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

"David W. Gulley" wrote: > > embedded engineer wrote: > > I am in need of an additional 16 bit counter. T1 is already used. > > Anyone know of an inexpensive external counter that I could interface > > with I2C? > > What is your definition of inexpensive ($0.10 or $10.00)? $0.10 would be nice :) but $0.50 to $1.00 is still cheap. David Koski -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Roman Black wrote: > > embedded engineer wrote: > > > > Hello, > > > > I am in need of an additional 16 bit counter. T1 is already used. > > Anyone know of an inexpensive external counter that I could interface > > with I2C? > > This probably sounds dumb, but why not use timer0 or > timer2, then just use interrupt on overflow to > increment a second byte, to give a 16 bit counter? > Or just implement a 16 bit counter in software? > It's only a few asm instructions. I apologise > in advance if your particular needs make this > not possible. :o) > -Roman That is a good idea. I should have been more specific. The problem with that approach is it requires more power. I want to wake up, start the counter, go to sleep and wake up again to retrieve the count. David Koski -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

T1 is used for real time. It is running at 32khz to wake up every 2 seconds. (Actually every second because I set the high bit of T1H on every interrupt.) I have a transducer that generates about 11khz to 15khz and I need to count for at least 800ms. I would like to interface an external counter with I2C to read the counts. It could be reset on power up as it would be powered down between readings. Power consumption must be at a minimum. Otherwise the PIC could just stay awake for a second or two and poll (4mhz PIC clock) the transducer clock. The goal is to keep the average power requirement less than 35ua when reading the transducer once per minute. David Koski Bob Ammerman wrote: {Quote hidden}> > How is T1 being used? > > What do you need your extra counter to do? > > What will it count? (time or external pulses)? > > Bob Ammerman > RAm Systems > (contract development of high performance, high function, low-level > software) > > {Original Message removed}

Is it necessary to run PIC at 4MHz? Why not 100KHz and use TMR1 as counter? What other tasks your unit is doing? WBR Dmitry. embedded engineer wrote: {Quote hidden}> > T1 is used for real time. It is running at 32khz to wake up every 2 > seconds. (Actually every second because I set the high bit of T1H on > every interrupt.) I have a transducer that generates about 11khz to > 15khz and I need to count for at least 800ms. I would like to interface > an external counter with I2C to read the counts. It could be reset on > power up as it would be powered down between readings. Power > consumption must be at a minimum. Otherwise the PIC could just stay > awake for a second or two and poll (4mhz PIC clock) the transducer > clock. The goal is to keep the average power requirement less than 35ua > when reading the transducer once per minute. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

The unit operates the USART at 9600/19.2k baud. 4mhz works well for that. Real time is needed and T1 works well for that and it is convenient to have it wake up the PIC. David Koski "Dmitry A. Kiryashov" wrote: {Quote hidden}> > Is it necessary to run PIC at 4MHz? Why not 100KHz > and use TMR1 as counter? What other tasks your unit > is doing? > > WBR Dmitry. > > embedded engineer wrote: > > > > T1 is used for real time. It is running at 32khz to wake up every 2 > > seconds. (Actually every second because I set the high bit of T1H on > > every interrupt.) I have a transducer that generates about 11khz to > > 15khz and I need to count for at least 800ms. I would like to interface > > an external counter with I2C to read the counts. It could be reset on > > power up as it would be powered down between readings. Power > > consumption must be at a minimum. Otherwise the PIC could just stay > > awake for a second or two and poll (4mhz PIC clock) the transducer > > clock. The goal is to keep the average power requirement less than 35ua > > when reading the transducer once per minute. > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Set up a CMOS ripple counter clocked by the transducer. Hook a high order bit of the counter to RB0 (eg: the bit that toggles every 16384 clocks). Enable RB0 interrupt on rising edge When RB0 interrupt occurs store value of Timer1. Change RB0 to interrupt on falling edge. When next RB0 interrupt occurs compute # of timer 1 ticks elapsed. You now have everything you need to compute the frequency or period of the transducer. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) {Original Message removed}

Hi. USART just sending or both receiving and sending? If just sending 19.2K means you will need 153.846 KHz resonator. Actually 150 will be fine as well. Probably you'll not need to send device to sleep at all. (T1 is free in this case) The goal is to make that unit cheap as well right? WBR Dmitry. embedded engineer wrote: {Quote hidden}> > The unit operates the USART at 9600/19.2k baud. 4mhz works well for > that. Real time is needed and T1 works well for that and it is > convenient to have it wake up the PIC. > > David Koski > > "Dmitry A. Kiryashov" wrote: > > > > Is it necessary to run PIC at 4MHz? Why not 100KHz > > and use TMR1 as counter? What other tasks your unit > > is doing? > > > > WBR Dmitry. > > > > embedded engineer wrote: > > > > > > T1 is used for real time. It is running at 32khz to wake up every 2 > > > seconds. (Actually every second because I set the high bit of T1H on > > > every interrupt.) I have a transducer that generates about 11khz to > > > 15khz and I need to count for at least 800ms. I would like to interface > > > an external counter with I2C to read the counts. It could be reset on > > > power up as it would be powered down between readings. Power > > > consumption must be at a minimum. Otherwise the PIC could just stay > > > awake for a second or two and poll (4mhz PIC clock) the transducer > > > clock. The goal is to keep the average power requirement less than 35ua > > > when reading the transducer once per minute. > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

David I think you are right. I just looked into specs, it's consuming more than 35uA at 150KHz. WBR Dmitry. "Dmitry A. Kiryashov" wrote: {Quote hidden}> > Hi. > > USART just sending or both receiving and sending? > If just sending 19.2K means you will need 153.846 > KHz resonator. Actually 150 will be fine as well. > Probably you'll not need to send device to sleep > at all. (T1 is free in this case) The goal is to > make that unit cheap as well right? > > WBR Dmitry. > > embedded engineer wrote: > > > > The unit operates the USART at 9600/19.2k baud. 4mhz works well for > > that. Real time is needed and T1 works well for that and it is > > convenient to have it wake up the PIC. > > > > David Koski > > > > "Dmitry A. Kiryashov" wrote: > > > > > > Is it necessary to run PIC at 4MHz? Why not 100KHz > > > and use TMR1 as counter? What other tasks your unit > > > is doing? > > > > > > WBR Dmitry. > > > > > > embedded engineer wrote: > > > > > > > > T1 is used for real time. It is running at 32khz to wake up every 2 > > > > seconds. (Actually every second because I set the high bit of T1H on > > > > every interrupt.) I have a transducer that generates about 11khz to > > > > 15khz and I need to count for at least 800ms. I would like to interface > > > > an external counter with I2C to read the counts. It could be reset on > > > > power up as it would be powered down between readings. Power > > > > consumption must be at a minimum. Otherwise the PIC could just stay > > > > awake for a second or two and poll (4mhz PIC clock) the transducer > > > > clock. The goal is to keep the average power requirement less than 35ua > > > > when reading the transducer once per minute. > > > > > > -- > > > http://www.piclist.com hint: The PICList is archived three different > > > ways. See http://www.piclist.com/#archives for details. > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

You bring up some good points. We already have RB0 connected in parallel with USART RX for wakeup. I guess they could be or-ed or use RB-change. A bigger problem though is reading T1. On the flash PIC 16F873 it cannot be done as it can modify the contents of T1 itself. That would corrupt the real time clock. See the errata for 16F873 for example. I am now exploring the possiblilty of using an external RTC instead, that would interrupt every second or minute. That would free up T1 to use as a counter. Dallas Semiconductor has some but I'm not sure if they have exactly what we need. Some of them run at less than 0.5ua. Thanks, David Koski Bob Ammerman wrote: {Quote hidden}> > Set up a CMOS ripple counter clocked by the transducer. > > Hook a high order bit of the counter to RB0 (eg: the bit that toggles every > 16384 clocks). > > Enable RB0 interrupt on rising edge > > When RB0 interrupt occurs store value of Timer1. > > Change RB0 to interrupt on falling edge. > > When next RB0 interrupt occurs compute # of timer 1 ticks elapsed. > > You now have everything you need to compute the frequency or period of the > transducer. > > Bob Ammerman > RAm Systems > (contract development of high performance, high function, low-level > software) > > {Original Message removed}

----- Original Message ----- From: "embedded engineer" <.....embeddedKILLspam@spam@ELUCIT.COM> To: <PICLISTKILLspamMITVMA.MIT.EDU> Sent: Wednesday, May 09, 2001 5:13 PM Subject: Re: [EE]: adding an external counter > You bring up some good points. We already have RB0 connected in > parallel with USART RX for wakeup. I guess they could be or-ed or use > RB-change. A bigger problem though is reading T1. On the flash PIC > 16F873 it cannot be done as it can modify the contents of T1 itself. > That would corrupt the real time clock. See the errata for 16F873 for > example. Would this work around the T1 problem: Directly read (using BTF instructions) the port pin used to clock the T1 timer, watching for the appropriate edge to go by (either 0->1 or 1->0, whichever applies), then read T1 immediately thereafter. To get the count. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> T1 is used for real time. It is running at 32khz to wake up every 2 > seconds. (Actually every second because I set the high bit of T1H on > every interrupt.) I have a transducer that generates about 11khz to > 15khz and I need to count for at least 800ms. I would like to interface > an external counter with I2C to read the counts. It could be reset on > power up as it would be powered down between readings. Power > consumption must be at a minimum. Otherwise the PIC could just stay > awake for a second or two and poll (4mhz PIC clock) the transducer > clock. The goal is to keep the average power requirement less than 35ua > when reading the transducer once per minute. You could program a 12C508A to be the external counter with as many bits as you need. The transducer drives timer 0 directly. The software has to periodically read timer 0 and transfer any new increment to a larger software counter. You could even have separate pins for gate and reset and still have two left over for the IIC. Note that the 12C508 clock must be a bit faster than 4x the maximum count frequency if it's a square wave, more if it's not. 100KHz RC looks like it would work here. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, .....olinKILLspam.....embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Bob Ammerman wrote: > > ----- Original Message ----- > From: "embedded engineer" <EraseMEembeddedspam_OUTTakeThisOuTELUCIT.COM> > To: <PICLISTspam_OUTMITVMA.MIT.EDU> > Sent: Wednesday, May 09, 2001 5:13 PM > Subject: Re: [EE]: adding an external counter > > > You bring up some good points. We already have RB0 connected in > > parallel with USART RX for wakeup. I guess they could be or-ed or use > > RB-change. A bigger problem though is reading T1. On the flash PIC > > 16F873 it cannot be done as it can modify the contents of T1 itself. > > That would corrupt the real time clock. See the errata for 16F873 for > > example. > > Would this work around the T1 problem: > > Directly read (using BTF instructions) the port pin used to clock the T1 > timer, watching for the appropriate edge to go by (either 0->1 or 1->0, > whichever applies), then read T1 immediately thereafter. To get the count. Hmm... good point. Microchip says there is no workarround, but why not? I might give that a try if I need. That's kind of what I am doing with another unit that is not quite so power frugal. On T1 int (1/sec) I set a global flag. In my code I watch the flag, reset it, count until set again. But the PIC is awake for about 2 seconds :( Thanks, David Koski -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin Lathrop wrote: > > > T1 is used for real time. It is running at 32khz to wake up every 2 > > seconds. (Actually every second because I set the high bit of T1H on > > every interrupt.) I have a transducer that generates about 11khz to > > 15khz and I need to count for at least 800ms. I would like to interface > > an external counter with I2C to read the counts. It could be reset on > > power up as it would be powered down between readings. Power > > consumption must be at a minimum. Otherwise the PIC could just stay > > awake for a second or two and poll (4mhz PIC clock) the transducer > > clock. The goal is to keep the average power requirement less than 35ua > > when reading the transducer once per minute. > > You could program a 12C508A to be the external counter with as many bits as you > need. The transducer drives timer 0 directly. The software has to > periodically read timer 0 and transfer any new increment to a larger > software counter. You could even have separate pins for gate and reset and > still have two left over for the IIC. Note that the 12C508 clock must be a > bit faster than 4x the maximum count frequency if it's a square wave, more > if it's not. 100KHz RC looks like it would work here. Or maybe use a 12Cxxx to generate 1hz wakeup pulse. That would free up T1. I'll have to look into the power consumption. Or maybe even offload the transducer code to the 12Cxxx. Thanks, you got me thinking. David Koski -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

David Koski said: > > > You bring up some good points. We already have RB0 connected in > > > parallel with USART RX for wakeup. I guess they could be or-ed or use > > > RB-change. A bigger problem though is reading T1. On the flash PIC > > > 16F873 it cannot be done as it can modify the contents of T1 itself. > > > That would corrupt the real time clock. See the errata for 16F873 for > > > example. > > to which Bob Ammerman replied: > > Would this work around the T1 problem: > > > > Directly read (using BTF instructions) the port pin used to clock the T1 > > timer, watching for the appropriate edge to go by (either 0->1 or 1->0, > > whichever applies), then read T1 immediately thereafter. To get the count. David then commented: > Hmm... good point. Microchip says there is no workarround, but why > not? I might give that a try if I need. That's kind of what I am doing > with another unit that is not quite so power frugal. On T1 int (1/sec) > I set a global flag. In my code I watch the flag, reset it, count until > set again. But the PIC is awake for about 2 seconds :( And Bob opined: I'm guessing that the errata's comments about 'might not increment' would only apply to an increment that was supposed to happen somewhere in the vicinity of the read. If your read is nowhere near that, I'm going to bet that it would work fine. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Bob Ammerman wrote: {Quote hidden}> > David Koski said: > > > > > You bring up some good points. We already have RB0 connected in > > > > parallel with USART RX for wakeup. I guess they could be or-ed or use > > > > RB-change. A bigger problem though is reading T1. On the flash PIC > > > > 16F873 it cannot be done as it can modify the contents of T1 itself. > > > > That would corrupt the real time clock. See the errata for 16F873 for > > > > example. > > > > > to which Bob Ammerman replied: > > > > Would this work around the T1 problem: > > > > > > Directly read (using BTF instructions) the port pin used to clock the T1 > > > timer, watching for the appropriate edge to go by (either 0->1 or 1->0, > > > whichever applies), then read T1 immediately thereafter. To get the > count. > > David then commented: > > > Hmm... good point. Microchip says there is no workarround, but why > > not? I might give that a try if I need. That's kind of what I am doing > > with another unit that is not quite so power frugal. On T1 int (1/sec) > > I set a global flag. In my code I watch the flag, reset it, count until > > set again. But the PIC is awake for about 2 seconds :( > > And Bob opined: > > I'm guessing that the errata's comments about 'might not increment' would > only apply to an increment that was supposed to happen somewhere in the > vicinity of the read. If your read is nowhere near that, I'm going to bet > that it would work fine. I would bet that to be 99.99 percent certain--not certain enough for this project. Furthermore, the accuracy would be reduced if the T1 transition is to be avoided in firmware. I was starting at a T1H transition for improved accuracy, counting T1H transitions in a loop and counting transducer input transitions for n T1H transitions. It worked great on the 16C7x. My problem has been solved--me thinks--by using an external RTC timer to interrupt the PIC every second. Some units draw less than 1ua. That frees up T1 for using as a counter to count the pulses from my transducer. As I understand, it can even be counting when the PIC is asleep. Regards, David Koski @spam@dkoskiKILLspamelucit.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body