mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche einen Arm Cortex M0+ oder M3 Board mit einer MPU


Autor: int 21h (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32F2xx wie der STM32F205 haben eine MPU.
Oder darfs auch nen M4 sein?
Dann die STM32F4xx Reihe.

Autor: fsdf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> [...] 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 ...

Autor: Nils P. (torus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: foobar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Ö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 ;-)

Autor: Nils P. (torus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: moep (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nils P. (torus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.