Servus! 32, 64, 128, 256 oder 512 Worte? Andere Werte kommen garnicht in Frage. Die M4-CPU kann ziemlich sicher max. 240 Interrupts,, die M7 evt. mehr. Aber real sind vielleicht nur 50 oder 100 auf dem Chip verdrahtet. Muss die Tabelle trotzdem 256 Worte groß sein? Zur Laufzeit kann man das im ICTR nachlesen, aber dann ist zu spät. In den pdfs von ST wird dieses Register nicht einmal erwähnt. Die Angaben zu den verdrahteten Interrupts sind widersprüchlich (z.B. 67 vs 84). Außerdem nützt diese Zahl nichts weil die CPU ja trotzdem voll ausgebaut sein kann. Doku von ARM hilft hier auch nicht, das ist implementation defined. Kann man das irgendwo nachlesen? Warum will ich das unbedingt richtig machen, es geht doch auch so? Sind 512 gesparte Flash-Bytes den Stress wert?
Beantworte dir mal die Frage selbst. Wenn der Core maximal 120 Einträge der Tabelle auslesen würde bei aktiver Interrupt-Bearbeitung ist es notwendig Flash für 240 Einträge zu reservieren. Am wichtigsten ist in der Tabelle der Stack-Pointer und der Reset-Point. Alles andere kann sonstwo liegen da beim Reset noch kein IRQ-Handling (Mal von NMI etc. abgesehen) an ist. Der beliebte STM32F103C8T6 hat 76 (16+60) (0-0x12F) Einträge. ST beschreibt das ja jeweils zum passenden µC ausreichend. "10 Interrupts and events" im "RM0008 Reference manual".
:
Bearbeitet durch User
Dennis H. schrieb: > Beantworte dir mal die Frage selbst. Wenn der Core maximal 120 > Einträge der Tabelle auslesen würde bei aktiver Interrupt-Bearbeitung > ist es notwendig Flash für 240 Einträge zu reservieren. Einverstanden, und wie schaut es aus, wenn es 100 statt 120 wären? Das ist hier die Frage. > Am wichtigsten ist in der Tabelle der Stack-Pointer und der Reset-Point. Notfalls könnte ich auch noch auf SP verzichten ;) > Der beliebte STM32F103C8T6 hat 80 (13+67) Einträge. > ST beschreibt das ja jeweils zum passenden µC ausreichend. > "10 Interrupts and events" im "RM0008 Reference manual". Ja, früher war alles viel besser. Bei den aktuellen Chips finde ich nichts dazu, nicht einmal beim F205.
Bauform B. schrieb: > Servus! > 32, 64, 128, 256 oder 512 Worte? Andere Werte kommen garnicht in Frage. > Die M4-CPU kann ziemlich sicher max. 240 Interrupts,, die M7 evt. mehr. > Aber real sind vielleicht nur 50 oder 100 auf dem Chip verdrahtet. Muss > die Tabelle trotzdem 256 Worte groß sein? STM32F4: RM0090 Table 61 Ansonsten: Beispiele für Bootloader bzw. Ausführung aus dem SRAM
Bauform B. schrieb: > Bei den aktuellen Chips finde ich > nichts dazu, nicht einmal beim F205. RM0033 Rev 8 ab Seiten 164: https://www.st.com/content/ccc/resource/technical/document/reference_manual/51/f7/f3/06/cd/b6/46/ec/CD00225773.pdf/files/CD00225773.pdf/jcr:content/translations/en.CD00225773.pdf
Bereitstellen muß man maximal was der NVIC an Vektoren überhaupt kann und minimal bis zum höchsten, den man davon auch benutzt. Ob an der Stelle, die die Hardware nie benutzt kein Vektor steht oder Code oder Konstanten, das ist der Hardware egal. Das ist einfach Flash, auf den das "VektorBasisRegister" zeigt und zwar an einer nach Reset bekannten Stelle. Wenn da dann Blödsinn steht, dann hat der ARM-Kern die Möglichkeit darauf mit Hardfault zu reagieren, oder eben "stehen zu bleiben", wenn auch der Hardfault-Vektor nicht benutzbar ist.
Eins muss ich zugeben. Es ist nachteilig das ST nicht ihre ganzen Spezifikationen der Cortex-M-Serie in eine einzige PDF geschrieben hat. Aber man sollte nicht behaupten das es da garnicht zum Nachlesen gibt. Wenns nicht im "Reference Manual" oder "Programming Manual" steht gibts immernoch "The Definitive Guide to ARM Cortex*" und "Arm architecture reference manual".
Angehängte Dateien:
-
Blockschaltbild.png
65 KB
Irgend W. schrieb: > RM0033 Rev 8 ab Seiten 164: Marcus H. schrieb: > STM32F4: RM0090 Table 61 > Ansonsten: Beispiele für Bootloader bzw. Ausführung aus dem SRAM In den Tabellen stehen doch nur die Interrupts, zu denen es auch Peripherie gibt. Das sagt aber nicht, wieviele "Lines" die CPU auswertet, also wie groß die Tabelle sein muss. Und Beispiele liefern Ideen und Hinweise, aber keine Fakten. Carl D. schrieb: > Bereitstellen muß man maximal was der NVIC an Vektoren überhaupt > kann und minimal bis zum höchsten, den man davon auch benutzt. Ob > an der Stelle, die die Hardware nie benutzt kein Vektor steht oder > Code oder Konstanten, das ist der Hardware egal. Na klar, nur sterben muss man. Mir ist aber nicht egal, was die Hardware macht. > Das ist einfach Flash, auf den das "VektorBasisRegister" zeigt und zwar > an einer nach Reset bekannten Stelle. Wenn da dann Blödsinn steht, dann > hat der ARM-Kern die Möglichkeit darauf mit Hardfault zu reagieren, oder > eben "stehen zu bleiben" oder beliebigen Blödsinn zu machen. Wenn da zufällig der Befehl 0x0800a2b1 steht gibt's eine Schnellabschaltung, aber bei vielen Bitkombinationen passieren viel lustigere Sachen :) Dennis H. schrieb: > Eins muss ich zugeben. Es ist nachteilig das ST nicht ihre ganzen > Spezifikationen der Cortex-M-Serie in eine einzige PDF geschrieben hat. > > Aber man sollte nicht behaupten das es da garnicht zum Nachlesen gibt. Nicht "nicht gibt", ich finde nur nichts. > Wenns nicht im "Reference Manual" oder "Programming Manual" steht gibts > immernoch "The Definitive Guide to ARM Cortex*" Den hab' ich sogar als Buch aus toten Bäumen, aber da kann ja kaum drin stehen, was ST jetzt bei einem bestimmten Chip einbaut. > und "Arm architecture reference manual". Da steht ganz klar drin: Die M4-CPU kann min. 32 und max. 240 Interrupts, für die tatsächliche Anzahl fragen Sie ihren Chip-Hersteller oder ihr Forum. Bei ARM ist eben alles optional (siehe oben) bis auf den NVIC und zum Ausgleich hat der eben optional viele Eingänge.
:
Bearbeitet durch User
Bauform B. schrieb: > In den Tabellen stehen doch nur die Interrupts, zu denen es auch > Peripherie gibt. Das sagt aber nicht, wieviele "Lines" die CPU > auswertet, also wie groß die Tabelle sein muss. Die Tabelle enthält sämtliche Interrupts, die passieren können. Damit ist die Länge dieser Tabelle auch zugeich das, was Du für diesen Chip maximal vorsehen mußt. Oder was sollen sonst für Interrupts noch kommen? Und woher sollen die kommen?
Nop schrieb: > Oder was sollen sonst für Interrupts noch kommen? Die, die nicht in der Tabelle stehen. Hört sich blöd an, ist es auch, aber der NVIC hat entweder 32 oder 64, 96 usw. Eingänge. Wenn laut Tabelle z.B. 80 belegt sind, bleiben noch 16 bis 160, die man per NVIC_STIR (Software Trigger) oder direkt per NVIX_ISPR auslösen kann. > Und woher sollen die kommen? Vom halbfertigen Programm? Die Cortex-M bieten wirklich nette Möglichkeiten die Fehlersuche zu vereinfachen und die möchte ich auch nutzen.
Bauform B. schrieb: > Vom halbfertigen Programm? Die Cortex-M bieten wirklich nette > Möglichkeiten die Fehlersuche zu vereinfachen und die möchte ich auch > nutzen. Fehlersuche vereinfachen in dem man angenommene, undokumentierte, Features nutzt? Ist das nicht ein wenig so als würde man für die Jungfräulichkeit vögeln?
Bauform B. schrieb: > In den Tabellen stehen doch nur die Interrupts, zu denen es auch > Peripherie gibt. Das sagt aber nicht, wieviele "Lines" die CPU > auswertet, also wie groß die Tabelle sein muss. Und Beispiele liefern > Ideen und Hinweise, aber keine Fakten. Nö, Beispiel F205 16 ARM-Irq (0x00000000 bis 0x0000003F) 81 STM-IRQ (0x00000040 bis 0x00000183) = 194 words -> Somit ist das nächstgelegene "power of two" 256 Wobei ich mir hier nicht sicher bin ob das mit dem "power of two" nicht nur für das aligment gilt wenn eine offset benutzt wird: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABIFJFG.html Deine Frage sollte eher lauten wie groß darf die Tabelle den sein über das eigentlich benötigte hinaus. "Groß sein" muss sie für 97 Einträge und nicht mehr. Was anderes kann regulär garnicht auftreten (irgendwelche Softwarebasteleien auf Registerebene zählen da nicht dazu). Du willst ja anscheinend bei 0x00000184 quasi eine Nummer 82 definieren. oder? Ob es auch mehr sein dürfen, darüber STM läst sich jedenfalls an keine Stelle aus. Ob es überhaupt möglich ist eine Interrupt außerhalb des definierten Bereichs anzusprechen bzw. was passiert wenn man es dennoch versucht ist nirgends festgelegt. Wenn es zufällig funktioniert (logischer wäre eigentlich eher ein hard fault) ist es jedenfalls etwas worauf STM anscheinend "Garantie" gibt (außer es findet noch jemand einen gut versteckt Hinweis).
Bauform B. schrieb: > Hört sich blöd an, ist es auch In der Tat. > Vom halbfertigen Programm? Wenn ein "halbfertiges" Programm sowas tut, sollte man vielleicht mal den Rauschgenerator durch einen Compiler ersetzen. Ansonsten ist das ein Fall von PEBKAC, wo auch keine aufgeblasene Interupttabelle hilft. Kurzum: Das ist ein non-issue.
Vor zwei Jahren hab ich mal für einen Bootloader die Vektortabelle
komplett weggelassen (bis auf Initial Stack und Reset) um noch ein paar
hundert Bytes rauszukitzeln und einen kostbaren Flash-Sektor einsparen
zu können (war ein kleiner M0+ mit nur 8k Flash). Also auch das geht
problemlos.
Jedoch nicht existierende(!) Interrupts in einer länger als nötigen
Vektortabelle aufzuführen (nur um dann 0 reinzuschreiben), das würd mir
selbst auf dem dicksten Controller nicht einfallen. Wozu auch um alles
in der Welt?
Normalerweise hat man einen passenden Startupcode für diese MCU (meist
vom Hersteller) und den benutzt man immer und immer wieder und der
funktioniert. Es ist zwar löblich zu versuchen sich das alles mal selbst
zu erarbeiten und mal selbst zu schreiben (also tu das!) aber am Ende
wird man wenn man alles richtig gemacht hat zwangsläufig wieder bei
einer Konstellation landen die dem ursprünglichen Code des Herstellers
verblüffend ähnlich sein wird und da wird auch kein Platz für nicht
existente Interrupts verschwendet.
Und sobald man einmal einen Startup selbstgeschrieben und von vorne bis
hinten verstanden hat hat man auch kein NIH-Syndrom mehr wenn man in
Zukunft einfach kurzerhand nur noch den fertigen Code vom Hersteller
nimmt weil man jetzt genau weiß daß da nichts mehr zu verbessern geht
und man es selbst auch kein bisschen anders gemacht hätte. Bestenfalls
noch einmal kurz reingeschaut, wohlwollend genickt ("ja, sieht normal
aus, das übliche.") und dann verwendet.
:
Bearbeitet durch User
Bei NXP LPCs brauchst Du mindestens die ersten 8 Einträge, weil an Position 7 (Offset 0x001C) eine Prüfsumme über die ersten 7 Vektoren steht.
Dennis H. schrieb: > Es ist nachteilig das ST nicht ihre ganzen > Spezifikationen der Cortex-M-Serie in eine einzige PDF geschrieben hat. Das geht gar nicht, da die Kerne unterschiedlich funktionieren und die Peripherie drumherum noch viel mehr.
Jürgen S. schrieb: > Bei NXP LPCs brauchst Du mindestens die ersten 8 Einträge, weil an > Position 7 (Offset 0x001C) eine Prüfsumme über die ersten 7 Vektoren > steht. Das war ein NXP (ehemals Freescale) Kinetis. Kinetisse haben keine solche Prüfsummen. Auch viele andere bekannte haben das nicht, auch STM32 hat das nicht.
:
Bearbeitet durch User
Bauform B. schrieb: > Nop schrieb: >> Oder was sollen sonst für Interrupts noch kommen? > > Die, die nicht in der Tabelle stehen. Hört sich blöd an, ist es auch, > aber der NVIC hat entweder 32 oder 64, 96 usw. Eingänge. Wenn laut > Tabelle z.B. 80 belegt sind, bleiben noch 16 bis 160, die man per > NVIC_STIR (Software Trigger) oder direkt per NVIX_ISPR auslösen kann. > Verzeih mir bitte, dass ich so kurz vor Weihnachten keine Zeit habe, einen Compiler anzuwerfen. Daher bin ich hier auf Deine Mithilfe angewiesen: Hast Du dieses Verfahren schon mal demonstrieren können? Auf welchem Chip? Magst Du uns ein Codebeispiel zeigen? Varianten die ich mir vorstellen könnte: - ist dauerhaft geblockt - springt immer in einen der bekannten Fault-Handler - funktioniert und springt an die erwartete Position einer erweiterten Vektortabelle
Irgend W. schrieb: > Wobei ich mir hier nicht sicher bin ob das mit dem "power of two" nicht > nur für das aligment gilt wenn eine offset benutzt wird: Das ist der entscheidende Tipp, Danke! Ich war sicher, dass das auch für die Größe gilt (für's alignment ja sowieso). Im ARM v7-M Architecture Reference Manual steht nämlich nur
1 | The Vector table must be naturally aligned to a power of two whose |
2 | alignment value is greater than or equal to (Number of Exceptions |
3 | supported x 4), with a minimum alignment of 128 bytes. |
Der Cortex-M Generic User Guide sagt es viel deutlicher:
1 | When setting TBLOFF, you must align the offset to the number of |
2 | exception entries in the vector table. The minimum alignment is |
3 | 32 words, enough for up to 16 interrupts. For more interrupts, adjust |
4 | the alignment by rounding up to the next power of two. For example, |
5 | if you require 21 interrupts, the alignment must be on a 64-word |
6 | boundary because the required table size is 37 words, and the next |
7 | power of two is 64. |
8 | See your vendor documentation for the alignment details of your device. |
Zumindest beim L451 passt das auch ganz genau. NVIC_ICTR ist 2, also wären vom NVIC her 96 Interrupts möglich. Der höchste benutzte Interrupt ist 84 und tatsächlich gibt es genau 85 NVIC_IP Register und das letzte NVIC_ISER hat nur 20 Bits. > Deine Frage sollte eher lauten wie groß darf die Tabelle den sein über > das eigentlich benötigte hinaus. Die darf natürlich beliebig viel größer sein, das ist einfach unbenutzter Speicherplatz. > Du willst ja anscheinend bei 0x00000184 quasi eine Nummer 82 definieren. > oder? Nein, neu definieren oder gar benutzen will ich da nichts. Ich war nur nicht sicher, ob die Interrupts knapp oberhalb (beim L451 85 bis 95) irgendwie getriggert werden könnten. Und für den Fall sollte da ein Handler eingetragen sein. Bernd K. schrieb: > Vor zwei Jahren hab ich mal für einen Bootloader die Vektortabelle > komplett weggelassen (bis auf Initial Stack und Reset) um noch ein paar > hundert Bytes rauszukitzeln und einen kostbaren Flash-Sektor einsparen > zu können (war ein kleiner M0+ mit nur 8k Flash). Also auch das geht > problemlos. Total normal, mit 8k würde ich das genauso machen; mit 512k denkt man auch mal an übergroße Vektortabellen... Nachdem das jetzt so gut ausgegangen ist: Dankeschön an alle!
Marcus H. schrieb: > Bauform B. schrieb: >> Nop schrieb: >>> Oder was sollen sonst für Interrupts noch kommen? >> >> Die, die nicht in der Tabelle stehen. Hört sich blöd an, ist es auch, >> aber der NVIC hat entweder 32 oder 64, 96 usw. Eingänge. Wenn laut >> Tabelle z.B. 80 belegt sind, bleiben noch 16 bis 160, die man per >> NVIC_STIR (Software Trigger) oder direkt per NVIX_ISPR auslösen kann. >> > > Verzeih mir bitte, dass ich so kurz vor Weihnachten keine Zeit habe, > einen Compiler anzuwerfen. Daher bin ich hier auf Deine Mithilfe > angewiesen: > Hast Du dieses Verfahren schon mal demonstrieren können? Nein. Ein L451 (siehe vorigen Beitrag) und ein F205 verhalten sich genau gleich, nur dass der höchste Interrupt beim F205 der 80er ist. Es gibt bei beiden im NVIC nur genau so viele Register und Bits wie nötig. Und ohne Enable-Bit sollte es nun wirklich keinen Interrupt geben, also braucht man auch keinen Handler-Eintrag. Ich wollte einen "reserved" Interrupt mittels NVIC_STIR triggern, aber das ging überhaupt nicht, auch nicht mit "normalen". Aber egal, vielleicht eine Forschungsaufgabe für Weihnachten.
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.