Hallo, die ganzen Arm Prozessoren werben ja mit einen Systickcounter. Was ist der Vorteil von diesem gegenüber einem normalen Timer. Weil der SysTick kann ja nur rauf und runter zählen und Interrupts auslösen. Wäre es nicht geschickter gewesen nochmals einen vollen Timer für den SysTick einzubauen? Danke schon mal für aufschlussreiche antworten.
Der Timer ist für den Taskwechsel im Betriebsystem vorgesehen und dafür ist er genau richtig, Zählt die Zeit und löst einen IRQ aus.
Der systick-Timer "gehört" ARM, normale Timer gehören dem Chip-Hersteller, das ist der entscheidende Unterschied. Theoretisch sollte der systick bei jedem Cortex-M gleich funktionieren, was man von normalen Timern ja wirklich nicht sagen kann. Praktisch scheitert die gute Idee an den umschaltbaren Taktfrequenzen und an den Header Files, die trotz CMSIS (oder gerade wegen?!) widersprüchlich sind und nicht zur Dokumentation passen (o.k., ich kenne nur ST).
Schaulus Tiger schrieb: > Praktisch scheitert die gute Idee an den umschaltbaren Taktfrequenzen Die Taktfrequenz soll gemäß CMSIS immer in einer globalen Variablen mit dem Namen SystemCoreClock stehen, wenn Du sie umschaltest sollst Du diese updaten. > und an den Header Files, die trotz CMSIS (oder gerade wegen?!) > widersprüchlich sind Und alles was den SysTick und dessen Konfiguration angeht steht in den core_cmXxxxx.h Headern und nicht in denen des Herstellers. > und nicht zur Dokumentation passen Bei ST passen die Header nicht zur Dokumentation? Ist das wirklich so?
In einem stm32f2xx.h steht z.B. (und damit hat sich "Standard" schon erledigt):
1 | /** @addtogroup Configuration_section_for_CMSIS
|
2 | |
3 | #define __Vendor_SysTickConfig 0 /*!< Set to 1 if different SysTick Config is used */
|
im zugehörigen core_cm3.h findet man:
1 | #ifndef __Vendor_SysTickConfig
|
2 | #define __Vendor_SysTickConfig 0
|
3 | #warning "__Vendor_SysTickConfig not defined in device header file; using default!"
|
4 | #endif
|
Die Warnung wäre ja wohl sinnvoller, wenn nicht der ARM-Standard benutzt wird. Die Register werden dann so definiert:
1 | typedef struct |
2 | {
|
3 | __IO uint32_t CTRL; /*!< Offset: 0x000 (R/W) SysTick Control and Status Register */ |
4 | __IO uint32_t LOAD; /*!< Offset: 0x004 (R/W) SysTick Reload Value Register */ |
5 | __IO uint32_t VAL; /*!< Offset: 0x008 (R/W) SysTick Current Value Register */ |
6 | __I uint32_t CALIB; /*!< Offset: 0x00C (R/ ) SysTick Calibration Register */ |
7 | } SysTick_Type; |
Das Programming manual PM0056 von ST nennt sie aber STK_CTRL usw. und im ARM v7-M Architecture Reference Manual heißen sie SYST_CSR, SYST_RVR, SYST_CVR und SYST_CALIB. Als Bonus enden die Bit-Definitionen mal auf "_Pos" und "_Msk" enden und mal nicht. Wobei "_Msk" ja sowieso etwas krank ist... Ich glaube, es gibt noch eine Variante, aber die finde ich jetzt natürlich nicht :(
Schaulus Tiger schrieb: > und damit hat sich "Standard" schon erledigt Wie "hat sich Standard erledigt" was meinst Du damit? Ich kann Dir nicht folgen. Was ist da nicht standardkonform? > Die Warnung wäre ja wohl sinnvoller, wenn nicht der ARM-Standard > benutzt wird. Wieso? Die Warnung kommt doch nur wenn es aus irgendeinem komischen Grunde überhaupt nicht definiert ist, nicht wenn es als 0 (default) definiert ist. > Die Register werden dann so definiert: > [...] Hab mal nachgeschaut bei mir, wahllos herausgegriffen, ein Freescale MKL05 (anderer Hersteller, anderer Cortex) da ist es exakt genauso definiert, vollkommen identisch. > Das Programming manual PM0056 von ST nennt sie aber STK_CTRL usw. > und im ARM v7-M Architecture Reference Manual heißen sie > SYST_CSR, SYST_RVR, SYST_CVR und SYST_CALIB. Würd ich melden (oder auch nicht, wahrscheinlich haben sie es eh schon selbst gemerkt und werden es irgendwann nachbessern) > Wobei "_Msk" ja sowieso etwas krank ist... Nicht unbedingt krank, vielleicht könnte man es lieber erbsenzählerisch nennen aber in letzter Konsequenz ist es nur konsequent. Ich habs selbst mal ne zeitlang so gemacht, bin aber für Einzelbits wieder davon abgekommen, das ist doch zu viel des Guten. Bei Gruppen von zusammengehörigen Bits definiere ich jedoch weiterhin jeweils ein XXXX_Pos, ein XXXX(x), ein XXXX_Msk und dann noch unter deren Zuhilfenahme alle sinnbehafteten Kombinationen XXXX_FOO, XXXX_BAR, XXXX_BLUB, etc...
Schaulus Tiger schrieb: > Der systick-Timer "gehört" ARM, normale Timer gehören dem > Chip-Hersteller, das ist der entscheidende Unterschied. Theoretisch > sollte der systick bei jedem Cortex-M gleich funktionieren, was man von > normalen Timern ja wirklich nicht sagen kann. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/Babieigh.html der systick counter gehört zur ARM-Architektur (M3/M4; M0 optional), was sonst so timer heisst ist wohl peripheral die ARM-Core Lizenznehmer auf Gutdünken mit implementieren. An Gründen wird Portierbarkeit zwischen OS angegeben, ich meine den systick auch als support fürs Profiling zu kennen. MfG,
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.