Hallo mal wieder zusammen,
ich bin gerade dabei zu versuchen, die Taktquelle eines ATTiny88s mitten
im Code-Ablauf zu ändern. Also ist es relativ einfach, die Fuse Bits
beim Programmieren mit Atmel Studio oder jeglichen anderen Tools zu
setzen, und sogar im Code, wie in der fuse.h-Datei in den Kommentaren
erklärt, habe ich es schon hingekriegt, was allerdings nur beim
kompilieren ausgeführt wird und in der .elf-Datei eingefügt wird, also
nichts dass in Runtime was ändert.
Meine Frage ist, wie man vorgehen würde, wenn man eine externe
Taktquelle verwendet (Taktgeber, kein Quarz möglich bei diesem ATTiny),
und man überwachen möchte, ob sie noch vorhanden ist. Wenn aus jeglichem
Grund z.B. der externe Taktgeber nicht mehr funktioniert und man das
sofort erkennen möchte und daraufhin auf den internen RC-Oszillator
umstellen will: wie geht man vor? Ist das überhaupt möglich?
Ich weiss, dass laut Datenblatt die Fuse Bits nur im Programmiermodus
gesetzt werden können, die Frage in diesem Fall wäre: kann man durch die
Selbstprogrammierfunktion (unter Verwendung von "SELFPRGEN" o.ä.) diesen
Zustand einleiten und die entsprechende FUSE-Einstellungen durchführen?
Oder gibt es einen einfacheren Weg, die Taktquelle in einem solchen
Fehlerfall zu ändern? I.e. eine Library die ich übersehen habe?
Hier der Code zu den Fuse-Einstellungen, die nur in der .elf-Datei beim
kompilieren eingefügt werden und nicht für Änderungen im Code geeignet
sind (interne Taktquelle usw. eingestellt):
dieser "Fehlerfall" wir in der Praxis nie vorkommen.
Wenn der interne RC reicht(Stabilität, Frequenz) , kann man ihn doch
gleich von Anfang an verwenden , oder?
Marc O. schrieb:> Oder gibt es einen einfacheren Weg, die Taktquelle in einem solchen> Fehlerfall zu ändern?
ja, steht im Datenblatt. Geht aber nicht mit SELFPRGEN.
Hi
>kann man durch die>Selbstprogrammierfunktion (unter Verwendung von "SELFPRGEN" o.ä.) diesen>Zustand einleiten und die entsprechende FUSE-Einstellungen durchführen?
Nein. Fusebits können nur gelesen werden.
MfG Spess
Wie sollte das denn überhaupt funktionieren können?
Dein AVR läuft mit externem Takt. Sobald der Takt fehlt, wird der
interne Oszillator angeschaltet. Um den internen Oszillator anzuschalten
(oder überhaupt nur den nächsten Befehl abzuarbeiten) brauchst Du einen
Takt.
Woher kommt der ? Vom Fallback-externen Taktgenerator?
Peter II schrieb:> Marc O. schrieb:>> Oder gibt es einen einfacheren Weg, die Taktquelle in einem solchen>> Fehlerfall zu ändern?>> ja, steht im Datenblatt. Geht aber nicht mit SELFPRGEN.
Wo genau? Ausser mit den CKSEL Fuse Bits, die wie gesagt laut Datenblatt
nur im Programmiermodus gesetzt werden können, sehe ich keine
Möglichkeit. Den Programmiermodus mitten im Code-Ablauf herbeizurufen
habe ich noch nicht hingekriegt. Wäre man so nett, auf den Abschnitt des
Datenblatts hinzuweisen, wo das beschrieben ist? Der Beitrag von Spess
scheint das zu unterstützen, wovor ich mich fürchte:
spess53 schrieb:> Nein. Fusebits können nur gelesen werden.
Und bzgl. der Antwort:
PeterL schrieb:> dieser "Fehlerfall" wir in der Praxis nie vorkommen.> Wenn der interne RC reicht(Stabilität, Frequenz) , kann man ihn doch> gleich von Anfang an verwenden , oder?
Ich habe eine Kommunikationsschnittstelle, die aufgrund der bestenfalls
mit Kalibrierung erreichbare 1%-Genauigkeit des internen RC oft genug
aus den Schienen gerät. Und es gibt gute Gründe, aus denen mir die
Umstellung zwischen Taktquellen sehr nützlich wäre. Der Fehlerfall kann
bei mir nämlich durchaus auftreten.
Martin L. schrieb:> Wie sollte das denn überhaupt funktionieren können?> Dein AVR läuft mit externem Takt. Sobald der Takt fehlt, wird der> interne Oszillator angeschaltet. Um den internen Oszillator anzuschalten> (oder überhaupt nur den nächsten Befehl abzuarbeiten) brauchst Du einen> Takt.> Woher kommt der ? Vom Fallback-externen Taktgenerator?
Ich dachte man könnte vllt. einen Übergangszustand bzw.
"Fast-Failure"-Zustand der Taktquelle detektieren, so was ähnliches wie
ein Brown-Out der Versorgung. Ich geh gerne immer davon aus, es gibt
etwas, das ich noch nicht kenne =)
Hallo,
beim XMega kannst du die Taktquelle auch per Software umschalten - nützt
für deinen Fall auber auch nichts, denn wie schon gesagt muss der
Controller ja noch laufen um die Umschaltung auszuführen.
Was du noch machen kannst währe eine automatische Korrektur des RC-Osc.
über das OSCCAL-Register anhand eines externen Taktsignals. Dazu wirst
du allerdings einen freien Timer brauchen.
Sascha
Sascha W. schrieb:> Was du noch machen kannst währe eine automatische Korrektur des RC-Osc.> über das OSCCAL-Register anhand eines externen Taktsignals. Dazu wirst> du allerdings einen freien Timer brauchen.
Naja, grade mit einer langsmen externen Quelle kommt man zur Not mit ner
Zählschleife (währenddessen UNBEDINGT Interrupts ausschalten) aus
handgezählten assembler-befehlen über die runden.
Sascha W. schrieb:> Was du noch machen kannst währe eine automatische Korrektur des RC-Osc.> über das OSCCAL-Register anhand eines externen Taktsignals. Dazu wirst> du allerdings einen freien Timer brauchen.Max D. schrieb:> Zählschleife (währenddessen UNBEDINGT Interrupts ausschalten) aus> handgezählten assembler-befehlen über die runden.
Die interne Oszillator-Kalibrierung durch den OSCCAL mit einer externen
PWM-Welle habe ich schon erfolgreich implementiert. Die damit
erreichbare Genauigkeit ist trotzdem nicht genug für meine Anwendung.
Ich habe Gründe, wie schon gesagt, den internen RC ersetzen zu wollen,
und die Quelle trotzdem mal ändern zu wollen, falls möglich. Siehe
hierzu
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment#Erg.C3.A4nzende_Hinweise_zur_Taktversorgung_.28kann_.C3.BCbersprungen_werden.29
Spess hat schon gesagt, die Fuse Bits können einfach nicht ohne
Programmiermodus geändert werden, wie ich befürchtet habe. Ausser es
kennt jemand doch eine Lösung. Dann wäre sie willkommen. Ansonsten
trotzdem danke für eure Zeit.
Ulrich F. schrieb:> Oh...> Da hätte ich was für dich: Das Datenblatt.
Ich frage in Mikrocontroller.net, weil das Datenblatt nichts anderes
mehr liefert, ausser dem, was schon geschrieben wurde: Fuse Bits können
nur im Programmiermodus manipuliert werden. Das erlaubt keine dynamische
Änderung der Taktquelle ohne externen ISP-Programmer o.ä., wie im
idealen Fall, den ich mir vorstelle. Datenblatt lesen kann ich seit
langer Zeit. Apropos Bedarf nach Heilen von schwachen Egos gibt es
übrigens bessere Mittel, als in Elektrnik-Foren ohne richtiges
Durchlesen der Beiträge zu klugsch** =)
Marc O. schrieb:> Datenblatt lesen kann ich seit> langer Zeit.
Vortrefflich!
Dann ist dir ja klar, dass es nicht so geht, wie du dir das erträumst.
Oder glaubst du dem Datenblatt nicht?
Woher sollten wir mehr wissen, als da drin steht?
Marc O. schrieb:> klugsch**
Jagut....
Du kannst den Takt mit einer PLL Schaltung vorgeben, die mit der
ausfallträchtigen Taktquelle synchronisiert wird.
Wenn diese ausfällt, läuft die PLL Schaltung auf ihrer (eventuell
weniger genauen) Frequenz weiter.
Allerdings: Wenn man so einen Aufwand betreibt, kann man gleich einen
externen Quarzoszillator verwenden.
Marc O. schrieb:> Der Fehlerfall kann bei mir nämlich durchaus auftreten.
Dann ist dein Konzept aber nicht unbedingt überragend.
Warum nimmst du keinen Atmega88 mit Quarz?
mfg.
STM32 können ihre Taktquelle während der Laufzeit umschalten, und sogar
vollautomatisch auf den internen RC Oszillazor umschalten wenn der
externe versagt.
Programmierer schrieb:> STM32 können ihre Taktquelle während der Laufzeit umschalten, und> sogar> vollautomatisch auf den internen RC Oszillazor umschalten wenn der> externe versagt.
Das ist ja schön, wenn der das kann. Hier ging es aber um einen ATtiny!
Stefan U. schrieb:> Du kannst den Takt mit einer PLL Schaltung vorgeben, die mit der> ausfallträchtigen Taktquelle synchronisiert wird.> Wenn diese ausfällt, läuft die PLL Schaltung auf ihrer (eventuell> weniger genauen) Frequenz weiter.
Und wenn die PLL ausfällt hast du was genau gewonnen?
> Spess hat schon gesagt, die Fuse Bits können einfach nicht ohne> Programmiermodus geändert werden, wie ich befürchtet habe. Ausser es> kennt jemand doch eine Lösung. Dann wäre sie willkommen. Ansonsten> trotzdem danke für eure Zeit.
Andere Architektur verwenden! PICs können es, viele ARMs können es,
einige 8051-Derivate (nicht die von Atmel...) können es auch.
Das Umschalten zwischen verschiedenen Taktquellen ist nicht trivial,
weil es glitchfree erfolgen muss. Soll heißen: Auch im Zeitpunkt des
Umschaltens darf die minimale High- und/oder Low-Zeit des Taktsignals
nicht unterschritten werden. Atmel hat sich diese Logik eben gespart.
Marc O. schrieb:> Ich dachte man könnte vllt. einen Übergangszustand bzw.> "Fast-Failure"-Zustand der Taktquelle detektieren
Wie soll das denn gehen? Begreife: Messen heißt vergleichen! Womit
bitteschön soll der Takt verglichen werden, um eine Abweichung vom Soll
feststellen zu können? Du hast doch keinen anderen Takt, mit dem du
vergleichen könntest. Und hättest du einen, brächtest du die äußere
Taktquelle erst garnicht...
Formale Logik ist nicht deine starke Seite, stimmt's?
> so was ähnliches wie> ein Brown-Out der Versorgung.
Der BOD vergleicht mit einer internen Spannungsreferenz. Deswegen kann
das funktionieren.
> Ich geh gerne immer davon aus, es gibt> etwas, das ich noch nicht kenne =)
Gibt es: Laß' das Teil einfach immer mit dem internen Taktgeber laufen
und benutze den externen Oszillator als Referenz, um den internen
Oszillator regelmäßig nachzujustieren.
Mit einer Plausibilitätsprüfung der Messergebnisse ist die Sache dann
sogar gegen den (Total-) Ausfall des externen Oszillators gesichert.
Natürlich wird aber vom Moment dieses Ausfalls an die interne Taktquelle
nicht mehr nachjustiert und bei einer nachfolgenden signifikanten
Temperaturänderung ist dann doch wieder Ende Gelände für deine UART.
D.h.: Im Prinzip hast du selbst mit mit diesem ganzen Aufwand bezüglich
der Ausfallsicherheit fast nix gewonnen. Nur die Möglichkeit, den
Ausfall der Referenztaktquelle melden zu können. Was aber nur dann etwas
bringt, wenn irgendwer diese Meldung zu sehen bekommt und dann den
Wechsel der externen Taktreferenz in die Wege leitet...
Deswegen ist folgendes viel besser:
Man macht sich die Tatsache der Kommunikation über UART an sich zunutze
und benutzt diese selber als Referenztaktquelle zum Justieren des
internen Taktgebers. Dazu muß man sich bloß ein primitives Protokoll zur
Kommunikation ausdenken, was neben der Nutzkommunikation die regelmäßige
Aussendung von vereinbarten (und geeigneten) Sync-Pattern beinhaltet.
Bei 8N1 z.B. wäre eine Mindest-Sendepause von 20 Bitlängen, gefolgt von
einem "dicht" gesendeten Burst von z.B. 16 großen "U"s, wiederum gefolgt
von einer 20Bit-Mindest-Sendepause ein hervorragendes Synchron-Pattern.
Darauf kann sich selbst ein mit internem Takt betriebener Controller
sofort neu synchronisieren, der einem 100K-Temperaturschock unterworfen
wurde.
Bei geringeren Anforderungen kann man natürlich das Synchronpattern
deutlich verkürzen oder sogar ganz darauf verzichten und einfach die
normale Kommunikation als Referenz verwenden. Dann dauert es aber
deutlich länger, bis ein vollkommen aus dem Tritt gekommener Client
wieder synchron ist. Und bei extrem ungünstigen Komunikationsinhalten
könnte es sogar passieren, daß er überhaupt nicht mehr "einrastet".
Und letztlich kann man beide Ansätze auch kombinieren: Ständige
Feinjustierung anhand der normalen Kommunikation und das Synchronpattern
gibt's nur dann, wenn der Master von irgendwem keine verständliche
Antwort mehr bekommt.
Frank K. schrieb:> Andere Architektur verwenden!
Auch Xmegas können es, war aber eben hier nicht gefragt.
Automatischen Fallback haben viele ARMs, auch die von Atmel. Braucht
logischerweise Hardware zur Überwachung. Könnte man genauso gut mit
ein wenig diskreter Mimik aufsetzen.
c-hater schrieb:> Formale Logik ist nicht deine starke Seite, stimmt's?
Dass du den kleinen Sarkasmus unbedingt bringen musst, obwohl du weder
meinen Lebenslauf gesehen hast noch mich persönlich kennst, spricht
nicht gerade dafür dass du sehr objektiv und wissenschaftlich handelst
:) Und apropos Takt, das sollen auch Menschen haben, die nicht ihr
berufliches Leben in der Werkstatt verbringen möchten. Aber naja,
Bescheidenheit ist im Internet noch nicht angekommen.
Und darum geht es eben, offen fragen zu können. Wer weiß ob es nicht
doch ein Trick gegeben hätte? Fragen schadet nicht. Der, der glaubt, gut
genug zu sein, hat aufgehört besser zu werden.
Trotzdem danke für deine Zeit und für den ausführlichen Beitrag. Hat mir
weiter geholfen.
Eine Möglichkeit wurde noch nicht genannt: 2 Controller der eine
überwacht mittels Quarzoszillator deinen Spezialoszillator ob dieser
noch osszilliert und wenn nicht programmiert dieser deinen
Messcontroller auf den internen Oszillator um...
Jörg W. schrieb:> Marc O. schrieb:>> spricht nicht gerade dafür dass du sehr objektiv und wissenschaftlich>> handelst>> Das sagt doch schon sein Nickname aus.
Ich habe doch schon vor längerer Zeit aufgedeckt, dass c-hater gar nicht
existiert, sondern eine Verschwörung ist.
mfg.
Marc O. schrieb:> Dass du den kleinen Sarkasmus unbedingt bringen musst, obwohl du weder> meinen Lebenslauf gesehen hast noch mich persönlich kennst
Das ist ja gerade der Witz. Hast du schonmal was von einem
Beweisverfahren namens "vollständige Deduktion" gehört und es auch
verstanden?
Dann weisst du, warum ich diesen "kleinen Sarkasmus" bringen kann, ohne
über deinen Lebenslauf informiert zu sein oder dich jemals kennengelernt
zu haben. Weil die Informationen daraus zur Beurteilung des
Sachverhaltes schlicht irrelevant sind. Der ist aus den gegebenen
Informationen bereits eindeutig bestimmt oder gar überbestimmt.
> Trotzdem danke für deine Zeit und für den ausführlichen Beitrag. Hat mir> weiter geholfen.DAS ist doch mal etwas, was ich gern lese. Leute, die wenigstens noch
in der Lage sind, verstehen können, dass ich ihnen wirklich nur helfen
möchte...
Paul B. schrieb:> A. K. schrieb:>> Nö. Erklär mal.>> Er hält sich für Sherlock Holmes.> http://www.donaukurier.de/themen/blog/kinotv/Die-K...>> MfG Dr. Watson
Zitat:
„Sherlock antwortet immer. Auf alles!
Er ist die Schlagfertigkeit in Person.
Er wird Gott überleben,
nur damit er das letzte Wort haben kann."
Na das passt doch wie die Faust auf's Auge :-)
Hahahaha jetzt lach ich nur noch über die Arroganz des c-hater und über
die nachfolgenden Kommentare. Mit so Menschen hab ich beruflich bisher
nur im Kellergeschoss der Firma zu tun gehabt. Du kannst ein As der
Elektronik sein, Freundchen, aber dass du daraus schließt, jemand der
kein Elektronik Expert ist und mal in einem Forum eine Frage stellt, sei
zu formaler Logik unfähig, ist nun echt sehr ironisch, aber wenn du
meinst das kannst du doch draus schließen, dann naja, "ignorance is
bliss".
