Cortex M4: NXP oder STM32?

Marcel schrieb:
> kleine sache: usb zeitschaltuhr und I/O's schalten
> via USB + mems sensor auslesen
Dafür brauchst du nimmer einen Cortex M4. Ein CM3 oder weniger reicht 
dafür locker aus.

Weniger = AVR + V-USB
          PIC18F + USB
          STM32 + USB
          jeder beliebige Controller + USB-UART



Gruß Oliver

Zwischen den kleinen STM32F1er und dem "dicken" STM32F4er ist der 
Preisunterschied unerheblich klein bei Kleinstückzahlen.

Der NXP hat weniger RAM und von dem STM's gibt es deutlich mehr 
Gehäusevariationen.

Daher: Nehme den STM32F417 und Du hast einen, den Du in den meisten 
Projekten wieder verwenden kannst.

Und ja, die anderen haben recht, man könnte auch kleinere CPU's nehmen, 
rein von der Geschwindigkeit her.
Ich vermute, Du brauchst den vielen RAM für die Messaufgabe.

Aber bedenke: zwischen einem STM32F1xx und STM32F2xx/F4xx hat ST die 
Pheriperie deutlich verbessert und das Programm kann nicht mehr 1:1 
kopiert werden. Daher ist der STM32F2xx/F4xx keine schlechte Wahl.

Ich nehme auch den STM32F4xx, auch für "Mini-Projekte" weil ich einfach 
mir einmal Software schreibe und die immer wieder verwenden möchte.
Und sollte ich mal mehr brauchen, der hat das alles einfach schon drin 
;-)

PS: bei EBV gibt es die am günstigsten.

>Mit einem M4 zu beginnen, könnte einigen Frust nach sich ziehen...

Nenne mal ein Beispiel für diese Aussage. Ständig lese ich das aber nie 
gibt es handfeste Beweise dafür.
Bei Neueinsteiger gibt es mindestens genau so viel Frust bei den AVR's, 
siehe die vielen Threads.

Markus Müller schrieb:
>>Mit einem M4 zu beginnen, könnte einigen Frust nach sich ziehen...
>
> Nenne mal ein Beispiel für diese Aussage. Ständig lese ich das aber nie
> gibt es handfeste Beweise dafür.
> Bei Neueinsteiger gibt es mindestens genau so viel Frust bei den AVR's,
> siehe die vielen Threads.

Das kann ich bestätigen.

Ich arbeite mich gerade in die STM32-Reihe ein und bin mit der 
mitgelieferten Doku, den Beispielen und Evaluations-Kits (hier 
STM32F4-Discovery) wirklich zufrieden.

Der Umstieg (von AVR) fällt nicht wirklich schwer, zumal die 
Linux-Unterstützung + Eclipse durchaus brauchbar ist.

Aber natürlich sieht man anfangs den Wald vor lauter Bäumen nicht: 
Timer, DMA und Takte ohne Ende

Da hilft nur der klassiche Einstieg: LED blinken lassen :-)

Begeistert bin ich von den DMA-Fähigkeiten. man kann damit schon fast 
alles erschlagen und der Kern dreht immer noch Daumen :-)

Chris D.

frame schrieb:
> Den NXP kann man für Unerfahrene nicht empfehlen.

Es handelt sich hier wohl nicht nicht um einen Einsteiger, sondern einen 
Umsteiger.

Du weiß aber schon, dass das RM0008 das falsche Guide für den STM32F4xx 
ist. Drucke besser das RM0090 aus.

Chris D. schrieb:
> Da hilft nur der klassiche Einstieg: LED blinken lassen :-)
>
> Begeistert bin ich von den DMA-Fähigkeiten.

Ah, vorwärts zu noch schneller blinkenden LEDs. :-))

Jörg Wunsch schrieb:
> Chris D. schrieb:
>> Da hilft nur der klassiche Einstieg: LED blinken lassen :-)
>>
>> Begeistert bin ich von den DMA-Fähigkeiten.
>
> Ah, vorwärts zu noch schneller blinkenden LEDs. :-))

