|
Anzeige
|
ARM Cortex M4, STM, TI oder Atmel??
Gast
#4067693
Hallo, da ich auf die ARM Cortex Technologie umsteigen möchte, bitte ich um ein paar Tipps welcher Hersteller am Besten ist, bzw. welche Vor-und Nachteile es gibt. Anforderung wär eine komfortable Entwicklungsumgebung und eine einfache Handhabung der Treiber (UART, I2C, CAN, USB, Ethernet). Danke schon mal im voraus :) Also ich verwende parallel zu den Atmel AVRs die Cortex von ST. Als IDE dann Coocox. Wunderbar einfach und unkompliziert. Atmel und co. habe ich keine Erfahrung... Die 32Bitter für rechenintensive Sachen, die AVRs zum basteln. Die gleiche Frage ist hier kommentiert: Beitrag "Günstiger Anfang mit ARM" In dem Thread gibt es bereits sehr viele gute Antworten. Schreibe vielleicht speziell was deine Anforderungen sind dann können gezielter Tipps und Empfehlungen gegeben werden.
Gast
#4068216
Ingo Less schrieb: > Die 32Bitter für rechenintensive Sachen, die AVRs zum basteln. NXP bietet ARMs von hoher Leistung (LPC4000 Triple-Core/80-Msps-ADC) bis DIP-8 fürs Steckbrett (LPC800), alle können mit derselben Entwicklungsumgebung programmiert werden. Zudem gibt es ein integriertes ROM mit allen wesentlichen Treibern (UART, SPI, I2C, CAN, USB) An Entwicklungsumgebungen gibt es erstmal das NXP-eigene Eclipse/gcc (LPCXpresso), freie gcc-Toolchains, und die Professionellen mit 32k Codelimit (Keil, IAR), was aber für einen Task völlig ausreicht. Es gibt günstige Demo-Boards mit Debugger oder mit per USB simuliertem Debugger: http://www.embeddedartists.com/products/lpcxpresso http://developer.mbed.org/platforms/ http://www.embeddedartists.com/products/boards http://www.embeddedartists.com/products/app http://www.embeddedartists.com/products/displaymodules https://www.olimex.com/Products/ARM/NXP/
Gast
#4068427
Wir haben TI. Aber die Kommunikation mit denen ist sehr schwerfällig. Wenn man nicht hundertausende abnimmt, wird man nicht wichtig und ernst genommen. Da mögen andere Hersteller besser sein.
Gast
#4069057
Vielen Dank für die schnellen hilfreichen Antworten :)
Gast
#4069217
Ingo Less schrieb: > Als IDE dann Coocox. Taugt nichts mehr in der neuen Version (Kindergarten) und ist auch viel zu langsam, völlig überladen mit dem Internet-Demo-Projekt-Runterladen-Gedöns.
Gast
#4069564
Christian J. schrieb: > Taugt nichts mehr in der neuen Version (Kindergarten) und ist auch viel > zu langsam, völlig überladen mit dem > Internet-Demo-Projekt-Runterladen-Gedöns. Also für die Arduinofraktion...
Gast
#4070118
CM3 schrieb: > Also für die Arduinofraktion... Nee, die Arduino-Denke ist mittlerweile zum Allgemeingut geworden. Siehe CMSIS, siehe ST-Lib, siehe Eröffnungstext des TO: femtohead schrieb: > Anforderung wär eine komfortable Entwicklungsumgebung und eine einfache > Handhabung der Treiber (UART, I2C, CAN, USB, Ethernet). Naja, vielleicht ist der Nick Programm. Ich kenne genug Leute, die nicht im geringsten daran denken, was und auf welcher Hardware sie zu tun beabsichtigen. Da muß zu allererst ne IDE her, SELBSTVERSTÄNDLICH die komfortabelste der Welt (was auch immer der Schreiber darunter versteht) und von solchen Niederungen wie dem Verstehen der eingebauten Peripherie oder gar des Assemblercodes hält man sich mit Nachdruck fern. Bloß nicht sowas. Jaja, genau DAS sind die Ingenieurs-Eliten der Zukunft. W.S. femtohead schrieb: > einfache Handhabung der Treiber Wenn das dein wichtigster Augenmerk ist, könntest du mit Atmels ASF glücklich werden. (Mein Fall ist es eher nicht.)
Gast
#4070479
Ich habe mich für Atmel entschlossen da die IDE gratis ist und relativ gut dokumentiert ist. Ich bedanke mich nochmals für eure Tipps außer bei W.S. dessen Aroganz hier keinem weiterhilft. Danke :) W.S. schrieb: > Ich kenne genug Leute, die nicht im geringsten daran denken, was und auf > welcher Hardware sie zu tun beabsichtigen. > Da muß zu allererst ne IDE her, SELBSTVERSTÄNDLICH die komfortabelste > der Welt (was auch immer der Schreiber darunter versteht) und von > solchen Niederungen wie dem Verstehen der eingebauten Peripherie oder > gar des Assemblercodes hält man sich mit Nachdruck fern. Bloß nicht > sowas. > Jaja, genau DAS sind die Ingenieurs-Eliten der Zukunft. Ich bin da eigentlich deiner Meinung. Aber es gibt Peripherieeinheiten die derart komplex sind das man über ein funktionierendes Beispiel an dem man sich entlanghangeln kann echt froh ist. Ich denk da z.B. an den MultiCAN von Infineon. Das Ding nur aus dem Datenblatt zu verstehen ist echt nicht ohne. Selbst wenn man schon Treiber für c_can und flexcan geschrieben hat. Wichtig ist halt das man trotz Verwendung fertiger libs noch einen groben Überblick über die jeweilige Peripherie hat. Alle Details muss man aber nicht verstehen. Matthias
Gast
#4070730
femtohead schrieb: > Ich habe mich für Atmel entschlossen da die IDE gratis ist und relativ > gut dokumentiert ist. Damit hast du exakt dem entsprochen, das W.S. ansprach. Glückwunsch. @W.S. Der Name IST Programm! Antwort schreiben |
Anzeige
|
