[STM32F0] Problem mit ungenauem Timer (RX Signal)

Was ist ein RX-Signal? Etwas das eigentlich von einer seriellen 
Schnittstelle kommt?

Speedy schrieb:
> Obwohl diese ebenfalls bei
> ziemlich exakt 20ms liegt.
Wie gemessen? Es ist ja relativ nah dran.

Speedy schrieb:
> Selbst mit einem AVR
> und internem Takt habe ich ein RX Signal extrem genau vermessen können.
Genau das selbe Signal?

Speedy schrieb:
> Der Quellcode hängt an.
Ist nicht vollständig, daher wertlos.

Dr. Sommer schrieb:
> Was ist ein RX-Signal? Etwas das eigentlich von einer seriellen
> Schnittstelle kommt?
Ein Servo-Signal (PPM, 1-2ms DutyCycle, 20ms Periode).
>
> Speedy schrieb:
>> Obwohl diese ebenfalls bei
>> ziemlich exakt 20ms liegt.
> Wie gemessen? Es ist ja relativ nah dran.
Oszi. Und nein 10% sind nicht nahe dran. Der gesamte Ausfahrbereich 
liegt zwischen 1000µS und 2000µS. Da sind 100µS Fehler alles andere als 
nahe dran.

>
> Speedy schrieb:
>> Selbst mit einem AVR
>> und internem Takt habe ich ein RX Signal extrem genau vermessen können.
> Genau das selbe Signal?
Nein aber dutzende Servosignale von dutzenden Empfängern und 
Servotestern.

>
> Speedy schrieb:
>> Der Quellcode hängt an.
> Ist nicht vollständig, daher wertlos.
Er ist vollständig. Was feht ist der startup code und das linkerscript.
Die RCC Konfiguration machen ich allerdings für diesen Test in der 
main.c und das ist somit auch sichtbar.

Speedy schrieb:
> Er ist vollständig.

Komisch. Bei mir sagt der Compiler, dass "init" nicht definiert ist. Und 
ich sehe auch nirgendwo eine Ausgabe der Werte des Timers. Guckst du mit 
Röntgenblick in die Capture Register und liest sie somit 100% sicher 
korrekt aus?

Speedy schrieb:
> Oszi.
Sicher dass die Pegel stimmen, und man auf die 1ms nicht nur kommt wenn 
man alles größer als 0.5V aus "high" zählt, oder so?

> timBase.TIM_Prescaler=8;
Fällt mir gerade auf - das teilt den Takt durch 9, nicht 8.

Dr. Sommer schrieb:
> Speedy schrieb:
>> Er ist vollständig.
>
> Komisch. Bei mir sagt der Compiler, dass "init" nicht definiert ist.
-> Das ist sicher im Startup code. Aber der ist 1:1 aus der StdPeriphLib 
übernommen. Natürlich ist trotzdem nicht auszuschließen das darin was 
schief läuft.

> Und
> ich sehe auch nirgendwo eine Ausgabe der Werte des Timers. Guckst du mit
> Röntgenblick in die Capture Register und liest sie somit 100% sicher
> korrekt aus?
Per Debugger. Ich pausiere und schaue mir die Register CCR1 und CCR2 an.

>> timBase.TIM_Prescaler=8;
> Fällt mir gerade auf - das teilt den Takt durch 9, nicht 8.
Oha, na wenn das mal keine Volltreffer ist.
Wieso teilt das durch 9? Ich habe heute Stundenlang die Clocks und 
Prescaler von dem Ding studiert.
Danke für den Hinweis.

Speedy schrieb:
>
> Wieso teilt das durch 9? Ich habe heute Stundenlang die Clocks und
> Prescaler von dem Ding studiert.

Tja wenn man kurz drüber nachdenkt wirds klar. Sicher weil 0 = 1:1 
bedeutet. Ich habe einfach keine Erfahrung mit derart "freien" 
Prescalern. Ich bin nur die von den AVRs gewöhnt und da hat man halt ne 
Handvoll und schlägt die Einstellung im Datenblatt nach.

Speedy schrieb:
> -> Das ist sicher im Startup code.
Der Startup Code definiert keine globalen Hilfsvariablen, die onehin 
lokal sein sollten. Die Definition hast du lediglich beim Copy&Paste 
verloren. Kaputtkopieren von Code kann die Fehlersuche im Forum 
erheblich erschweren...

Speedy schrieb:
> Wieso teilt das durch 9?
Das ist ein 16bit-Prescaler, und die Hardware addiert automatisch 1, 
denn:
Eine 16bit-Zahl geht von 0 bis 65535. Durch 0 kann man nicht teilen, und 
indem man immer 1 aufaddiert, kann man auch durch 65536 teilen.

> Ich habe heute Stundenlang die Clocks und
> Prescaler von dem Ding studiert.
Tja, hättest du mal die Register-Definition vom Prescaler-Register, und 
den Code der Library angeschaut, die den Prescaler-Wert 1:1 ins Register 
schreibt (aber nur beim Timer, beim CAN z.B. ist das wimre nicht so)...
(letzteren Schritt spart man sich, wenn man auf die Library verzichtet)