Motor PWM 19KHz?

[RolfD]

Also ich hatte beschlossen, den Timer1 auf 20KHz bzw. 10.000 PWM Impulse laufen zu lassen. Das ergibt ein Wert von 400 für das 16 Bit Register ICR1 bei Precaler 1 und eine Auflösung von 100 μs für die ISR (TIMER1_OVF_vect), wo ich da dann alles 1:1 rein setzen kann was vorher in der ISR (TIMER0_COMP_vect) stand. Damit ist der Timer0 frei für RTOS. Die Pole des Motorankers dürften so genügend Pulse Pro Sek. bekommen um sauber zu arbeiten auch wenn er dann etwas fiept und alle anderen Abläufe müssten gleich sein. Sogar die Stopwatches tuen es dann noch. Für die Anpassung der Sollgeschwindigkeit aus RP6 Lib Funktionen (passend zum ICR1 Dutycycle Wert) reicht zum testen eine Multiplikation / bitshift *2 welche einfach in die ISR Motorsteuerung einzubringen ist.
Dann noch ein RTOS Task der die RP6Tasks aufruft und alles müsste eigentlich passen... Eigentlich... denn es passt nicht!

Zunächst was ich noch nicht ganz verstehe, TCCR1A und TCCR1B sind ja die Timerconfigurationsregister. Die werden zu Anfang durch Hardwareinit gesetzt. Ok. Und teilweise später auf 0 gesetzt... Warum?
U.a. in emergencyShutdown, bei task_motionControl im Abschnitt CHANGE_DIRECTION_FAST wobei unter CHANGE_DIRECTION_MEDIUM nur geprüft wird, in der ISR (TIMER0_COMP_vect) ... allerdings auch wieder gesetzt..
Würde es nicht ausreichen TCCR1A in Ruhe zu lassen und nur einfach OCR1AL und OCR1BL mit 0 zu beschreiben damit der Bot stehen bleibt?
Irgendwie wird da das TCCR1A in der RP6Lib als 2.ter Ein/Aus Schalter fürs PWM benutzt - was aber zu Problemen führt wenn TIMER1_OVF_vect (s.o.) auch systemrelevante Funktionen steuert und daher weiter laufen soll.
Eine bessere Lösung wäre vielelicht auch die Directionbits im Port zu ändern da die PWM nur nach ausßen gelangt wenn die Portbits auf Ausgang stehen bzw. die Bits COM1A1:0 and COM1B1:0 in TCCR1A zu löschen.
vergl. S.107 im cpu-pdf

"The COM1A1:0 and COM1B1:0 control the Output Compare pins (OC1A and OC1B respectively)
behavior. If one or both of the COM1A1:0 bits are written to one, the OC1A output
overrides the normal port functionality of the I/O pin it is connected to. If one or both of the
COM1B1:0 bit are written to one, the OC1B output overrides the normal port functionality of the
I/O pin it is connected to. However, note that the Data Direction Register (DDR) bit corresponding
to the OC1A or OC1B pin must be set in order to enable the output driver."

Ok... also passend umschreiben.

Aber was mir noch aufgefallen ist... Radbruchs Tip TIMER1_OVF_vect zu nutzen scheint mir inzwischen nicht mehr die beste Idee wie dort Figure 47. Phase Correct PWM Mode, Timing Diagram etwa mitte des Bildes zeigt.
Die Interrupts fallen bei Mode 10 _nicht_ Zeitsyncron an, sondern je nach dem wie das PWM Verhältnis eingestellt ist. Deren Frequenz kann sich bis zu einem mehrfachen der ursprünglich erwarteten Frequenz steigern. Mit anderen Worten, die Rechnung oben zum Thema TimerISR umsetzen wäre für die Katz! Sehe ich das richtig so?

Praktisch ruckelt der Bot jedenfalls als würde jemand ständig Gas und Bremse vertauschen... Karnickelhüpfen quasi...

Ich will das Ganze noch mal mit Timer Mode 8, also "PWM, Phase and Frequency Correct" versuchen, ansonsten war das Ganze ein informativer Ausflug in die Timerprogrammierung und die RP6Lib aber leider ist so kein Blumenpott zu gewinnen...

LG Rolf

[radbruch]

Hallo

