Hallo zusammen,
ich hab mal wieder ein Problem.
Ich habe ein Programm auf meinem Mikrocontroller (PIC 16F648A) dass sich
nach einem Ablauf wiederholt.
Die Dauer dieses Ablaufs ist abhängig von den eingelesenen Werten (über
AD-Wandler).
Allerdings soll dieser nach einer immer gleichen Zeitkonstante
wiederholt werden.
Also dachte ich mir, ich nehme den Timer1 dafür und warte bis der
Überlauf (TMR1IF) gesetzt wird, um das Programm erneut zu wiederholen.
Das Problem, es läuft weiterhin zusätzlich in Abhängigkeit der
eingelesenen Werte.
Der Überlauf wird natürlich nach der Aktivierung auch zurück gesetzt.
Auch verschiedene Teilungen am Vorteiler (T1CKPS0, T1CKPS1) habe ich
ausprobiert. Das Programm selbst ist auch nicht zu lange.
Der Timer1 hat zwar schon eine Auswirkung auf die Dauer des
Programmablaufs, dennoch ist dieser noch zusätzlich Abhängig von den
eingelesenen Werten, obwohl dies laut meiner Auffassung nicht der Fall
sein sollte, da der Timer ja immer nach gleich vielen Takten überlaufen
sollte?
Oder habe ich einen Denkfehler?
Vielen Dank für eure Antworten
Gruß Philip
> Oder habe ich einen Denkfehler?
Zeig einfach den Quellcode. Und schreib nochmal ∗genau∗ auf, was Du
haben willst und was Du stattdessen bekommst, das obige ist leicht
verwirrend.
Ja, war vielleicht etwas kompliziert beschrieben, sorry.
Der Quellcode ist leider viel zu lange tut mir Leid ...
Ich versuche es mal einfacher zu beschreiben
Init
Timer1 Vorteiler = 4
1. Einlesen AD-Wandler
2. Werte des AD-Wandlers berechnen
3. Warten bis Timer1 überläuft
4. Überlauf löschen
5. Zurück zu Punkt1 springen
Laut meiner Auffassung sollte der Zyklus 1-5 immer gleich lang sein, da
der Timer1 immer nach 65535 Takten überläuft.
Das ist er aber nicht, er ändert sich Abhängig vom Vorteiler UND von den
eingelesenen- und zu berechneten Werten.
Philip schrieb:> Der Quellcode ist leider viel zu lange tut mir Leid ...
Schade. Man könnte den Quellcode kürzen oder aber lieber andere wühlen
lassen?!
Hallo,
der Timer läuft - wie schon von Dir beschrieben - nach 65536 x 4 Zyklen
über.
Dann wird TMR1IF gesetzt. Je nach OSC Takt kann man das jetzt in
Zeiteinheiten umrechnen (bei 4MHz wären das dann ca. 260ms - natürlich
nur, wenn TMR1H,TMR1L nicht anders vorbelegt werden).
An Deinem Ablauf kann ich mir zwei Probleme aus der Glaskugel ziehen:
1) Du hast ein BANK-Problem und schreibst einen falschen Wert ins
TMR1H/L- Register.
2) Deine ADC Routinen / Berechnungen dauern länger als 260ms (das geht
ganz schnell, wenn Du mit 32bit Floatingpoint Rechnungen ankommst - ES
LEBE C)
Abhilfe / Analyse:
Nimm mal den Simulator aus MPLAB und lasse den mal durchlaufen. Da
siehst Du dann ganz schnell, wo die Zeit geblieben ist / wo das
BANK-Problem auftaucht.
Alternativ: Du setzt/löschst einen unbenutzten Pin in jeder Teilroutine
und benutzt ein Oszi für die Auswertung.
Gruß
TK
Philip schrieb:> Das ist er aber nicht, er ändert sich Abhängig vom Vorteiler UND von den> eingelesenen- und zu berechneten Werten.
Das ist doch der Sinn eines Vorteilers:
Zeit = Quarz / Vorteiler / Timer
Code ausführen benötigt Zeit, insbesondere Division und Float.
Da Du keinerlei Angaben machst, kann man nur vermuten. Wenn der Timer
alle 10µs überlaufen soll, wirst Du dazwischen kaum Berechnungen machen
können.
Du mußt die Zeit so lang wählen, daß alle Berechnungen garantiert bis
zum nächsten Überlauf abgeschlossen sind.
Philip schrieb:> Das Programm selbst ist auch nicht zu lange.Philip schrieb:> Der Quellcode ist leider viel zu lange
Aha...
Wenn Du schon Deinen Code nicht posten willst, beschreibe doch
wenigstens mal, wie Du zu der Meinung kommst, daß das Programm nicht das
macht, was es soll. Irgendwie scheinst Du ja das Timing-Verhalten
messtechnisch zu erfassen (ich nehme an, Du sitzt nicht mit der Stopuhr
in der Hand und stopst manuell Millisekunden, bis eine LED aufblitzt).
Dasselbe Verfahren kann man sicher auch dazu nutzen, um das Programm zu
debuggen, wenn das Debugging mit Simulator oder Debugger-Hardware nicht
weiterführt.
Also, welches Timing-Verhalten erwartest Du von Deinem Programm genau
und was passiert dann tatsächlich?
Erstmal vielen Dank für eure Antworten.
Das Programm umfasst fast den kompletten Speicherinhalt des PICs, also
um die 4000 Befehle.
Ich bezweifle dass dies jemanden hier weiter geholfen hätte.
Aber ich habe es nun gelöst:
@Thomas Elger, die Messung erfolgte mit einem Oszilloskop ;)
Genau daran lag auch das Problem, die Triggerung auf ein PPM-Signal an
dem ich gemessen habe funktionierte nicht richtig.
Zudem habe ich zunächst die falsche PIR-Flag für den Überlauf gelöscht.
Die scheint von PIC zu PIC unterschiedlich zu sein.
Erst nachdem ich einen Ausgang zweckentfremdet habe, der mir die Zyklen
genau anzeigte, kam ich darauf.
Manchmal ist die Lösung ganz Simpel, aber wer misst misst Mist.
Danke nochmal
