Hallo, sehe ich es nicht oder gibts für den Timer TCB wirklich keinen kompletten Satz Clock-Selectbits wie für TCA? Man kann nur den Takt halbieren oder die Einstellung von TCA übernehmen. Ich würde jetzt TCA mit dem gewünschten Prescaler einstellen, dieses für TCB übernehmen und die alte Einstellung von TCA wiederherstellen. Oder gibts eine "gewöhnlichere" Möglichkeit? Im aktuellen DataSheet Kapitel 21.5.1 http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4808-09-DataSheet-DS40002173B.pdf
Hallo, ich hatte etwas falsch gedacht. TCBn kann nur mit vollen oder halben CPU Takt oder mit Takt von TCA0 laufen. Mit eigenen unabhängigen Prescaler ist nicht möglich.
Veit D. schrieb: > ich hatte etwas falsch gedacht. TCBn kann nur mit vollen oder halben CPU > Takt oder mit Takt von TCA0 laufen. Mit eigenen unabhängigen Prescaler > ist nicht möglich. Nicht ganz korrekt ausgedrückt. Das Problem ist, er hat halt selber nur einen 1Bit-Prescaler, das ist alles. Allerdings ist deine ursprüngliche Formulierung "keinen kompletten Satz Clock-Selectbits" doch sehr unglücklich, was wahrscheinlich für den geringen Feedback vom Forum gesorgt hat. Denn was ist "vollständig"? Verglichen z.B. mit den (aus dem dort vorhandenen sehr "breiten" Prescaler) resultierenden Möglichkeiten des Timer1 eines Tiny85 ist fast jeder andere Timer der AVR8 diesbezüglich doch sehr "incomplete"... Sprich: dir fehlt ganz offensichtlich die Übersicht über die Architektur. Das solltest du ändern... Sprich: Viel mehr DBs lesen und zwar auch vergleichend, um die Gemeinsamkeiten und Unterschiede zu erkennen und damit die ganze Bandbreite dessen, was vorkommen kann... Man kann darüber hinaus auch sehr viel aus den Gemeinsamkeiten lernen und daraus, wie genau bestimmte exotische Features aus Programmierersicht sichtbar werden. Letztlich kann man daraus die Funktionsweise der Hardware im Detail ableiten, jedenfalls sehr viel detaillierter, als sie in den DBs erläutert ist. Dieses Wissen ist gelegentlich sehr hilfreich.
Noch leckerer, seltener und umso begehrenswerter ist der TCA: Kann übers Event-System externe Ereignisse aller Art zählen .
Veit D. schrieb: > Ich würde jetzt TCA > mit dem gewünschten Prescaler einstellen, dieses für TCB übernehmen und > die alte Einstellung von TCA wiederherstellen. Interessant...
Hallo, okay. :-) Mit "kompletten Satz Clock-Selectbits" meinte ich, dass ich es Schade finde das TCBn nicht die gleichen Prescalereinstellmöglichkeiten besitzt wie TCA0. Allerdings sind die Timer schwer vergleichbar und mit bekannten Timern vom ATmega328P/2560 erst recht nicht vergleichbar. Sodass meine Eingangsfrage damit schon hinfällig und überholt ist. Ich hatte mich in der Vergangenheit nur mit TCA0 beschäftigt. Mit TCBn spiele ich frisch rum. >> Ich würde jetzt TCA mit dem gewünschten Prescaler einstellen, dieses für >> TCB übernehmen und die alte Einstellung von TCA wiederherstellen. > Interessant... Meine erste Idee funktioniert leider nicht. Das war aus dem Bauch heraus ein verfrühter Gedanke. :-)
:
Bearbeitet durch User
Der TCB ist nicht so universell wie der TCA und nur für ein paar konkrete Aufgaben gedacht. 2xTCA gibt es z.B. beim AVR128DA48.
Hallo, ich muss nochmal darauf zurückkommen. Gehts wirklich nur mir so oder auch anderen, dass beim TCBn Entscheidendes fehlt? Neben fehlenden Prescalern fehlt der Overflow Interrupt. Wäre gesagtes Vorhanden wäre der TCBn aus meiner Sicht komplett und man könnte den unabhängig vom TCA verwenden. Bsp. TCB Capture Pulse-Width Measurement Mode. Entweder man begnügt sich mit Prescaler 1 oder 2. Oder man muss TCA für den Takt verwenden. Und schon ist TCA blockiert. Wenn wenigstens ein TCBn Overflow Interrupt vorhanden wäre könnte man sich auch mit Prescaler 1 und 2 anfreunden. Gibts aber nicht. Also muss man seine maximale Pulsweite kennen, daraufhin den Prescaler von TCA wählen, damit die max. Pulsweite in das Zeitfenster ohne Overflow Möglichkeit reinpasst. Man kann laut Manual mit dem TCB viel machen. Aber dermaßen eingeschränkt das es fast kein Sinn macht und man mit den "alten Timern" der alten Serie besser bedient ist. Also irgendwie finde ich den TCBn im Nachgang komisch.
Veit D. schrieb: > Neben fehlenden Prescalern fehlt der Overflow Interrupt. Im Zählermodus fungiert der Capture-Interrupt offenbar als ein solcher, wobei das entsprechende Register zugleich die Zählweite begrenzt. Wenn du das Capture-Register auf 0xFFFF setzt, sollte dies einem Overflow-Interrupt entsprechen (falls ich das Datenblatt richtig lese). In der Praxis dürfte man aber ohnehin die Zählweitenbegrenzung häufiger benutzen wollen als einen puren N-bit-Overflow; zumindest sagt das meine Erfahrung mit den klassischen AVRs (bei denen es den CTC-Modus ja anfangs noch nicht gab).
:
Bearbeitet durch Moderator
Hallo, leider ist das "Capture" kein Overflow Interrupt und kann diesen auch nicht ersetzen. Der Zählumfang ist auf "einmalig" 0...65535 begrenzt. Man bekommt keine Information das er übergelaufen ist. Habe schon übers Eventsystem nachgedacht oder auch mit TCA. Event nützt einem nichts, weil wenn man nicht mitbekommt das er übergelaufen ist, kann man keinen künstlichen OVF mittels Event erzeugen. Wenn er überläuft wird kein Event Interrupt ausgelöst. Der Event Interrupt löst nur für die individuelle Konfiguration aus - was ja Sinn macht. :-) Habe schon mehrere Möglichkeiten gedanklich durchgespielt damit ich den TCB Capture Pulse-Width Measurement Mode ohne Zählumfangseinschränkung für mich nutzen kann. Ich sehe aktuell keine Möglichkeit. TCA müßte man manuell starten, stoppen und nullen, selbst wenn der Silizium Bug mit der Syncronisation nicht wäre, generiert man damit Zählerstandsunterschiede. Man kann schlecht TCA und TCB zeitgleich starten um den Overflow vom TCA zu nutzen. Das ginge nur wenn TCB den TCA steuern könnte. Ein Capture Event (Flanke) startet TCB selbstständig bei 0. Selbst wenn man beide Timer zeitgleich starten könnte, kann man beide nicht syncron stoppen. TCB würde im Capture Mode selbst stoppen. In dessen Interrupt müßte man dann TCA manuell stoppen und den TCA Overflowcounter auslesen. TCA hat jedoch ein paar Takte weitergezählt wenn TCB stoppt und in seinen Capture Event Interrupt springt. Dann würde eine Rechen- und Vergleichsorgie notwendig um herauszufinden ob beim Capture Event ein Überlauf stattgefunden hat oder doch nicht. Falls überhaupt sinnvoll. Was mir gerade beim schreiben einfällt wäre, TCA im Event-Mode "Count while event signal is high" zu betreiben. Das zu messende Eingangssignal außen nicht nur TCBn sondern auch TCA0 zuführen. Nachteil, man kann somit nur ein Signal messen. Ich möchte 2 messen. Hätte also zwei TCBn verwendet. Auch für ein Signal wäre das ein Workaround für einen Workaround für einen Workaround. Ich verfalle in den Modus immer etwas drumherum bauen zu müssen. Ich meine die megaAVR0 Serie ist schon toll. Aber so richtig im Detail gefallen mir die Timer nicht. Die Fähigkeiten schon aber irgendwie nicht zu Ende gedacht. Ich finde das wirklich sehr Schade um die Möglichkeiten die sich damit auf tun würden.
Veit D. schrieb: > leider ist das "Capture" kein Overflow Interrupt und kann diesen auch > nicht ersetzen. Wir reden aber über den "Periodic Interrupt Mode", ja? Ich habe zwar mittlerweile ein ATmega4809-Board zu Hause liegen, aber erst noch paar andere Baustellen, bevor ich mich intensiver mit diesem befassen kann.
:
Bearbeitet durch Moderator
> ... nicht zu Ende gedacht ...
Deshalb gibt es nun in den AVR128DA ebendieses 'Overflow Interrupt Flag'
für die TCB (sowie TCD). Umfangreichere TCB-Prescaler allerdings hätte
ich mir auch gewünscht.
Veit D. schrieb: > ich muss nochmal darauf zurückkommen. Gehts wirklich nur mir so oder > auch anderen, dass beim TCBn Entscheidendes fehlt? Neben fehlenden > Prescalern fehlt der Overflow Interrupt. Huch? Ist der TCB bei den Mega0 so viel anders als bei den AVR128? Kann ich mir kaum vorstellen...
Angehängte Dateien:
-
ATmega4809_TCB.png
96 KB
> Huch? ... Kann ich mir kaum vorstellen...
Vielleicht sehen Sie auf dieser Seite mehr als wir.
Hallo, @ Jörg: eigentlich rede ich über den "Capture Pulse-Width Measurement Mode". :-) Ich möchte im Endeffekt zwei Pulsweiten messen. Im "Periodic Interrupt Mode" kann man nichts messen. Damit kann man "nur" zeitgesteuert irgendwas auslösen. @ S. Landolt: Kombimodus ala 32Bit Counter. Stimmt, beim AVR128DA kann man 2 Timer zusammenschalten. Jetzt bin ich echt am überlegen mir ein Testboard zu kaufen oder alles mit einem "normalen" ATmega zu lösen. :-) Und schon hat man mit einem Schlag Luxuxprobleme. :-) Danke für den Tipp. Edit: okay, man muss sicherlich nicht 2 Timer zwingend zusammenschalten und kann den OVF einzeln verwenden. Beim AVR128DD werden dann sicherlich die Prescaler nachgereicht. :-)
:
Bearbeitet durch User
S. Landolt schrieb: > Vielleicht sehen Sie auf dieser Seite mehr als wir. Nö. Aber jetzt sehe ich, dass meine Frage berechtigt war. Es gibt da tatsächlich diesen eklatanten Unterschied zwischen Mega0 und AVR128. Sollte man also die Konsequenz draus ziehen: nicht Mega0 sondern AVR128 benutzen, wenn man TCB mit OVF-Int braucht oder zu brauchen meint. Was mich viel mehr interessiert: warum gibt's den OVF beim Mega0 nicht? Dafür muß es doch einen Grund geben, der Timer selber kann nicht das Problem sein, denn beim AVR128 hat er den. Entweder kaputtes Silizium oder irgendein Problem im Zshg. mit der Verwaltung der Interrupts, möglicherweise auch der Events. Das herauszufinden ist das eigentlich Spannende, das, was ggf. wieder etwas über die Archtektur lehrt, was nicht im DB steht. Denn: nihil sine causa fit. Auch nicht das "Verschwinden" einer offensichtlich prinziell verfügbaren Interruptquelle in so eng verwandten Devices...
Veit D. schrieb: > Was mir gerade beim schreiben einfällt wäre, TCA im Event-Mode "Count > while event signal is high" zu betreiben. Das zu messende Eingangssignal > außen nicht nur TCBn sondern auch TCA0 zuführen. Nachteil, man kann > somit nur ein Signal messen. Ich möchte 2 messen. Hätte also zwei TCBn > verwendet. Bevor mich jemand für bekloppt hält. Hier gabs Gedankensalat-Overload. Wenn man so mit TCA die Länge vom Highpegel misst braucht man natürlich nicht noch extra TCBn dazu. Wäre sinnfrei. :-) :-) @ c-hater: Du meinst der TCBn OVF Interrupt existiert beim megaAVR0 heimlich still und leise im Untergrund? Dazu brauchst noch den Interrupt Vector. Nur bedenke, selbst wenn du das Headerfile etc. modifizierst, kann das vielleicht mit viel viel Glück bei einem Exemplar funktionieren und beim Nächsten nicht. Ist ja nicht spezifiert - der OVF beim megaAVR0. Für den Zeitvertreib sicherlich interessant, rein praktisch aus meiner Sicht ohne Nutzen. Das wird von Euch auch sicherlich niemand in Serie betreiben wollen. :-)
Zwischenfrage. Die AVR128DA gibts ja schon zu kaufen. Nur das Manual ist noch nicht Final. Hat "Preliminary" Status. Sind die Teile schon richtig Final fertig oder verkaufen die Vorserienware? Danke.
> OVF ... Dazu brauchst noch den Interrupt Vector.
Da gerate ich nun in Zweifel - wenn ich das AVR128DA28def.inc-File
richtig lese, gibt es nur den einen Vektor:1 | ; TCB0 interrupt vectors |
2 | .equ TCB0_INT_vect = 0x0018 ; |
Veit D. schrieb: > Du meinst der TCBn OVF Interrupt existiert beim megaAVR0 heimlich still > und leise im Untergrund? Nein, das eher nicht. Die Frage ist: warum nicht? Denkbar wäre immerhin, das zwar der Interrupt nicht existiert (zumindest nicht in brauchbarer Form), aber vielleicht doch das Flag! Das könnte ggf. durchaus hilfreich sein, oder? > vielleicht mit viel viel Glück bei einem Exemplar funktionieren Nönö, wenn du meinst, TCB mit OVF zu brauchen, dann nimm einfach AVR128, wo das offiziell dokumentiert ist. Das hatte ich auch bereits explizit geschrieben.
> richtig Final fertig
Gibt's nicht, irgendwas bleibt immer. Für Näheres siehe die Errata.
Veit D. schrieb: > Zwischenfrage. Die AVR128DA gibts ja schon zu kaufen. Nur das Manual ist > noch nicht Final. Hat "Preliminary" Status. Sind die Teile schon richtig > Final fertig oder verkaufen die Vorserienware? Danke. Ich würd's mal so ausdrücken: Das ist (wie bei praktisch allen heutigen µC) Vorserienware, aus der nie eine fehlerfreie Serie wird. Bestenfalls werden die "most annoying bugs" irgendwann gefixt.Oder auch nur die Doku so angepaßt, dass es kein Bugs mehr sind... Nur dann, wenn sich ein wirklicher Showstopper-Bug in der Vorserie herausstellt, dann besteht ein Chance, dass das Projekt komplett eingestampft wird... Business as usual...
Veit D. schrieb: > eigentlich rede ich über den "Capture Pulse-Width Measurement Mode". > :-) OK, gut, dann weiß ich, warum wir aneinander vorbei geredet haben. Als allgemeiner Timer taugt er ja im Periodic Interrupt Mode, aber für deinen Zweck nicht. Veit D. schrieb: > Nur das Manual ist noch nicht Final. Hat "Preliminary" Status. Das war lange Zeit bei Atmel usus, direct von "preliminary" nach "obsolete" … Weiß nicht, inwiefern Microchip das anders handhabt. c-hater schrieb: > Die Frage ist: warum nicht? Weil bestimmte Sachen eben zuweilen als Kunden-Feedback auf die Vorgängerversionen auch mal nachgerüstet werden. So wie bei den alten AVRs der CTC-Modus.
Veit D. schrieb: > Wenn wenigstens ein TCBn Overflow Interrupt vorhanden wäre Schau mal hier rein: Table 21-6. Interrupt Sources Set Conditions by Counter Mode Einfach nur den entsprechenden Mode auswählen.
Hallo, der TCBn hat nur einen einzigen Interrupt, den Capture Interrupt. Der löst je nach Modi verschieden aus, ist jedoch nie ein Overflow Interrupt. Der CAPT löst immer nur bei irgendeiner Flankenerkennung je nach Modi aus. Beim Zählerüberlauf löst er nicht aus. Selbst wenn würde einem das nicht helfen, man könnte nicht unterscheiden ob Überlauf oder die Signalflanke ausgelöst hat. Ich sehe zumindestens keine Möglichkeit.
Angehängte Dateien:
-
Interrupt_on_Top.png
13 KB
Veit D. schrieb: > ist jedoch nie ein Overflow > Interrupt. Obige Tabelle sagt was anderes.
Hallo, die Tabelle sagt nichts anderes. Top ist nicht Max. Top stellt man in den von dir gezeigten Modi selbst ein. Schau dir einmal bitte dazu die Diagramme an wann der Capt Interrupt auslöst.
Hallo, wusstest ihr das es die DB Serie schon zu kaufen gibt? Ein nochmals aufgebohrter DA. Auch das Errata liest sich etwas angenehmer, finde ich. Da werde ich gleich einen DB nehmen statt DA. :-) Curiosity Nano gibts auch schon. Ist alles noch bissel versteckt auf der Microchip Seite. https://www.microchip.com/Developmenttools/ProductDetails/EV35L43A
> Auch das Errata liest sich etwas angenehmer
Dann hoffen wir mal, dass der Inhalt dieser Datei zuverlässiger ist als
ihr Name.
Hallo, ich kann nur hoffen, ich habe keine Ahnung wie zuverlässig oder unzuverlässig Microchip ist. Ich habe nur mitbekommen das sich die Manuals im Vergleich zu den Atmel Manuals etwas schlechter lesen lassen. Tabellen und Bezeichnungen wurden verschlimmbessert, wenn ich dabei an einen Atmega328P oder ATmega2560 denke. Beim megaAVR0 gehts wieder. Übrigens ist ein Free Shipping Code "MCHPWELCOME" für ein Curiosity Nano Board gültig.
:
Bearbeitet durch User
Danke für die 6.15 € Ersparnis. Dass aber Microchip die AVR128DB28-I/SP erst im Dezember liefern kann ... - und dazu passt dann der Name der Errata-Datei (auf den ich mich bezog): "AVR64DB28..."; also etwas mehr Ruhe (und Sorgfalt) wäre angebracht.
S. Landolt schrieb: > also etwas mehr Ruhe (und Sorgfalt) wäre angebracht. Das ist ziemlich großkotzig, sorry. Selbstverständlich ist es das Ziel einer jeden IC-Entwicklung, einen fehlerfreien IC zu liefern. Selbstverständlich tut man im Vorfeld alles für dieses Ziel, die "Ruhe und Sorgfalt" äußert sich in einem (initialen) Entwicklungszyklus von 2 … 3 Jahren. Trotzdem passieren natürlich Fehler, die man dann erst am fertigen Silizium merkt. Dann ist es immer eine Abwägung: wie (un)wichtig ist der Fehler, kann man den Chip auch so schon bestimmungsgemäß verwenden? Welcher Aufwand ist für die Reparatur nötig, kann man einen Patch nur mithilfe der oberen Metall-Lagen bauen, oder braucht es eine "full layer revision"? Ein "metal fix" schlägt mit vielleicht einem halben Jahr und einer sechsstelligen Summe ein, eine full layer rev braucht bei beidem nochmal mehr.
:
Bearbeitet durch Moderator
> Das ist ziemlich großkotzig, sorry.
Nein, ich entschuldige nicht. Die Erläuterung wäre auch ohne diesen
verbalen Ausrutscher angekommen.
Im Übrigen bezog ich mich darauf, dass das offenbar AVR128 und AVR64
vermischt wurde.
S. Landolt schrieb: > dass das offenbar AVR128 und AVR64 vermischt wurde Du meinst, PDF-Titel des Dokuments? (Überschrift und Dateiname stimmen.) Das ist leider ein gängiges Problem, wenn man mit Word arbeitet und die Kopie von einem Dokument auf das nächste macht (vermutlich hat der AVR64DBxxx einfach die gleichen Bugs, weil's der gleiche Chip ist). Aber OK, das könnte schon mal irgendwo jemandem beim Marketing auffallen, bevor man es freigibt.
> ... Ruhe (und Sorgfalt) ...
Ohne weiteren Kommentar:
Gestern wurden mir von Microchip die AVR128DB28-I/SP 'acknowledged' und
'scheduled' mit "Estimated Ship Date 03-Dec-2020", heute wurde
"06-Mar-2021" daraus.
Dann ist wohl bei der Verifikation noch ein Showstopper hochgekommen. :/
Es gibt eine Möglichkeit, den Überlauf zu detektieren, vielleicht nicht ganz sauber. Später mehr. Diese Diskussion ist schon ziemlich alt, aber ich bin bei meiner aktuellen Suche nach Verständnis über den 4809 auch hier hängen geblieben, um erstmal zu der Erkennnis zu gelangen, das der overflow interrupt bei TCB tatsächlich fehlt. Und das tut er, er fehlt ganz gewaltig! Ich habe allerding einen Weg ersonnen, dass Problem zu überwinden. Ist vielleicht nicht elegant, vielleicht sogar nicht ganz sauber, aber zumindest für meine Anwendung funktioniert es. Aufhänger war eine Anwendung, bei der ich die zeitliche Auflösung in TCB von prescaler 1 max 2 brauche, aber der 16 bit counter in einigen Fällen z.T. sogar mehrere Male überläuft. Gelöst habe ich es, in dem ich im Hauptprogramm den counter beobachte und mit der letzten Beobachtung vergleiche. Wenn der counter kleiner als die letzte Beobachtung ist und zwischenzeitlich kein capture ausgelöst wurde, dann gab es offensichtlich einen Überlauf. Und wenn es einen capture gab, dann bleibt noch zu prüfen, ob es zwischen der letzten Beobachtung und dem capture einen Überlauf gab. Das Kriterium dafür ist, dass die letzte counter Beobachtung größer als der capture Wert ist. Wie gesagt. bestimmt nicht elegant, ich bin auch nichht 100% sicher in Bezug auf die Zuverlässigkeit. Es wird sicher davon abhängen, wie häfig man den TBC überhaupt beobachten kann. Aber bei mir funktionoiert es gut.
So richtig einzusehen ist nicht, warum man heutzutage überhaupt noch unterschiedliche Timer implementiert. Das macht doch die Programmierung nur unnötig umständlich. Die paar Transistoren mehr, um alle Timer gleich auszurüsten, sollten doch keine Rolle spielen. Es hat mich schon bei den standard AVRs geärgert, warum jeder ATtiny unterschiedliche Timer T1 hatte (ATtiny25, ATtiny24, ATtiny261). Will man beim TCB einen Overflowinterrupt, muß man eben TOP = MAX setzen. Warum beim TCB die Anzahl der Interruptvektoren so kastriert wurde, weiß der Geier. Sogar die T0, T2 bei den alten AVRs hatten mehr.
@ Fiso: Gute Idee. So ähnlich hat das Peter in seiner sicheren Überlaufauswertung schon gezeigt für alte AVRs inkl. Interruptflag. Der Knackpunkt ist, du müßtest noch analysieren wie der Zählerstand just am Überlaufpunkt ausgewertet wird. Gab es einen Überlauf in dem Moment oder eben genau noch nicht. Sonst hätte man einen kompletten Überlauf zu wenig oder zuviel addiert. @ all: Darum und andere Gründe habe ich auf den AVRxDBx gewechselt. TCB mit getrennten Interrupts vorhanden und es sind 2 kaskadierbar zu 32Bit, wenn man es nicht in Software machen möchte. Man kann übrigens alle "Messmodi" kaskadieren, auch wenn das nicht so im Manual steht. Microchip hatte mir gesagt das sie das im nächsten Manual ändern/ergänzen wollen.
Beitrag #6942249 wurde von einem Moderator gelöscht.
Hallo, der Modi macht genau das was sein Name sagt. :-) Aber ja, man hätte bestimmt noch den WO verfügbar machen können, ist Schade. Aber vielleicht kann man das hinbekommen mit einem anderen Modi. Beim Arduino Nano Every (Atmega4809) bei dem ja nicht alle Pins rausgeführt sind, habe ich mittels Eventsystem alle Logik Pins nach außen führen können. Damit sind die LUTs komplett nutzbar. Mit dem Timeout Mode habe ich schon ein Taktsignal erzeugt. Allerdings noch mit einem externen verlegten Draht für das erneute Startsignal. Vielleicht kann man das auch noch übers Eventsystem intern zuführen. So als Anregung vielleicht.
> ... WO verfügbar ... Aber vielleicht kann man das > hinbekommen mit einem anderen Modi. Event & CCL
Hallo,
zur Info für alle Threadleserquereinsteiger. Es ging um den TCB Periodic
Interrupt Mode womit kein WO Pin konfigurierbar ist.
> Event & CCL
Danke. Muss ich mir mal überlegen. Bin zur Zeit noch an was anderem
längere Zeit beschäftigt. Merke ich aber vor.
> Merke ich aber vor.
Es geht auch mit einem zweiten TCB, falls man einen übrig hat.
Andernfalls wie gesagt CCL, sofern dort ein Block frei ist - ich hatte
vor kurzem (wegen eines anderen Threads) eine Konstruktion mit
D-Flip-Flop sowie JK-Flip-Flop ausprobiert. Ist zwar ausgesprochen
umständlich, aber wenigstens eine Lösung; mir fiel nichts Besseres ein.
Hallo, solche Knobelaufgaben sind doch was Feines. Zudem alles onChip ist. :-)
Okay - war meine erste halbwegs sinnvolle Beschäftigung mit CCL. Einerseits. Andererseits wäre die bessere Lösung gewesen, wenn bei MicroChip beim TCB etwas weiter gedacht worden wäre.
Moin zusammen! Veit D. schrieb: > Der > Knackpunkt ist, du müßtest noch analysieren wie der Zählerstand just am > Überlaufpunkt ausgewertet wird. Gab es einen Überlauf in dem Moment oder > eben genau noch nicht. Da hast Du wahrscheinlich einen wunden Punkt in meiner Idee gefunden. Allerdings habe ich den Fehler in meine Logik noch nicht so ganz durchdrungen: Wenn ich häufig genug den Zähler beoabachte, während kein capture erfolgt (ich messe Frequnz mit dem TCB), dann müsst ich doch jeden Überlauf durch das Kriterium - alter beobachteter Zählerstand ist größer als der aktuelle - sicher entdecken. Oder? Und im Falle vom capture muss ich überprüfen, ob der erfasste period Wert kleiner als die letzte Beobachtung ist, dann hat es auch noch einen Überlauf zwischen der letzten Beobachtung und dem capture gegeben. So weit die Theorie. In der Praxis habe ich hinweise, dass es nicht jedes mal sicher klappt. Ich verstehe aber noch nicht, warum. Du scheinst etwas zu wissen, was ich noch nicht verstanden habe. Was soll kritisch daran sein, nahe dem Überlauf zu beobachten? Entweder bin ich noch vor dem Überlauf oder dahinter. Ich sehe noch nicht, wo das meine Logik in Schwierigkeiten bringt. Aber irgendwas ist da ... Vielleicht auch ein andere Fehler in meiner Impementierung. Ich suche noch.
Hallo, das ist der/mein Thread der mir gestern in den Sinn kam. Beitrag "Timer Overflow Counter - Wie richtig berücksichtigen?" Auch Link drin von Peter beachten. Ich weiß noch nicht ob das bei deiner Software Variante auch zutrifft. Musst du im Detail durchgehen. Weil man kann nicht mehrere Zähler exakt zur selben Zeit auslesen, geht ja nur nacheinander. Ist nur so ein Gedanke was vielleicht sehr selten schief laufen könnte, muss aber geklärt werden ob das zutrifft.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.