ATtiny1614 TCB: Überlauf bei input capture erkennen?

[Anton (antang)]

Mir scheint, es ist unmöglich, beim ATtiny1614 (und Verwandten) einen 
Überlauf von TCB0 bzw. TCB1 in den input capture Modi (bei mir: 
CNTMODE=FRQ) zu erkennen oder gar zuverlässig zu zählen. Offenbar geht 
das nur mit den ATmega-TCB. Kennt jemand einen Trick, wie man das mit 
einem ATtiny schafft?

[S. L. (sldt)]

Wenn ich mich recht erinnere, so wurde auch für den ATmega4809 keine 
Lösung bzw. kein 'Trick' gefunden:
Beitrag "TCB von ATmega4809 megaAVR0 Serie"

PS:
Konkret ab:
Beitrag "Re: TCB von ATmega4809 megaAVR0 Serie"

[Anton (antang)]

Danke! Dann nehme ich einen ATmega4808 oder gleich einen AVR128DB32, 
letzterer erschlägt noch ein paar andere Probleme.

[Wilhelm M. (wimalopaan)]

Anton schrieb:
> Danke! Dann nehme ich einen ATmega4808 oder gleich einen AVR128DB32,
> letzterer erschlägt noch ein paar andere Probleme.

... oder den 1624, wenn es pinkompatibel sein soll.

[Anton (antang)]

Stimmt, TCB mit OVF-Event, danke! Habe ich aber (noch) nicht auf Lager.

[S. L. (sldt)]

> Dann nehme ich einen ATmega4808

?
  Dieser hat doch denselben Mangel.

[Peter D. (peda)]

Die neuen ATtiny sind ja völlig verrückt. TCA hat Overflowinterrupt aber 
kein Capture. TCB hat Captureinterrupt, aber kein Overflow.

Da bleibt wohl nur, den alten ATtiny84 zu nehmen, der kann das.

[S. L. (sldt)]

> Die neuen ATtiny sind ja völlig verrückt ...
> TCB hat Captureinterrupt, aber kein Overflow.

Wie von Wilhelm M. geschrieben, hat Microchip offenbar den Mangel 
erkannt und mit der 'tinyAVR® 2 Family' behoben.

[Peter D. (peda)]

S. L. schrieb:
> hat Microchip offenbar den Mangel
> erkannt und mit der 'tinyAVR® 2 Family' behoben.

Irgendwie lernen die es nie. Statt mal gründlicher nachzudenken und alt 
bewährtes zu übernehmen, werden wieder mal neue Typen am laufenden Band 
rausgeschleudert.
Ich hatte ja kürzlich erst gefragt, was dieser Typenwildwuchs soll und 
mal die vielen 8kB 14-Pinner betrachtet.

[S. L. (sldt)]

Ich würde ja auch sagen, erst eine Weile nachdenken und dann gleich 
richtig machen wäre gescheiter gewesen, aber dann kommt vielleicht 
wieder ein Moderator und nennt mich "großkotzig".

[Anton (antang)]

S. L. schrieb:
>> Dann nehme ich einen ATmega4808
>
> ?
>   Dieser hat doch denselben Mangel.

Stimmt, danke! Also vorerst AVR128DB32 bis ich ATtiny3224 auf Lager habe 
(ich nehme immer das Modell mit dem größten Speicher).

[Wilhelm M. (wimalopaan)]

S. L. schrieb:
>> Die neuen ATtiny sind ja völlig verrückt ...
>> TCB hat Captureinterrupt, aber kein Overflow.
>
> Wie von Wilhelm M. geschrieben, hat Microchip offenbar den Mangel
> erkannt und mit der 'tinyAVR® 2 Family' behoben.

Nicht nur das, sondern man hat damit einen 32bit Timer. Und das ist gut, 
denn bei einem 8bitter kommt es wesentlich auf die Flexibilität der 
internen Peripherie an.

[Peter D. (peda)]

Wilhelm M. schrieb:
> Nicht nur das, sondern man hat damit einen 32bit Timer.

Ist dann aber auch ein atomarer Zugriff möglich, d.h. 3 Temp-Register.
Ansonsten ist das witzlos und ein Kaskadieren in Software gleichwertig.

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Wilhelm M. schrieb:
>> Nicht nur das, sondern man hat damit einen 32bit Timer.
>
> Ist dann aber auch ein atomarer Zugriff möglich, d.h. 3 Temp-Register.
> Ansonsten ist das witzlos und ein Kaskadieren in Software gleichwertig.

Da es ja nur um den Capture-Modus geht, lese ich das DB so, dass 
tatsächlich hier Kopien der CNT in die CCMP-Register atomar geschieht 
(zumindest interpretiere ich die Beschreibung des CASCADE-Flags so).

[Veit D. (devil-elec)]

Hallo,

genau, die Übernahme des Zählerstandes erfolgt sicher in Hardware und 
man liest sie nur noch aus. Wenn man bspw. TCB0 und TCB1 kaskadiert hat

ISR(TCB0_INT_vect)
{
  counter.lsb  = TCB0.CCMP;
  counter.msb  = TCB1.CCMP;
  // counter.finish = true;
  TCB0.INTFLAGS = TCB_CAPT_bm;      // clear the interrupt flag
}