Moin, da so gut wie alle Arm Cortex M0+ µC keine MPU integriert haben, werde ich wahrscheinlich doch auf einen M3 zurückgreifen müssen. Aber alle die ich mir bis her angeschaut habe (Datenblätter) haben keine Memory Protection Unit integriert. Ich möchte nämlich irgendwann demnächst von AVR8 auf die Arm Architektur umsteigen und suche dafür ein geeignetes Board (Am besten ein billiges aus China), dass eine MPU integriert hat, da diese bei Betriebssystemen und TCP/IP von großer Bedeutung ist.
STM32F2xx wie der STM32F205 haben eine MPU. Oder darfs auch nen M4 sein? Dann die STM32F4xx Reihe.
dann nimm einen M4 oder M7 die haben oft MPU und sind deutlich schneller und auch mehr features gerade bei IP und ggf TLS/SSL
fsdf schrieb: > dann nimm einen M4 oder M7 Würde ich genau so sagen. Atmel bzw. Microchip hat die SAM4 Reihe bzw. die SAME7x, SAMS7x, SAMV7x. Da müsstest mal schauen. Der M4 (SAM4E) hat eine MPU, falls es nicht unbedingt gleich ein M7 sein muss. edit: M4 Core ist der Nachfolger vom M3... Somit würde ich lieber im neueren Bereich schauen.
:
Bearbeitet durch User
Die M7 sind dann doch meist etwas zu kompliziert für den Einstieg von AVR her. Der M4 ist nicht der Nachfolger des M3. Sondern ein M3 Kern mit DSP und FPU Erweiterungen Zu den STM32F4 gibts auch künstige DevBoards, die Discoverys zB STM32F407 Discovery oder STM32F411 Discovery.
:
Bearbeitet durch User
> [...] da diese [Memory Protection Unit] bei Betriebssystemen und TCP/IP von
großer Bedeutung ist.
Wie kommst du auf den Trichter? Bei nem kleinen Mikrocontroller ist ne
MPU ziemlich überflüssig. Was sollte sie da erledigen? Die laufen meist
eh mkt ner festen Anwendung ohne OS und was TCP/IP mit ner MPU soll ...
foobar schrieb: > Wie kommst du auf den Trichter? Bei nem kleinen Mikrocontroller ist ne > MPU ziemlich überflüssig. Was sollte sie da erledigen? Die laufen meist > eh mkt ner festen Anwendung ohne OS und was TCP/IP mit ner MPU soll ... Öhm, mir fällt da einiges ein: - Stack Overflows erkennen via Guard-Pages - Null Pointer Zugriffe erkennen - Speicherschutz bei verwendung von RTOS Threads Mit TCP/IP hat das aber nicht viel zu tun, das sehe ich genau so.
> Öhm, mir fällt da einiges ein: > > - Stack Overflows erkennen via Guard-Pages > - Null Pointer Zugriffe erkennen > - Speicherschutz bei verwendung von RTOS Threads Und dann? Die Anwendung killen und beten, dass sie das in Zukunft nicht wieder macht? Warum sollte sie? Das sind doch alles Programmierfehler und die müssen gefixt werden. Ich bleibe dabei: die Bedeutung von MPUs auf kleinen Mikrocontrollern geht gegen Null. Und das scheinen die Hersteller ähnlich zu sehen ;-)
foobar schrieb: > Und dann? Die Anwendung killen und beten, dass sie das in Zukunft nicht > wieder macht? Warum sollte sie? Das sind doch alles Programmierfehler > und die müssen gefixt werden. Genau, und wie finde ich die Fehler in der Entwicklungszeit? Am besten doch so durch eine harte Exception der MCU. Und im Produkt ist eine MCU für z.B. Stackoverflow Schutz auch nützlich. Beispiel aus der Robotik. Sollte es beim Kunden trotz aller Bemühungen fehlerfreien Code abzuliefern doch mal zu einem Überlauf kommen, welches Verhalten würdest Du Dir wünschen? a) Roboter läuft Amok und hackt dem Benutzer eine Hand ab. b) Roboter schaltet sauber die Motoren aus und signalisiert den Fehler über eine blinkende Status LED. Letzteres Verhalten lässt sich relativ einfach über die MPU in z.B. einem Cortex-M3 implementieren weil Du einen Stackoverflow erkennst bevor undefiniertes Verhalten auftreten kann. Mit Stack Probing und ähnlichen Techniken bekommst Du es erst dann mit, wenn das Kind bereits in den Brunnen gefallen ist.
Nils P. schrieb: > Beispiel aus der Robotik. Wenn du eine Steuerung für einen kollaborativen Roboter entwickelst der genug Kraft aufbringen kann dir "eine Hand abzuhacken" musst du die vermutlich sowieso mindestens nach SIL2 entwickeln. Da ist es dann mit ein bisschen Stackoverflow-Schutz nicht mehr getan.
Das war ja auch ein Beispiel, welches ich humorig Zuspitzen wollte. Hat offensichtlich nicht geklappt. Worauf es mir ankommt: Die meisten Cortex-M3 haben die MPU eingebaut. Es dauert meist nicht mal einen Tag sie zum Laufen zu bringen, also warum die MPU nicht aktivieren und von dem zusätzlichen Schutz profitieren?
FreeRTOS kann die MPU ja sogar nutzen um einzelne Threads voreinander zu schützen. https://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html Ich weis hier echt nicht wieso hier jemand meint die MPU sei unnütz... TCP/IP kannste damit nicht direkt schützen, aber die Anwendung die darauf aufbaut. Bei der Entwicklung der Anwendung übersieht man dann doch eine Möglichkeit von kauderwelsch vom Netzwerk und die Anwendung stürzt ab. Das kann der Faulthandler dann wunderbar loggen. Vor sowas sind ja nichtmal die openSSL Entwickler sicher. Unvorhergesehende Stackoverflows kommen nach der Entwicklungszeit/Testzeit auch mal vor und dann soll auch bitte alles stillstehen: https://formal.iti.kit.edu/~beckert/teaching/Seminar-Softwarefehler-SS03/Ausarbeitungen/bertram.pdf Die anderen Fehlerfälle wurden schon genannt. Der Cortex-M Fault fliegt einem dann sogar direkt mit einem Stackerror Bit um die Ohren!
Nils P. schrieb: > foobar schrieb: >> Und dann? Die Anwendung killen und beten, dass sie das in Zukunft nicht >> wieder macht? Warum sollte sie? Das sind doch alles Programmierfehler >> und die müssen gefixt werden. > > Genau, und wie finde ich die Fehler in der Entwicklungszeit? Am besten > doch so durch eine harte Exception der MCU. Genau so, und mit einem Hard Fault Handler, der die Fault Status Register dekodiert und ausgibt. Die Cortex-M sagen dir dann ganz genau, was wo passiert ist. Und zwar, bevor auch nur ein weiterer Maschinenbefehl ausgeführt wird. MPU und Hard Fault Handler waren ungefähr das erste, was ich auf Cortex-M programmiert hab, direkt nach der Blink-LED. Probiert es, es lohnt sich. Gerade zu Anfang, wenn man noch Fehler macht ;) Übrigens haben die M0+ aus der STM32L-Familie fast alle eine MPU.
Mw E. schrieb: > Der M4 ist nicht der Nachfolger des M3. > Sondern ein M3 Kern mit DSP und FPU Erweiterungen OK, Nachfolger war ein falscher Begriff...Es ist ein erweiterter M3.
int 21h schrieb: > da so gut wie alle Arm Cortex M0+ µC keine MPU integriert haben, werde > ich wahrscheinlich doch auf einen M3 zurückgreifen müssen. > Aber alle die ich mir bis her angeschaut habe (Datenblätter) haben keine > Memory Protection Unit integriert. Oder brandneu STM32G0-Familie. Die haben obendrein eine ganz fixe GPIO-Anbindung, da sehen die anderen STM32 teilweise recht alt gegen aus.
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.