Suche einen Arm Cortex M0+ oder M3 Board mit einer MPU

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

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.

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.

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.

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.

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.