Hallo, ich habe eine Anwendung mit einem ATtiny45, der folgendes "Stupides" macht bzw. machen soll: 1. Analogspannungen mit ADC messen 2. Mittelwert aus mehreren Messungen bilden 3. Den Mittelwert mit einem Faktor multiplizieren und ein Offset abziehen (lineare Gleichung als Übertragungsfunktion) 4.diesen Wert als 8Bit-PWM ausgeben (OCR-Register beschreiben) --> wieder zu 1. Der Timer läuft als "Phase Correct". Das funktioniert soweit, aber ab und zu (<< 1% der Messungen) habe ich "Spitzen" in der PWM-Ausgabe, wo das Tastverhältnis entweder 0 oder 255 ist. Das Analogsignal ist aber während dieser Zeit sehr sauber, es können also keine Störspitzen sein. Ein Variablenüberlauf kann es meiner Meinung nach nicht sein, denn die Spitzen treten auch bei Messwerten auf, die sowohl vom ADC, als auch bei der auszugebenden PWM "schön" in der Mitte liegen. Falls der errechnete OCR-Wert doch mal größer ist, wird er auf 255 begrenzt. Dann kam mir in den Sinn, dass alle 16ms Sprünge in die Timer-ISR stattfinden. Das könnte ja unglücklicherweise genau dann stattfinden, wenn das erste Byte des ADC-Registers bereits ausgelesen ist, das zweite aber noch nicht. Dann springt er in die ISR. Wenn er aber dann wieder zurückspringt, steht im zweiten Byte möglicherweise schon etwas anderes drin. Das, was ich dann folglich in meiner 16Bit-Variable habe, ist dann natürlich Müll. Habe dann zum Auslesen des ADCs die Interrupts gesperrt, sodass atomarer Variablenzugriff gewährleistet ist. Ich dachte, damit wäre das Problem behoben... Pustekuchen. Das Problem besteht immer noch. Wie kann ich herausfinden, wo der Hund begraben ist? Ich könnte z.B. die errechneten OCR-Werte analysieren und wenn sie im Vergleich zum vorherigen Wert um so und soviel Prozent abweichen, sämtliche verdächtige Variablen in einem Array speichern. Anschließend kann ich die Variablen dann analysieren (über DebugWire). Hat jemand noch ein paar Tipps, was ich überprüfen könnte? Die AVR-Checkliste habe ich bereits abgearbeitet. Eine grundsätzliche Frage: Darf ich eigentlich das OCR-Register zu jedem beliebigen Zeitpunkt beschreiben, ohne dass irgendwelche Glitches die Folge sind? Zumindest wird Timer0 im Datenblatt mit "Glitch Free, Phase Correct Pulse Width Modulator (PWM)" beworben. Danke. Third-Eye
> Wie kann ich herausfinden, wo der Hund begraben ist? Der meiner Meinung nach wichtigste Punkt ist es, sich selbst eine Möglichkeit zu schaffen, wie man Werte aus dem System rauskriegt. Ob das ein LCD oder eine UART ist, ist dabei erst mal nicht so wichtig. Wichtig ist, dass man aus dem Status "Stochern im Nebel" rauskommt. Persönlich halte ich es von einem Neuling für leichtsinnig, eine Schaltung in der Version 0.9 zu entwerfen, die keinerlei Möglichkeiten vorsieht (und sei es nur mit einer Huckepack-Platine, die zb mit einem MAX232 zwischenzeitlich an die TxD angeklemmt wird), Werte aus dem System rauszukriegen. > Darf ich eigentlich das OCR-Register zu jedem beliebigen Zeitpunkt beschreiben, Das kommt auf den Modus an. Im Datenblatt deines Prozessors gibt es im Timer-Abschnitt "Register Description" (oder Register Summary) eine Tabelle über alle Modi, die der Timer beherrscht. In dieser Tabelle ist auch angegeben, wenn genau der Update des OCR Registers erfolgt. Wenn da TOP (oder BOTTOM) steht, dann kannst du dem OCR Register jederzeit was zuweisen. Die Hardware sorgst dann selbst dafür, dass das eigentliche OCR Register zu einem unkritischen Zeitpunkt den Update erhält. Steht da aber 'Immediate', also 'sofort', dann hast du ein Problem.
Third Eye schrieb: > Ein Variablenüberlauf kann es meiner Meinung nach nicht sein Das würde ich nicht mit irgendeiner "Meinung" vertreten, sondern einfach mal glashart ausrechnen. Wir sind hier nicht in der Politik oder der Kirche, hier zählen beweisbare Fakten. Und das sind: wieviele Bits liefert die ADC, wieviele Samples addierst du für die Mittelwertbildung auf, mit welchem Faktor multiplizierst du den Mittelwert, welchen Osset addierst du? Ganze vier (für dich, aber nicht für uns) einfach ermittelbare Größen und man kann das problemlos ausrechnen. > Dann kam mir in den Sinn, dass alle 16ms Sprünge in die Timer-ISR > stattfinden. Huch, was macht er denn in dieser ISR? Ich sehe in deiner Funktionsbeschreibung nämlich absolut nichts, was eine solche überhaupt erfordern würde... > Eine grundsätzliche Frage: Darf ich eigentlich das OCR-Register zu jedem > beliebigen Zeitpunkt beschreiben, ohne dass irgendwelche Glitches die > Folge sind? Den Timer0 ja, jedenfalls in allen PWM-Modi. Umso wahrscheinlicher ist ein Variablenüberlauf.
Wenn der PWM-Modus so steht, dass OCR IMMER aktualisiert wird, dann gibt es auch dieses Szenario: aktuelles OCR: 150 aktueller Timerwert: 100 dann neues OCR schreiben: 50 In diesem Fall läuft die PWM bis 255 --> 0 --> 50 durch. Ich kann mich auch irren, denn ich habe jetzt nicht ins Datenblatt geschaut. Also mal nachschauen, wann OCR übernommen wird und ggf. mal auf TOP stellen.
Hi >aktuelles OCR: 150 >aktueller Timerwert: 100 >dann neues OCR schreiben: 50 Geht aber so nicht. Das OC-Register wird dann upgedated wenn der Timer den Top-Wert erreicht hat und anfängt rückwärts zu zählen. MfG Spess
Danke für die Infos. Wie mir schon geraten wurde, werde ich die Vermutungen durch harte Fakten ersetzen. Ich verwende keinen Modus, in dem "Update of OCRx at" auf "Immediate" steht. @ Karl Heinz: Ich verwende DebugWire. Ich bin in früheren Basteleien ganau aus dem von Dir genannten Grund schon ziemlich auf die Schnauze gefallen. Wenn man nur einen Pin als Ausgabemöglichkeit hat, den man ggf. toggeln kann, ist die Programmiererei seeehr nervtötend. Man lernt halt dazu ;-)
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.