Hallo Freunde der Elektronik! Beim STM32L431 kann man für die Timer nur den Systemclock nehmen. Dies empfinde ich als problematisch, da der Systemclock von der PLL kommen muss, wenn man 80 MHz Taktfrequenz für die CPU erhalten will. Damit erben die Timer aber auch den Jitter von 50-60 ps (bei 80 MHz), was knappe 0.5% Frequenzungenauigkeit bedeutet. Allerdings weiß ich nicht, ob bei Langzeitmessungen (Stunden) durch Mittelung der Jitterfehler erheblich niedriger liegt, sich evtl. kompensiert, da die Flanken mal früher, mal später kommen. Daß man z.B. den Quarzoszillator (HSE) nicht zu den Timern routen kann, kommt mir komisch vor, das kann nämlich der 1 € SAMD10 von Atmel. Zwar kann ich den Quarztakt beim STM431 auf einem Port ausgeben, aber es kann doch nicht sein, daß ich diesen Takt dann von außen in einen Timer gebe, der dann im Input capture mode arbeiten muss. Übersehe ich etwas, mache ich einen Denkfehler? Gruß Uwe
Ein Jitter hat nicht unbedingt eine Frequenzungenauigkeit zur Folge. Die Frequenz ist ja per PLL an die Referenz angebunden.
Martin O. schrieb: > Ein Jitter hat nicht unbedingt eine Frequenzungenauigkeit zur Folge. Das verstehe ich nicht. Wenn eine Flanke verfrüht oder verspätet kommt, ändert sich doch die Zeit, und folglich die Frequenz, da die Frequenz eine Funktion der Zeit ist. Ich erbitte Erklärung!
:
Bearbeitet durch User
Uwe M. schrieb: > Das verstehe ich nicht. Das ist ein Problem der Lokalität. Wenn die PLL ein wenig wackelt (was der Normalfall ist, schließlich ist das das Funktionsprinzip einer PLL), wird natürlich lokal (für einen oder sehr wenige Takte) die Frequenz divergieren. Über weitere Zeiträume (etliche Takte) betrachtet, mittelt der Fehler sich aber aus. Denn genau das ist Sinn und Zweck einer PLL. Wenn du nicht einmal solche Trivialitäten verstehen kannst, spielst du definitiv in einer Liga, in der du völlig falsch bist. Da taugst du nur als waterboy.
Uwe M. schrieb: > Wenn eine Flanke verfrüht oder verspätet kommt, > ändert sich doch die Zeit, und folglich die Frequenz, da die Frequenz > eine Funktion der Zeit ist. Bei einem PWM-Signal kannst Du das Tastverhältnis beliebig ändern, ohne daß sich dessen Frequenz verändert. Deine 0,5% Rechnung gilt nur für eine Periodendauer von 12,5 ns. Bezogen auf 1 s sind es .... Mein Taschenrechner schafft es nicht ;-)
c-hater schrieb: > mittelt der Fehler > sich aber aus. Wenn du meinen Beitrag verstanden hättest (habe die Mittelung nicht ausgeschlossen), hättest du dir deine blöde und freche Bemerkung ersparen können. Haste in der Firma auch so einen üblen Jargon drauf, oder biste deswegen schon dauerarbeitslos? Waterboy
50ps entspricht einer Frequenz von 20GHz. Der Jitter ist also viel weniger. Abgsehen davon verursacht dieser Jitter keine zusätlichen Zählfehler. Der Jitter selber mittelt sich ja aus. Ich bin der Ansicht, daß man sich in diesen Kontext keine Gedanken darüber machen muß. Teste das Ganze aktuell mit HW und überanalysiere es nicht zu sehr.
:
Bearbeitet durch User
Gerhard O. schrieb: > Der Jitter selber mittelt sich ja aus. Sicher, wobei die Frage lauten muss, wie weit kompensiert sich der Fehler. Wenn ich eine Quarzfrequenz der PLL am Eingang anbiete, kommet man auf lange Sicht auf die Frequenzgenauigkeit des Quarzes?
Uwe M. schrieb: > Wenn ich eine Quarzfrequenz der PLL am Eingang anbiete, kommet > man auf lange Sicht auf die Frequenzgenauigkeit des Quarzes? O.m.g. Das ist genau der Sinn und Zweck einer PLL. c-hater schrieb: > Wenn du > nicht einmal solche Trivialitäten verstehen kannst, spielst du definitiv > in einer Liga, in der du völlig falsch bist. Da taugst du nur als > waterboy.
Uwe M. schrieb: > Sicher, wobei die Frage lauten muss, wie weit kompensiert sich der > Fehler. Wenn ich eine Quarzfrequenz der PLL am Eingang anbiete, kommet > man auf lange Sicht auf die Frequenzgenauigkeit des Quarzes? OMG Noch einer, der das Konzept einer PLL nicht verstanden hat. Die Antwort ist natürlich JAAAA. Denn genau das ist der Sinn einer PLL... Kann das Niveau hier noch weiter abstürzen oder ist bittere Ende damit bereits erreicht?
Uwe M. schrieb: > Gerhard O. schrieb: >> Der Jitter selber mittelt sich ja aus. > > Sicher, wobei die Frage lauten muss, wie weit kompensiert sich der > Fehler. Wenn ich eine Quarzfrequenz der PLL am Eingang anbiete, kommet > man auf lange Sicht auf die Frequenzgenauigkeit des Quarzes? Absolut. Der VCO der PLL hat eine exakte und definierte Phasenveziehung zur Quarzreferenz. Nur die augenblicklichen Flanken des VCO jittern zufällig um den von Dir angegebenen Betrag. Die Frequenz des VCO ist immer exakt ein Vielfaches der Quarzfreqzenz. 50ps Jitter entspricht dem 250zigstel der VCO Frequenz. Statistisch wirst Du da nichts bemerken. Die übliche +/-1 Zählungenaugigkeit fällt da alleine ins Gewicht. Natürlich muß der Quarz bzw der Referenzoszillator die geforderte Genauigkeit und Stabilität haben. Das ist nicht anders als bei anderen Frequenzzählern auch. Professionelle Geräte haben noch HW um die traditionelle +/-1 Ungenauigkeit im Periodenmodus zu vermindern. Viele Timerschaltungen in uC haben noch eine Synchronisierlogik mit der Zeitbasisfrequenz um statistische Zählungenauigkeiten zu vermeiden bzw. zu minimieren. Was mich interessiert, wie hoch ist die höchste Frequenz die Du messen möchtest? Mißt Du die Länge einer Periode oder zählst Du Perioden mittels zeitlichen Meßfensters?
:
Bearbeitet durch User
c-hater schrieb: > Kann das Niveau hier noch weiter abstürzen oder ist bittere Ende damit > bereits erreicht? Dein Niveau (Jargon) ist nicht mehr zu unterbieten, gratuliere!
Danke dir Gerhard für die sehr ausführliche, klare Antwort! Man kann halt nicht Alles wissen bis ins letzte Detail, Ausnahme C-hater.
Uwe M. schrieb: > Ausnahme C-hater. Keine Sorge. Der ist en bekannter Troll. Wenn man solche Beiträge (gedanklich) ausblendet, bekommt man hier gute Antworten.
Hallo Gerhard! Sorry, habe deine Frage jetzt erst bemerkt. Ich setze mehrere Timer ein, um im output compare mode definierte Zeiten festzulegen für Lade- und Entladeimpulse (Gegenstrom Ladeverfahren von Ernst Behr). Das heißt, der Counter wird mit dem Systemtakt von 80 MHz befeuert. Vielleicht wird der Prescaler auf /2 gesetzt, da sich die CPU sehr schön übertakten läßt (bis 160 MHz), was ich aber für mein privates Projekt nicht voll ausnutzen werde, vielleicht nur bis 100 MHz (ich weiß, Risiko, it's just for fun!). Gruß Uwe
:
Bearbeitet durch User
Uwe M. schrieb: > Hallo Gerhard! > > Sorry, habe deine Frage jetzt erst bemerkt. Ich setze mehrere Timer ein, > um im output compare mode definierte Zeiten festzulegen für Lade- und > Entladeimpulse (Gegenstrom Ladeverfahren von Ernst Behr). Das heißt, der > Counter wird mit dem Systemtakt von 80 MHz befeuert. Vielleicht wird der > Prescaler auf /2 gesetzt, da sich die CPU sehr schön übertakten läßt > (bis 160 MHz), was ich aber für mein privates Projekt nicht voll > ausnutzen werde, vielleicht nur bis 100 MHz. > Gruß > > Uwe Danke für die Antwort. Ich würde Dir raten den Vorteil Faktor gerade groß genug einzustellen um die gewünschte Auflösung zu bekommen. Unnötig hohe Taktfreqenzen geben Dir möglicherweise nur unnötig feine Werte. Vielleicht geht es in Deiner Anwendung sogar mit us bzw ms Taktperioden. Vielleicht überlege mal mit 1Mhz bzw 1us Auflösung zu arbeiten. Ich kenne allerdings das Ernst Behr Verfahren noch nicht und schwatze hier möglicherweise aus der Schule:-) Der Vorteil einer langsameren Taktfrequenz liegt in der Möglichkeit auf die vorhandene Synchronisiereinrichtungen zuzugreifen die dann stabileres Zählen bewirken. Diese Synchronisier Schaltungen haben aber in der Regel eine obere maximale Grenzfrequenz.
Hallo Gerhard! Das Gegenstromladeverfahren von Ernst Behr aus dem Jahr 1954 verlängert die Lebensdauer von Akkus um gut das Doppelte, höhere Ladeströme sind möglich. Sogar Alkalibatterien kann man damit teilweise laden. Der Ladezyklus dauert zwischen ca. 1 - 15 ms, der Entladezyklus ca. 100 us - 1 ms. Den Faktor muss ich auf 20 (*4 MHz) mindestens einstellen, beim Prescaler der Timer kann ich die Frequenz teilen. Guter Gesichtspunkt: Langsamer Takt aus dem Prescaler durch größere Teilung mittelt den Jitter (weitgehend) weg, Zeit heilt Wunden. :-)
:
Bearbeitet durch User
Die Auflösung schafft ja schon ein kleiner PICkel. Sogar mit einer Soft-PWM!
Uwe M. schrieb: > 1 - 15 ms, der Entladezyklus ca. 100 us - > 1 ms. Den Faktor muss ich auf 20 (*4 MHz) mindestens einstellen, Und dann noch Sorgen um 60ps Jitter... Ist das hier nu Getrolle oder Akku-Esoterikkram?
Teo D. schrieb: > Uwe M. schrieb: >> 1 - 15 ms, der Entladezyklus ca. 100 us - >> 1 ms. Den Faktor muss ich auf 20 (*4 MHz) mindestens einstellen, > > Und dann noch Sorgen um 60ps Jitter... > > Ist das hier nu Getrolle oder Akku-Esoterikkram? Laß ihm doch ein bischen Zeit ein Gefühl dafür zu bekommen wie man die praktisch vernünftigsten Einstellungen bestimmt.
:
Bearbeitet durch User
Uwe M. schrieb: > Hallo Gerhard! > > Das Gegenstromladeverfahren von Ernst Behr aus dem Jahr 1954 verlängert > die Lebensdauer von Akkus um gut das Doppelte, höhere Ladeströme sind > möglich. Sogar Alkalibatterien kann man damit teilweise laden. Der > Ladezyklus dauert zwischen ca. 1 - 15 ms, der Entladezyklus ca. 100 us - > 1 ms. Den Faktor muss ich auf 20 (*4 MHz) mindestens einstellen, beim > Prescaler der Timer kann ich die Frequenz teilen. Guter Gesichtspunkt: > Langsamer Takt aus dem Prescaler durch größere Teilung mittelt den > Jitter (weitgehend) weg, Zeit heilt Wunden. :-) Danke. Ja, da kannst Du mit deutlich lockerern Einstellungen arbeiten. Bei 1Mhz hast Du noch 1us Auflösung mit bis 65K (65ms)im 16-bit Modus ohne Überlauf und bei kaskadierten Zählern ist es sowieso kein Thema. Bei 1Mhz kannst Du die Steuerzeit Periode mit 1us Auflösung bestimmen. Da brauchst Du an sich nicht schneller takten. Ja, ein AVR oder PIC würde hier auch dicke ausreichen und ein STM32... Naja, uC sind nicht nachtragend:-)
:
Bearbeitet durch User
Hallo Gerhard! Das Projekt hatte ich letztes Jahr mit einem AVR (ATMega 8) gelöst, wobei hier klar die Grenzen aufgezeigt wurden! Wenn der ADC 65 us braucht pro Wandlung (ohne Averaging!!!), die anschließende Berechnung einer aufwendigen 32 Bit Formel für die Entladezeit auch noch mal etwa 150 us benötigt und errechnet, der Entladeimpuls hätte 100 us dauern sollen statt 215 us, dann kannste das Verhältnis zwischen Ladung und Entladung (10:1) schlecht einhalten. Das schadet dem Akku nicht, aber dem eigenen Ehrgeiz. Und da ich mich 2001 aus der uC Programmierung verabschiedet hatte, um mich ganz der HW zu widmen (EMV), hatte ich nicht mitbekommen, was es mittlerweile für tolle uCs gibt von Arm. Bei uns in der Automobilindustrie war damals Motorola/Freescale (heute NXP) angesagt, HC08, HC16, technisch langweilig. Dagegen war mein erster 1€ ARM Cortex mit M0+ (SAMD10) eine Revolution, ich war am staunen bei CPU und der aufwendigen Peripherie, eine neue Welt voller Innovationen. So wird mein Lebensabend nicht langweilig.
:
Bearbeitet durch User
Uwe M. schrieb: > Hallo Gerhard! > > Das Projekt hatte ich letztes Jahr mit einem AVR (ATMega 8) gelöst, > wobei hier klar die Grenzen aufgezeigt wurden! Wenn der ADC 65 us > braucht pro Wandlung (ohne Averaging!!!), die anschließende Berechnung > einer aufwendigen 32 Bit Formel für die Entladezeit auch noch mal etwa > 150 us benötigt und errechnet, der Entladeimpuls hätte 100 us dauern > sollen statt 215 us, dann kannste das Verhältnis zwischen Ladung und > Entladung (10:1) schlecht einhalten. Das schadet dem Akku nicht, aber > dem eigenen Ehrgeiz. Und da ich mich 2001 aus der uC Programmierung > verabschiedet hatte, um mich ganz der HW zu widmen (EMV), hatte ich > nicht mitbekommen, was es mittlerweile für tolle uCs gibt von Arm. Bei > uns in der Automobilindustrie war damals Motorola/Freescale (heute NXP) > angesagt, HC08, HC16, technisch langweilig. Dagegen war mein erster 1€ > ARM Cortex mit M0+ (SAMD10) eine Revolution, ich war am staunen bei CPU > und der aufwendigen Peripherie, eine neue Welt voller Innovationen. So > wird mein Lebensabend nicht langweilig. Hallo Uwe, Alles klar. Ja ich arbeite auch ganz gerne mit dem STM32 und vielen Berechnungen ist man damit klar im Vorteil. Naja, wenn Du schon eine Lösung hast, sollte es mit dem 32-bitter zügiger gehen. Berichte mal gelegentlich wie groß die Unterschiede und Grenzen liegen. Gruß, Gerhard
Hallo Gerhard! Also der M0+ im SAMD10 hat bei gleicher Taktfrequenz die 32 Bit Berechnungen um den Faktor 7 schneller gerechnet (fixed point). Bei 48 MhZ (die theoretische Grenze, praktisch 68) war das der Faktor 17!! Dazu der 20 mal schnellere ADC, wobei ich erstmalig Averaging (8 samples) einführen konnte, um auf echte 12 Bit zu kommen, denn die Genauigkeit ohne liegt bei 10.5 Bits. Logisch, denn der ADC arbeitet in einer EMV Hölle. Nun bin ich beim STM32L431 gelandet, weil mir die Doku von Atmel nicht gefallen hat, wobei ST mich auch nicht gerade vom Stuhl haut, besonders beim ADC, sehr kompliziert beschrieben. Will dann auf Floating point umsteigen, kann es mir ja nun leisten dank FPU. Und da der STM32 vollgestopft ist mit Peripherie, bin ich noch lange beschäftigt. Besonders der geschätzt 4 mal größere Assemblerbefehlssatz wird interessant, gigantisch gegenüber dem M0+. Gruß Uwe
Uwe M. schrieb: > Hallo Gerhard! > > Also der M0+ im SAMD10 hat bei gleicher Taktfrequenz die 32 Bit > Berechnungen um den Faktor 7 schneller gerechnet (fixed point). Bei 48 > MhZ (die theoretische Grenze, praktisch 68) war das der Faktor 17!! Dazu > der 20 mal schnellere ADC, wobei ich erstmalig Averaging (8 samples) > einführen konnte, um auf echte 12 Bit zu kommen, denn die Genauigkeit > ohne liegt bei 10.5 Bits. Logisch, denn der ADC arbeitet in einer EMV > Hölle. > > Nun bin ich beim STM32L431 gelandet, weil mir die Doku von Atmel nicht > gefallen hat, wobei ST mich auch nicht gerade vom Stuhl haut, besonders > beim ADC, sehr kompliziert beschrieben. Will dann auf Floating point > umsteigen, kann es mir ja nun leisten dank FPU. Und da der STM32 > vollgestopft ist mit Peripherie, bin ich noch lange beschäftigt. > Besonders der geschätzt 4 mal größere Assemblerbefehlssatz wird > interessant, gigantisch gegenüber dem M0+. > Gruß > > Uwe Hallo Uwe, Interessant. Mit den SAMs habe ich noch nicht gearbeitet. Habe nur Erfahrung mit älteren NXP ARM7TDI, LPC1788 und STM32F1/F4. Ja, die Doku ist bei ST auch nicht immer hilfreich. Mit welchen Werkzeugen arbeitest Du übrigens? Ich arbeite mit ST TrueStudio. Ein STM32F1 schaffte die Berechnung eines faktorisierten, optimiertes Thermocouple Polynomial 9ter Ordnung in nur 14us bei 36 MHz. Das ist nützlich wenn man mit ITS-90 NIST Koeffizenten aller gängigen TC Typen arbeiten will. Jedenfalls kann man mit diesen 32-bit uC Familien viel machen. Ich mag sie ganz gerne. Grüße, Gerhard
Uuufff... 80MHz PWM um eine Bisschen zu Entladen, .. und sich Sorgen um Jitter machen... Dann noch ein paar Floatingpoints durchstampfen ... Krass.
Gerhard O. schrieb: > ITS-90 NIST Koeffizenten aller gängigen TC Typen Moin Gerhard! Das oben Zitierte sagt mir leider nichts. TC Typen? Beim SAM habe ich mit Amel Studio gearbeitet, hat sofort funktioniert, auch das Debugging. Allerdings ein Resourcenkiller, basiert auch auf Eclipse. Auf einem zweikernigen Intel Atom ein Geduldsspiel. Man muß noch Microsofts .NET Framework libriaries installieren. Wenn du Linux auch noch auf der Platte hast, wird es ein Kampf. Beim STM32 arbeite ich mit STM Workbench von AC6. Das habe ich recht schnell zum laufen bekommen im Gegensatz zum Atollic Studio, wo es Probleme gab mit dem Debuggen. Mit dem STM32L431 will ich einige Projekte machen, wo ich im us Bereich die Zeit messen muss (Motorsteuerung für Teleskopmontierung), aber auch die genialen Stromsparfähigkeiten des uC ausreizen werde. War halt auf der Suche nach einem Universaltypen, mit dem ich viel erschlagen kann. Sicherlich bei einigen Sachen Overkill, aber bei dem Preis (gut 3 €) Peanuts. Habe halt keine Lust, für jedes Projekt mich in einen anderen uC einzuarbeiten. Daher dient das jetzige Projekt rein zum kennenlernen des uCs, bevor es nächstes Jahr anspruchsvoll wird.ST uCs gefallen mir gut, eine vollgestopfte Wundertüte mit Peripherie. Da kann man lange für Treiber schreiben. Auf CMSIS und so etwas verzichte ich.
:
Bearbeitet durch User
Klonophon schrieb: > und sich Sorgen um > Jitter machen Fehlt dir das Vorstellungsvermögen, einen uC für mehrere Projekte einzusetzen? Diesbezüglich habe ich nämlich klare Pläne! Aber wahrscheinlich setzt du für jedes Projekt einen maßgeschneiderten uC ein, ich dagegen nicht!
Uwe M. schrieb: > Auf CMSIS und so etwas verzichte ich. O.m.g. CMSIS ist immer mit im Boot. Und du hast es noch nicht gemerkt. Da schlägt wieder die volle Qualifikation durch. Uwe M. schrieb: > bevor es nächstes Jahr anspruchsvoll wird
OMG schrieb: > Da schlägt wieder die volle Qualifikation durch. Deine Qualifikation bestimmt! Ich nutze keine CMSIS Funktionen, um auf Register zuzugreifen, bestimmte Eigenschaften der Peripherie zu nutzen, denn ich will unabhängig sein, sprich nicht suchen, wie mache ich dies und jenes mit CMSIS. Und nur die Namen der Register und Bits zu verwenden, das ist nur ein winziger Bruchteil von CMSIS!
:
Bearbeitet durch User
Uwe M. schrieb: > Daß man z.B. den Quarzoszillator (HSE) nicht > zu den Timern routen kann, kommt mir komisch vor Hast Du mittlerweile herausgefunden, daß es ganz einfach geht?
m.n. schrieb: > Hast Du mittlerweile herausgefunden, daß es ganz einfach geht? Nein, ich lasse mir aber gerne konstruktive Ratschläge geben....... Außen rum (über Port) hatte ich ja schon erkannt. Das Blockschaltbild im Reference Manual gibt keine Auskunft.
:
Bearbeitet durch User
Uwe M. schrieb: > Damit > erben die Timer aber auch den Jitter von 50-60 ps (bei 80 MHz), was > knappe 0.5% Frequenzungenauigkeit bedeutet. Uwe M. schrieb: > Wenn eine Flanke verfrüht oder verspätet kommt, > ändert sich doch die Zeit, und folglich die Frequenz, da die Frequenz > eine Funktion der Zeit ist. Ich erbitte Erklärung! Uwe M. schrieb: > Wenn du meinen Beitrag verstanden hättest Bevor hier das gegenseitige Dreckschleudern so richtig losgeht, würde ich dir empfehlen, mal etwas gründlicher nachzudenken. Also: Ein µC ist im Allgemeinen ein getaktetes System. Das macht auch an den Pins des Chips nicht halt. Merke dir also, daß alle Signale, die die Innereien des µC von der Außenwelt zu sehen bekommen, niemals die Signale selbst sind, sondern es sind Samples der Außenweltsignale. Und diese Samples werden mit dem zugehörigen Takt erzeugt. Ob das nun der AHB-Takt ist oder einer der üblicherweise niedrigeren APB-Takte oder ggf. etwas noch niedrigeres (chipabhängig), ist für's Verständnis eigentlich egal. Du hast nämlich IMMER die Ungewißheit von einer ganzen Taktperiode des betreffenden Taktes, mit dem diese Samples erzeugt werden. Und wenn dein schnellster Takt eben 12.5 ns schnell ist, dann hast du in jedem Falle auch für alle Timer und Counter in deinem Chip eine Zeitunsicherheit von 12.5 ns und all deine Überlegungen über Jitter sind schlichtweg gegenstandslos. W.S.
OMG schrieb: > CMSIS ist immer mit im Boot. Und du hast es noch nicht gemerkt. > > Da schlägt wieder die volle Qualifikation durch. Ähemm... da schlägt sie eher zurück auf dich. Ich z.B. verwende CMSIS nicht und da ist auch nix davon im jeweiligen Projekt - weder explizit noch implizit. Ich nehme mal an, daß du in der Art programmierst, wie man es üblicherweise den Anfängern andressiert hat: Die IDE vom Hersteller verwenden, alle Supportfiles vom Hersteller verwenden, Code sich vom Tool des Herstellers generieren lassen. Falls diese meine Annahme nicht zutreffen sollte, kannst du ja mal erklären, wie du dann auf obige Aussage gekommen bist. W.S.
Da sieht man doch einen Umschalter mit dem HSE an die PLL gelegt werden kann. Die betreffenden Bits sind unter PLLSRC im Register RCC_PLLCFGR einzustellen. Zuvor müssen allerdings HSE aktiviert (HSEON) und stabil (HSERDY) sein. Zudem muß die PLL konfiguriert werden und wenn dann alles läuft (PLLRDY), die PLL als Systemclock eingeschaltet (PLLON) werden Das betreffende Register ist RCC_CR. Da ist im Grunde bei allen STM32 so. OMG schrieb: > CMSIS ist immer mit im Boot. Und du hast es noch nicht gemerkt. Auch das ;-)
W.S. schrieb: > kannst du ja mal erklären, wie du dann auf obige > Aussage gekommen bist. Gerne doch! Die IDE des Herstellers nehme ich, klar, das ist aber alles. Daß man mit Pointern auf I/O Register zugreifen kann, dürfte unstreitig sein, dazu braucht man nicht unbedingt CMSIS Funktionen. Über den Sinn von CMSIS und Co. wurde vor kurzem hier übrigens diskutiert. Da ich auf lesbaren Code stehe, habe ich mir z.B. Funktionen geschrieben wie write_io_reg32(). Beispiel: write_io_reg32(RCC_CR,OFF,PLLON,1); //PLL off mit den Parametern Registeradresse (=Name), Daten zum schreiben, Bitpositione und Bitfeldbreite. Was ich vom Hersteller verwende, sind lediglich die Originalnamen, fertig. Wo es schnell gehen muss, etwa ADC Abfragen, gehe ich direkt mit einem Pointer auf die Register unter Verwendung der Originalnamen. In den 90er Jahren gab es noch kein betreutes Denken für Ingenieure, und das hat nichts mit Anfängerstatus zu tun, diese Arroganz erspare dir bitte. Die Leute konnten noch selbstständig arbeiten, was ich bei den heutigen Diplomanten oft vermisse! Damals musste man nicht krampfhaft nach Funktionen oder Macros suchen, die etwas bewirkten. Ausnahme: Bei komplexen Schichtenmodellen wie Canbus muss man komplette Tools (Libraries) einbinden, etwa damals von Vector. Meine Philosophie ist: Was man selber machen kann vom Aufwand her gesehen, auch selber programmieren für maximale Transparenz. Ich habe mich einmal im Codedschungel von ASF fast zu Tode gesucht, weil etwas nicht funktionierte, seitdem liebe ich die Unabhängigkeit. Und meine Philosophie muss ich auch nicht rechtfertigen! Und ob man solche Leute als Profis bezeichnen kann, die fertige Funktionen brauchen zum initialisieren von Registern, möchte ich nicht diskutieren. Generell mag ich kein betreutes Denken, der heutige Trend.
:
Bearbeitet durch User
m.n. schrieb: > Da sieht man doch einen Umschalter mit dem HSE an die PLL gelegt werden > kann. Darum geht es nicht. Meine PLL, versorgt durch geteilten HSE läuft prima, konnte man in eienr STunde programmieren, da gut beschrieben. Was gemeint war, ich kann nicht die Timer mit dem HSE versorgen, während der Core mit PLL läuft. Core und Timer bekommen immer dieselbe Quelle.
:
Bearbeitet durch User
Uwe M. schrieb: > Was > gemeint war, ich kann nicht die Timer mit dem HSE versorgen, während der > Core mit PLL läuft. Ach so! Deine Eingangsfrage war ein wenig anders. Es ginge auch noch HSE direkt als Sysclock für CPU und Timer, aber wenn das auch stört muß man in der Tat ein externes Signal als Timertakt verwenden. Böse dabei ist, daß alle Zugriffe auf die Timer auf den Systemtakt synchronisiert werden müssen - einschließlich Jitter. Mit völliger Freiheit ist hier wieder Schluß ;-)
Hallo m.n.! Wenn ich Timer und core mit HSE antreibe komme ich auf maximal 48 MHz, wobei ich nicht weiß, gibt es Grundtonquarze mit 48 MHz, dürfte schwierig sein. Sicherlich wäre Synchronisierung bei unterschiedlichen Frequenzen und Phasen ein großes Thema, nur habe ich das Gefühl, daß der STM32 das intern automatisch machen würde, habe nämlich noch keine Synchronisierungsbits gesehen, habe aber auch noch nicht alle 1600 Seiten durch. :-) Bisher läuft auch alles auf einer Fequenz.
:
Bearbeitet durch User
Uwe M. schrieb: > Wenn ich Timer und core mit HSE antreibe komme ich auf maximal 48 MHz, > wobei ich nicht weiß, gibt es Grundtonquarze mit 48 MHz, dürfte > schwierig sein. Du nimmst einfach einen Quarzoszillator für HSE statt einem Quarz. Die gibt es problemlos in 48 MHz. > Sicherlich wäre Synchronisierung bei unterschiedlichen > Frequenzen und Phasen ein großes Thema, nur habe ich das Gefühl, daß der > STM32 das intern automatisch machen würde Lies Dir den Post von W.S. oben nochmal genau durch: Die Timer sind alle auf den Takt ihres Busses getaktet. Also selbst wenn Du den Timer mit einem externen Takt versorgst, wird dieser immer mit dem internen Core/Bus-Takt des µC gesampelt. Das siehst Du auch in den entsprechenden Timing-Diagrammen im Reference Manual wenn Du Dir die genau anschaust. Wenn das nicht so wäre, würde der Timer asynchron zu dem Rest des µC laufen. Das würde den Zugriff auf Register etc. wesentlich komplexer machen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.