Interner RC Oszillator von STM32C5 überraschend gut

[Nemopuk (nemopuk)]

Beim Vergleich diverser Mikrocontroller ist mir aufgefallen, dass der 
HSI Oszillator von allen STM32C5 außergewöhnlich stabil ist. Der 
Hersteller verspricht 1% in einem Temperaturbereich von -20 bis +130 
Grad Celsius.

Der weite Temperaturbereich überrascht mich. Ist das

a) inzwischen normal, oder

b) tatsächlich besonders gut, oder

c) bin ich zu dumm, das Datenblatt zu verstehen?

[Jörg R. (solar77)]

Nemopuk schrieb:
> Beim Vergleich diverser Mikrocontroller ist mir aufgefallen, dass
> der HSI Oszillator von allen STM32C5 außergewöhnlich stabil ist. Der
> Hersteller verspricht 1% in einem Temperaturbereich von -20 bis +130
> Grad Celsius.

> Der weite Temperaturbereich überrascht mich. Ist das

> c) bin ich zu dumm, das Datenblatt zu verstehen?

Vielleicht solltest du auf das Datenblatt verlinken. Dann muss nicht 
jeder der evtl. helfen will danach suchen;-)

[Harald A. (embedded)]

Nemopuk schrieb:
> Der weite Temperaturbereich überrascht mich. Ist das
>
> a) inzwischen normal, oder

Bei vielen Microcontrollern neueren Datums hat sich bei den internen 
Oszillatoren gegenüber "früher" einiges getan. Für "Standardaufgaben" 
und UART dürfte es reichen, bei CAN/Ethernet wird es hingegen nicht ganz 
reichen.

Je nachdem, welche Extreme man tatsächlich noch berücksichtigen muss, 
ist das z.B. bei > -30°C unter 1% - wie gesagt, UART okay, CAN eher 
nicht bzw. grenzwertig

[Niklas G. (erlkoenig)]

Harald A. schrieb:
> CAN eher nicht bzw. grenzwertig

Müsste CAN nicht vergleichsweise unproblematisch sein aufgrund der 
NRZ-Codierung (Bitstuffing) welche eine Synchronisierung des Takts 
ermöglicht? Bei UART gibt's das ja so nicht, dafür sind die Frames 
kürzer...

[Vanye R. (vanye_rijan)]

> Der weite Temperaturbereich überrascht mich. Ist das

Naja relativ. Der uebliche industrielle Temperaturbereich ist -40 bis 
+85, der Hersteller sagt dir also damit das sein RC-Oszillator fuer 
industrielle Anwendung nicht 1% genau ist. .-)

Und wenn man bedenkt wie wichtig die -40 sind, dann sagt er sogar, wir 
haben es probiert, aber es ging wirklich nicht. Sonst wuerden sie nicht 
-20 schreiben. :-D

Vanye

[Harald A. (embedded)]

Niklas G. schrieb:
> Harald A. schrieb:
>> CAN eher nicht bzw. grenzwertig
>
> Müsste CAN nicht vergleichsweise unproblematisch sein aufgrund der
> NRZ-Codierung (Bitstuffing) welche eine Synchronisierung des Takts
> ermöglicht? Bei UART gibt's das ja so nicht, dafür sind die Frames
> kürzer...

Bei angenommenen Sample-Punkt 87,5%, 250kbit, SJW=1 sind es rechnerisch 
pro Knoten 0,3%, bei SJW=2 theoretisch 0,6%. Blanke Theorie, 
Abweichungen, bei denen auf jeden Fall Probleme aufkommen werden. In der 
Praxis sollte man besser deutlich drunter bleiben, vor allem wenn es 
nicht nur auf dem Labortisch laufen soll.

Edit: CAN FD nochmal kritischer.