hallo alle zusammen. ich programmiere ein programm für ein elektroauto. sitze gerade vor einem problem. ich lasse den timer 1 hochlaufen bis 256. bei compare wird interrupt ausgelöst wo ich einen fet ausschalte. nach diesem wird der timer 0 gestartet der nach 3 taktzyklen in den overflow springt und den anderen fet einschaltet. so. der timer 1 rennt natürlich weiter und sollte eigentlich bei 256 den overflow interrrupt auslösen. was er aber nicht macht, sondern wieder von oxFF anfängt runter zu laufen und dadurch entsteht hier das 2. mal das compare. und erst wenn er bei 0 ist wird der overflow interrupt ausgelöst. kann mir bitte jemand helfen warum er nicht einfach bis 256 läuft und dann wieder von 0 anfängt? habe fast pwm verwendet. danke im voraus!
1) Warum startest du für 3 taktzyklen einen zweiten Timer (Timer0)? IMHO ist es naheliegender innerhalb der ISR von Timer1 einfach drei NOP() zu verbraten, als den ganzen Overhead für einen zweiten Timer aufzubauen. 2) Warum benutzt du Fast-PWM und nicht den CTC-Modus?
1. ich fand es so einfacher, um die fets nicht gleichzeitig umzuschalten. 2. ctc hab ich nicht verwendet weil ich ja den overflow brauche
Durch die NOP() würdest du ja nicht gleichzeitig schalten.
1 | ISR(TIMER1_...) |
2 | {
|
3 | static uint8_t tick_tack = 0; |
4 | |
5 | tick_tack ^= 1; |
6 | if( tick_tack ) { |
7 | fet1_aus; |
8 | NOP(); |
9 | NOP(); |
10 | NOP(); |
11 | fet2_an; |
12 | } else { |
13 | fet2_aus; |
14 | NOP(); |
15 | NOP(); |
16 | NOP(); |
17 | fet1_an; |
18 | }
|
19 | }
|
In deinem Code gibt es übrigens mindestens ein Problem durch ein fehlendes volatile von t0_ch
>> ich lasse den timer 1 hochlaufen bis 256. > ISR(TIMER1_OVF_vect) Hat bei deinem AVR der Timer1 nur 8-Bit?
stimmt. das mit NOP find ich gut. danke ja ich verwende nur 8 bit. das problem ist bei mir immer noch, dass der timer 1 hochläuft, dann bei compare in den interrupt hüpft und anstatt bei overflow in den anderen interrupt hüpft, zählt er bis 0xFF rauf und dann von 0xFF wieder runter und dadurch kommt das compare 2 mal vor bevor überhaupt overflow interrupt ausgelöst wird. ich verstehe nicht warum ??
Jay Steve schrieb: > stimmt. das mit NOP find ich gut. danke > ja ich verwende nur 8 bit. das problem ist bei mir immer noch, dass der > timer 1 hochläuft, dann bei compare in den interrupt hüpft und anstatt > bei overflow in den anderen interrupt hüpft, zählt er bis 0xFF rauf und > dann von 0xFF wieder runter wie hast du diesen Teil festgestellt? Ich hab mir dein Programm angesehen und ich bin wie du der Meinung du hast da eine 8-Bit Fast PWM eingestellt. Und die kann nicht so zählen, wie du das beschreibst. Ich denke deine Symptomanalyse ist falsch.
ich habe es in der simulation im avr studio festgestellt. ich habe mal einfach einen wert 0xf0 für OCR1AL genommen. wenn der wert erreicht wird, hüpft er in den compare interrupt. dann hab ich einzelne schritte gemacht und gesehen, dass der timer bis 0xFF hinaufzählt. Und wenn er den wert erreicht, fängt er an wieder runter zu zählen anstatt wieder von 0 zu beginnen (was eigentlich gewünscht ist). bei 0xEF springt er wieder in den compare interrupt.
Wenn Timer1 ein 16-Bit Timer ist und du nur 8-Bit davon verwendest "ja ich verwende nur 8 bit", um den TIMER1_COMPA_vect zu bekommen, kannst du nicht erwarten, dass du auch den TIMER1_OVF_vect beim 16-Bit Überlauf bekommst. Beim Eintreten des TIMER1_COMPA_vect wird TCNT1 auf 0 zurückgesetzt. Das ist im CTC-Modus und bei Fast-PWM (= single slope) gleich. Und > und dann von 0xFF wieder runter kann ich nicht für Fast-PWM nachvollziehen, wenn ich z.B. ins Datenblatt des Atmega8 schaue. Schreib mal welchen AVR du verwendest, damit man sich das im Simulator ansehen kann.
atmega8. ja ich verstehe auch nicht warum er wieder runter zählt. darum auch meine frage
Jay Steve schrieb: > ich habe es in der simulation im avr studio festgestellt. Der Simulator hat so seine Schwächen :-)
Helfer schrieb: > Beim Eintreten des TIMER1_COMPA_vect wird TCNT1 auf 0 zurückgesetzt. Das > ist im CTC-Modus und bei Fast-PWM (= single slope) gleich. Und Äh. Nein Fast PWM: Der Timer zählt von 0 bis TOP. Im eingestellten Modus ist TOP immer 255 und hängt von nichts ab. Der Compare Match hat damit nichts zu tun. @TO Ich will mir allerdings ehrlich gesagt diesen Code so nicht weiter antun, weil mich dieses Wizard generierte Zeugs nervt. Hundertausend Initialisierungen, die keiner braucht. Die wichtigen Dinge als Zuweisung von Hex-Codes, bei jeder 3.ten Zeile müsste man im Datenblatt nachschlagen, was das jetzt wieder für Bits sind, die da umgesetzt werden, etc. Wenn du im Simulator dir die Timerkonfiguration ansiehst, stimmt die dann?
Ich hab auch noch nicht verstanden, warum du das so 'kompliziert' mit 2 Timern machst. Du hast doch auf dem Timer 1 2 PWM Kanäle, A und B An jeden Kanal kommt ein Fet, A wird auf normale PWM gestellt, B auf invertierte PWM. Du musst dann nur noch dafür sorgen, dass der Vergleichswert für B immer um mindestens deinen Zeitversatz höher ist. Das ist aber nicht so schwer sicherzustellen. Wenn sich der PWM Wert als ganzes erhöht, wird zuerst Compare B erhöht und erst dann Compare A; wird der PWM Wert niedriger, wird zuerst A erniedrigt und erst dann B. Schwups: Schon macht die Hardware alles von ganz alleine.
laut datenblatt habe stimmt meine initialisierung. ich kanns mir einfach nicht erklären warum er den phase correct pwm nimmt obwohl ich fast pwm eingestellt habe.
> Äh. Nein > > Fast PWM: > Der Timer zählt von 0 bis TOP. > > Im eingestellten Modus ist TOP immer 255 und hängt von nichts ab. > Der Compare Match hat damit nichts zu tun. Du meinst damit, dass Fast-PWM beim Erreichen des TOP (hier 255) keinen TIMER1_COMPA_vect aus löst? Dann verstehe ich die Programmlogik von programm.txt (4.8 KB) auch nicht.
ja das mit dem timer habe ich schon verstanden, dass es ohne einen 2ten geht. aber mein problem liegt immer noch am timer 1 der nicht so arbeitet wie ich es eigentlich eingestellt habe
Helfer schrieb: >> Äh. Nein >> >> Fast PWM: >> Der Timer zählt von 0 bis TOP. >> >> Im eingestellten Modus ist TOP immer 255 und hängt von nichts ab. >> Der Compare Match hat damit nichts zu tun. > > Du meinst damit, dass Fast-PWM beim Erreichen des TOP (hier 255) keinen > TIMER1_COMPA_vect aus löst? Warum sollte es? Der Compare Wert ist der Wert, wann die PWM Steuerung den Output Pin umschalten soll. Mit dem Endwert hat das nichts zu tun.
Jay Steve schrieb: > ja das mit dem timer habe ich schon verstanden, dass es ohne einen 2ten > geht. aber mein problem liegt immer noch am timer 1 der nicht so > arbeitet wie ich es eigentlich eingestellt habe Ich hab jetzt wenig Zeit, sonst würd ich das selber ausprobieren. Was ich tun würde: Abgespecktes Programm, nur den Timer 1 im Fast PWM - 8 Bit Und das im Simulator durchtesten. Wenn es dann immer noch ist, dann ist es ein Fehler im Simulator. Der reale Mega8 macht das definitiv richtig.
ich habe die schaltung auch aufgebaut und getestet. und er macht leider genau das.
Eines ist mir in deinem Programm noch aufgefallen. Irgendwo beschreibst du von einem 16-Bit Register nur das Low-byte. Gewöhn dir das ab. Der GCC unterstützt dich dabei: Du kannst so tun als ob zb TCNT1 ein 16-Bit Register wäre und einfach auf TCNT1 zuweisen. Die Aufteilung in Low und High macht der GCC für dich (denn da ist die Reihenfolge wichtig). Irgendwo bei den Cmopare Werten hast du nur das L Register beschrieben aber nicht das H
also jungs. ich bin stecke komplett fest. der sch*** funktioniert nicht. bin es sicher 10 mal durchgegangen im datenblatt und habe es auch mit dem aufbau getestet. ES GEHT NICHT. fast pwm mode sollte eingestellt sein. ist es aber nicht. HELFT MIR BITTE! :(
Leider verstehe ich dein Wunschtiming nicht. Im Anhang so wie ich mir das vorstelle...
ich danke herzlichst. heute um 13 uhr etwa werd ich das mal probieren. danke!
Bitte 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.