Aber was mir noch aufgefallen ist... Radbruchs Tip TIMER1_OVF_vect zu nutzen scheint mir inzwischen nicht mehr die beste Idee wie dort Figure 47. Phase Correct PWM Mode, Timing Diagram etwa mitte des Bildes zeigt.
Die Interrupts fallen bei Mode 10 _nicht_ Zeitsyncron an, sondern je nach dem wie das PWM Verhältnis eingestellt ist. Deren Frequenz kann sich bis zu einem mehrfachen der ursprünglich erwarteten Frequenz steigern. Mit anderen Worten, die Rechnung oben zum Thema TimerISR umsetzen wäre für die Katz! Sehe ich das richtig so?

In der Mitte von Bild 47 wird TOP verändert, deshalb ändert sich die Frequenz. Etwas weiter unten steht folgendes:

When using a static TOP value there are practically no differences between the two modes of operation.

Gruß

mic

[RolfD]

"When using a static TOP value there are practically no differences between the two modes of operation."

Diese Aussage bezieht sich auf den Unterschied von "PWM, Phase and Frequency Correct" und "PWM, Phase Correct".
Da wir mit ICR1 ein static TOP haben, verhält sich Mode 8 wie Mode 10... also dürfte Mode 8 auch nichts gegenüber Mode 10 verbessern. ok. Aber..

"The Timer/Counter Overflow Flag (TOV1) is set each time the counter reaches BOTTOM. When
either OCR1A or ICR1 is used for defining the TOP value, the OC1A or ICF1 Flag is set accordingly
at the same timer clock cycle as the OCR1x Registers are updated with the double buffer
value (at TOP). The Interrupt Flags can be used to generate an interrupt each time the counter
reaches the TOP or BOTTOM value."

Da Top = ICR1 und Bottom = 0 nicht verändert werden, müsste es so gehen.. nur warum "hüppelt" der Bot dann aber so?
Ich sehe schon ein das du theoretisch recht hast mit dem TIMER1_OVF_vect, Radbruch... praktisch tuts das aber so nicht.
Ob das an den noch nicht umgeschriebenen Registern TCCR1A = 0 (s.o.) liegen kann? Ich mach mich mal dran das zu ändern.
Denn das würde den Zeitgeber Timer1 beeinflussen und so ggf. Störungen in den 100uS Messschleifen verursachen.

Hier meine Änderungen bisher:
Init:

// Initialize Timer 0 - 2ms cycle or 500Hz RTOS
TCCR0 = (0 << WGM00) | (1 << WGM01)
| (0 << COM00) | (0 << COM01)
| (0 << CS02) | (1 << CS01) | (1 << CS00);
OCR0 = 250; // 500 Hz

// Initialize Timer1 - PWM and exTimer0 Funktions:
// PWM, phase correct with ICR1 as top value.
TCCR1A = (0 << WGM10) | (1 << WGM11) | (1 << COM1A1) | (1 << COM1B1);
TCCR1B = (1 << WGM13) | (0 << WGM12) | (1 << CS10); // prescaler /1

// 20000 Hz = ICR1 400, bzw. pwm von 10000 Hz -> 0,0001 S bzw. 100 μs bei prescaler /1

ICR1 = 400; // New Phase corret PWM top value, 400 = 10 KHz 100uS

Dann die ISR für Timer:
ISR (TIMER0_COMP_vect) in ISR (TIMER1_OVF_vect) geändert. Aufruf alle 100uS

ISR für den nun freien Timer0:

#if configUSE_PREEMPTION == 1
// ISR (TIMER0_COMP_vect, ISR_NAKED)
ISR (TIMER0_COMP_vect)
{
// vPortYieldFromTick();
// asm volatile ( "reti" );
}
#else
// ISR (TIMER0_COMP_vect, ISR_NAKED)
ISR (TIMER0_COMP_vect)
{
// vTaskIncrementTick();
}
#endif // portUSE_PREEMPTION

Um aktuell Komplikationen zu verhindern ist die nun zum RTOS gehörende ISR (TIMER0_COMP_vect)
so geändert, das sie als normale ISR ohne ins RTOS zu wechseln 500 mal /sec nichts macht. Da das RTOS
nicht angesprungen wird liegt es nur als toter Code im Hexfile - es geht also immer noch nur um die RP6Lib.

Is also alles keine Zauberei... und trotzdem ruckelt der Bot vor sich hin statt normal zu fahren.
LG Rolf

[SlyD]

Hallo,

Irgendwie wird da das TCCR1A in der RP6Lib als 2.ter Ein/Aus Schalter fürs PWM benutzt - was aber zu Problemen führt wenn TIMER1_OVF_vect (s.o.) auch systemrelevante Funktionen steuert und daher weiter laufen soll.