So ungefähr :-)

Vielleicht noch für andere Einsteiger Dinge, die mir sehr geholfen 
haben:
- Schema der Takterzeugung ausdrucken und aufhängen
- Schema der internen Busverbindungen ausdrucken und aufhängen

Aber es macht wirklich Spaß, gerade mit dem F4 - endlich hat man mal 
alles zusammen, was man so benötigt, und vor allem: Speicher satt.

Chris D.

Die Batterie wurde mir leer gezogen. Als ich den Chip mit Rev. Z 
einsetzte war das Problem weg.
Das war einfach nur Pech, dass mir der Distri zu Testzwecken noch ein 
paar alte Rev A schickte und ich auch noch die Batterie angeschlossen 
habe.

>An anderer Stelle gab es einen Link auf die Probleme mit dem
>DMA-Controller.

Wenn Du den wieder findest schreibe ich das sofort in den STM32 
Artikel rein. Da gibt es mittlerweile einen Abschnitt "Errata vom 
STM32F4xx die nicht im Errata von ST stehen". Ich hatte schon vergeblich 
gesucht und nicht mehr gefunden :-(

Vielleicht dieser hier:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FWarning%20limit%20simultaneous%20DMAs%20to%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=811

AG schrieb:
> Chris D. schrieb:
>> endlich hat man mal
>> alles zusammen, was man so benötigt
>
>
> Abgesehen von einem internen EEPROM ;-)
> (jaja Flash aber das ist nicht so gut)
> Gibts eigentlich nen Grund warum so gut wie kein ARM internes EEPROM
> hat?
> Find ich doof.

Ich und praktisch alle, die auf dem ST-Seminar waren, auch :-)

Ich habe den Herrn Sbick von ST daraufhin angesprochen und er meinte, es 
wäre ganz oben auf der Liste. Wir wären nicht die einzigen.

Also hoffen wir mal, dass das Manko bald behoben ist :-)

Willi schrieb:
> Daher: (Datenblatt)Papier ist geduldig. Aber die Praxis sieht anders
> aus.
> Beim Blinkenlassen einer LED, merkt man davon noch nichts.

Schon klar - allerdings blinkt hier schon lange keine LED mehr ;-)

Ich dachte, die Sache mit der Pufferbatterie wäre in einer neuen 
Revision schon behoben?

Chris D.

>Also hoffen wir mal, dass das Manko bald behoben ist :-)

Ich will mindesten 32KByte EEPROM drin haben :-)


Ich habe die Links in den Artikel rein genommen.

Ist schon lustig, es gibt Revision A und Z. Die nächste ist dann wohl Y?


Peter

A: Entwicklung / Test (B, C, D...)
Z: Endgültiger Stand

Markus Müller schrieb:
> Z: Endgültiger Stand

Darf man dem Anwender wirklich so knallhart sagen, daß keine Bugfixes 
mehr erfolgen?

Bei Revision M hätte man ja wenigstens noch die Hoffnung, daß mal eine N 
folgen könnte.

Bisher kenne ich keinen neueren MC ohne Bugs.


Peter

Peter Dannegger schrieb:
> Darf man dem Anwender wirklich so knallhart sagen, daß keine Bugfixes
> mehr erfolgen?

Ist ohnehin oft so. Bei µCs wird nicht lange an Versionen gebastelt. 
Bugs, die keine Showstopper sind, bleiben in der Prodversion ohnehin oft 
ungefixt. Mal will Geld verdienen, keinen Perfektionismus betreiben.

Wenn sich dann herausstellt, dass die Endversion unbedingt doch noch 
gefixt werden muss, dann gibts eben einen neuen Chip mit neuem Namen 
oder mit Suffix. Dem STR9 hat ST in der verbesserten Version mittendrin 
ein A spendiert, Microchip dem dsPIC30F6013 eines hintendran und NXP hat 
diversen LPC2000ern ein /01 angehängt.

Das ist auch für den Kunden besser, denn versuch mal einen Chip mit 
einer bestimmten Revision zu kriegen.