ATTiny1614-- What happens when Timer B Overflows?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm thinking about using Timer B for frequency measurement from analog comparator output.

 

page 245 21.3.3.1.4 Input Capture Frequency Measurement Mode

 

But, timer B doesn't seem to have the ability to generate an interrupt on overflow. 

 

Should I expect it to simply wrap if the time between edges is too long to fit in the 16 bit register?  Or, maybe just stop at the MAX value?

 

Thanks!

 

 

This topic has a solution.
Last Edited: Wed. Sep 29, 2021 - 08:05 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The simulator is very useful for checking such things.
The TCA generates an event every 40000 clocks or every 80000 clocks.

At 80000 clocks, you can see that the TCB count wraps.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The datasheet is not explicit on that... I guess experimentation is needed. My bet would be, the counter wraps and keeps counting, no interrupt is generated.

 

edit: lol, while I was reading the datasheet, Kabasan was already experimentingcheeky

Last Edited: Sat. Jan 11, 2020 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This TCB thing without OVF is a disaster if you want to measure anything slower than counter wrap around time. One of the ways is to use RTC to measure the time between TCB matches to estimate the number of overflows.

Even with overflow, measuring freq and pulse width mode is useless too since there is no indication when CNT is latched, so you have to mux between two modes separately to measure both.

In essence, for slow PWM the overhead (code and HW) makes it no better than a good old edge detection with OVF, so, yeah, seems like a waste of an effort developing those new features.

I needed 4/5 timers and a DAC (and soic150-14 is great), but now I'm thinking about DA/DB family in TQFP32, a bit bigger but not as much as soic 300mil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For t1614... Sync Timer A with B and use A overflow. mind the sync errata. That is what I did. Microchip not having an overflow with capture was the stupidest idea in microcontroller design history.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

12oclocker wrote:
Microchip not having an overflow with capture was the stupidest idea in microcontroller design history.

zazik wrote:
I'm thinking about DA/DB family

 

Well, at least they added overflow to TCB in the AVR-Dx series and apparently also to the new tiny AVR-2 series  https://www.microchip.com/wwwproducts/en/ATTINY1627

Last Edited: Mon. Mar 15, 2021 - 12:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need to have slow (20-100Hz) PWM and slow capture, and fast (20-30kHz) PWM and fast capture, TCA is doing slow PWM as has more dividers, TCD is doing fast PWM, TCB0 and TCB1 fast and slow capture.

I might rethink if I can move slow capture elsewhere, haven't got a grip with split mode yet, but TCA is not available in my current design.

So I'm using RTC for timing and since it is about 5% off (in my case), I ended up measuring RTC it with TCB first to get the timing calculation more accurate, don't care about power, a bit messy, but works fine.

Definitely will look into TCA sync idea, thank you for the tip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For anyone else that's had this...

Create a second TCB in timeout mode using 65,535 as the max count which listens to the signal.

Create an OR gate with a CCL which wires up the second TCB and the signal

Feed the CCL into the first TCB in frequency measurement mode.

Now the read will cap at 65,535 and not rollover.
 

Last Edited: Mon. Jul 4, 2022 - 12:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would choose the tiny2 series for 32-bit capture.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Depends if you fancy waiting til mid 2023 when they arrive!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I battled this for half a day yesterday. It's impossible to get the TCBn output recognised by the CCL to use as an OR gate to feed into the second TCBn. I tried every conceivable combination, slowed the clock for the TCB thinking the single pulse was too quick, all sorts. It should work but it's likely a bug.

Next best thing, I check the interrupt flag over the first TCBn (in timeout mode) and override the freq calc from the second TCBn if it's set.