Nun mit der normalen Lib war das natürlich nicht vorgesehen und daher nicht nötig das anders zu machen.
Mit TCCR1A = 0 ist die PWM halt sicher aus und die Ports wieder normale I/Os.
Und man kann einfach mit if(!TCCR1A) testen ob beide PWM Werte schon bei 0 angekommen sind (bei change direction).
Kannst Du natürlich ändern oder nur die passenden Bits (COM1x1) in dem Register setzen.

Warum es ruckelt kann ich auf Anhieb nicht sagen ohne mir das genauer anzuschauen.

MfG,
SlyD

[RolfD]

Ich habe nun mal alle TCCR1A=0 entfernt und durch OCR1AL = 0; OCR1BL = 0; ersetzt und siehe da - der Bot bewegt sich - oh Wunder - sanft und ruhig.

Nun frag ich mich.... warum rief der denn vorher überhaupt in dem Beispiel Example_05_Move_01 das TCCR1A=0 auf?
Da steht ja nur drin: "Beweg dich langsam vorwärts (wobei er {beide RP6, die ich hab} da bei mir schon immer rückwärts anfuhr)".. also kein Richtungswechsel.. keine Speedänderung, kein Halten ...

Und man kann einfach mit if(!TCCR1A) testen ob beide PWM Werte schon bei 0 angekommen sind (bei change direction).

Das halte ich aber für ein dickes Gerücht.... ein gelesenes TCCR1A gibt aus was man als Config Bits reinschreibt - und keine Istwerte des Zählers. Im TCCR1A steht z.B. das Verhalten für COM1A1 und COM1B1 drin, also die Portpins bei Timerüber/unterlauf. Ferner steht da auch der PWM Mode drin....welcher sich zur Laufzeit niemals ändert. Ein TCCR1A kann also niemals 0 werden - egal wie der Status der PWM Counter ist. Ein OCR1AL = 0; OCR1BL = 0; sorgt eh dafür, das keine Impulse mehr rausgehen. Es ist nun wirklich nicht nötig, Änderungen im Dutycycle bei 10 bzw. 19 KHz PWM auf den aktuellen PWM Counter zu timen - wie du andeutest, Slyd. Der Code da in der ISR mit if(!TCCR1A) ist einfach nicht sinnvoll.
Siehe Seite 107-109 im CPU-PDF.
Ich vermute, da haben sich nur einfach ein paar Denkfehler in die bisherige Motorsteuerung eingeschlichen. Dies betrifft zumindest die lesende Nutzung des TCCR1A, sowie auch das mitten im Rollbetrieb scheinbar Konditionen entstehen, die dazu führen, das TCCR1A = 0 ausgeführt wird. Beides fällt in der alten Timerconfig halt nur nicht auf.

Jetzt kann man natürlich mit dem schlagenden Argument kommen "funktioniert doch bisher" ... und ich füge an ... "irgendwie".
Vielleicht wäre es wirklich mal an der Zeit, die RP6Lib zu überarbeiten. Nach TWI schon der 2. Problemkreis, der sich für mich auftut.
Aber da ich ja eh das RTOS portieren will... *seufz
Jedenfalls tuts jetzt die Idee mit TIMER1_OVF_vect, Timer0 ist frei und es kann los gehen mit RTOS, Danke noch mal an Radbruch für den Tip und alle beteiligten Leser fürs Mitdenken.
LG Rolf

[SlyD]

Ne ne hier verstehst Du nur was an dem Programmablauf nicht ganz

ein gelesenes TCCR1A gibt aus was man als Config Bits reinschreibt

Ja genau, und was wird im Timerinterrupt reingeschrieben wenn beide OCRs 0 sind?
--> 0
Was steht also drin wenn die PWM Werte auf 0 runtergeregelt wurden?
--> 0

Passt also.

MfG,
SlyD

[RolfD]

Hi Slyd,
du benutzt das TCCR1A bewust als Statusvariable für die PWM ... ok.. ja vermutet hatte ich den Zusammenhang ja oben schon mit dem ein/aus Schalter.
Ok kann man so machen...
Als Regelkreislauf kommt es aber offensichtlich dazu, das diese Kondition auch im Fahrbetrieb des Beispiels Example_05_Move_01 aufkommt - was hier dann zu ruckeln führte. Ok das ruckeln liegt an meiner Bastelei am Timer1...
Nur darf der Regelkreislauf so exorbitant ausschlagen das der Motorcontroller meint, im Rollbetrieb zwischendrin mal eben so die PWM Generierung abschalten zu müssen? Da ist doch was im argen...
Gruß Rolf