Hi, ich als MSP programmierer muss gezwungener maßen ein Cortex M4 programm schreiben (kleine sache: usb zeitschaltuhr und I/O's schalten via USB + mems sensor auslesen). Würdet ihr den STM32F407 empfehlen oder den NXP Cortex M4 ? Preis ist egal. Hauptsache ist der Entwicklersupport, die schnelle einarbeitung bzw. Tutorials die beim Entwickeln helfen IDE ist Keil. Wäre für Tips dankbar! Gruß Marcel
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
Nimm was aus der Stellaris Reihe von TI. zb die Lm3S5xxxx Da bleibst du beim gleichen Hersteller, was wohl zumindest beim Verständnis der Datenblätter helfen kann.
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.
Den NXP kann man für Unerfahrene nicht empfehlen. Der hat einen M4- und einen M0-Kern, quasi ein asymmetrischer Dual-Core Prozessor. So etwas zu debuggen ist oft etwas problematisch, um es einmal vorsichtig auzudrücken... Und was die Performanceanfoderungen angeht, reicht ein M0 hier eigentlich völlig aus. Außerdem ist ein M0 auch geeigneter als Einstieg in die ARM Welt. Mit einem M4 zu beginnen, könnte einigen Frust nach sich ziehen...
>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.
Der Schritt von MSP zum Arm Cortex ist heftig genug. Kein Grund, einen "Mehrfrontenkrieg" zu eröffnen.
ja also ein M4 weilt ggf. das Programm erweitert wird. ABER ich sehe gerade das der NXP eine integrierte Phy mit RMI/MII hat ist ja auch praktisch! Das mit den asynch Cores ist natürlich interessant aber ich finde auch unnötig kompliziert wenns um das debuggen geht, da habt ihr recht. Also ich hab mir heute das Discovery auf den tisch gelegt und mal bisschen was gemacht. Sieht eigentlich sehr nett aus. OK die Library hätte man ja doch etwas mehr abstrahieren können und eine gute Doku wäre auch sehr nett gewesen. Also gerade was es angeht externe/interne Interrupts zu erzeugen, I2C/SPI, Timer zu starten... Da wäre so eine kleiner Beginnersguide nicht schlecht gewesen oder eher eine Reference naja ok das dicke RM0008 liegt ja hier auf dem Desktop. Das Erata-Sheet von ST sieht allerdings viel beängstigender aus als das von NXP... naja vielleicht weiß NXP ja noch nich soviel über die MCU Fehler. ... Aber Markus hat schon recht, sooooo schwer ist es ja nicht umzusteigen. Ich bin ja kein absoluter Anfänger. Warum der M4: - 1.) es soll später noch ein Webserver auf dem Controller laufen, welcher die Messdaten visualisiert. 2.)Es ist gewünscht, weil der nächste der dran weiterarbeitet sich mit dem Controller auskennt. Meint ihr das wäre mit dem möglich? (Peformance technisch). oder würde man hierzu einen externen controller benutzen? Grüßle Marcel
> Meint ihr das wäre mit dem möglich? (Peformance technisch). Man kann auch einen einfachen Webserver auf einem 8MHz AVR laufen lassen. Der STM32F4 hat 168MHz und Cache und und und... Man ist früher mit einem Pentium 90MHz auch im Internet gesurft und da lief noch Windows 95 und sonstiger Schund dazwischen. Gute Programmierung vorausgesetzt: Kein Problem.
Ich hab schon recht nette Messdaten-Visualisierungen auf einem 16Bit 25MHz PIC Webserver gemacht, ein M4 sollte das also schon schaffen.
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.
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.
Chris D. schrieb: > Begeistert bin ich von den DMA-Fähigkeiten. man kann damit schon fast > alles erschlagen und der Kern dreht immer noch Daumen :-) An anderer Stelle gab es einen Link auf die Probleme mit dem DMA-Controller. Ab 3 aktivierten Kanälen wurden DMA-Anforderungen aus unerklärlichen Gründen sporadisch nicht mehr bedient. Ein anderer Beitrag zeigte, dass die Pufferbatterie ratzfatz leergezogen werden kann. Diese Macke kann man wohl nicht umschiffen (workarounden :-) DMA+FSMC soll ebenfalls nicht sauber funktionieren. Daher: (Datenblatt)Papier ist geduldig. Aber die Praxis sieht anders aus. Beim Blinkenlassen einer LED, merkt man davon noch nichts.
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 :-(
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
Chris D. schrieb: > Ich dachte, die Sache mit der Pufferbatterie wäre in einer neuen > Revision schon behoben? Das hat Markus ja dann auch mit seiner Rev. Z bestätigt. Schon mal gut! Die Links von ...frankvh... meinte auch ich. Normalerweise bin vorsichtig, aus unbekannter Quelle solche Fehlermeldungen zu akzeptieren. Er scheint mir allerdings kompetent, zu wissen, was er macht und schreibt. Selber auf solche Fehler zu treffen, ist immer heikel, wenn man den Fehler immer zuerst bei sich selbst sucht und (wider Erwarten) nicht fündig wird :-)
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.
back to topic.... hat NXP nicht solche DMA probleme? Das ist ja echt blöd aber ich werde höchstens ein DMA benutzen :((
Marcel schrieb: > Das ist ja echt blöd aber ich werde höchstens ein DMA benutzen :(( Dann kanns Dir ja egal sein
>ABER ich sehe gerade das der NXP eine integrierte Phy mit RMI/MII hat >ist ja auch praktisch! Entweder meinst Du "Ethernet MAC mit RMI/MII Schnitstelle" oder "Ethernet MAC mit integriertem PHY, ev plus zusätzliches RMI/MII Interface...
jetzt seh ich gerade das der Stellaris auch ziemlich viel cooles zeug an board habt. Wie sind denn eure erfahrungen damit ? http://www.ti.com/lsds/ti/microcontroller/arm_stellaris/m4f_series/overview.page
eigentlich brauch ich ein stabiles i2c, usart und USB. :) und natürlich eine gute library.
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.