Guten Abend zusammen wie viele andere möchte ich nun den Schritt von 8 auf 32 Bit starten. Hierfür möchte ich Cortex M3 Chips verwenden, da ich mit diesen schon gearbeitet habe (LM3S6965 von TI). Mir stellt sich nun wie allen anderen auch die Frage: Welcher genau? Zur Auswahl stehen mir dabei folgende 3 Firmen: - ST Miccroelectronics mit dem STM32 - NXP mit dem LPC17xx - TI mit der LM3xxxxxx Reihe Wichtig für mich ist eine gute Verfügbarkeit der Controller (ich möchte die Controller auch privat bestellen können, da die Studentenlaufbahn ja irgendwann vorbei ist) sowie eine ordentliche Entwicklungsumgebung. (Habe bisher mit IAR und Eclipse Derivaten gearbeitet). Ein ordentlicher Programmer unter 100€ ist natürlich Pflicht! Wenn ich mich mit einem uC beschäftige, möchte ich bei Fehlern nicht darüber nachdenken müssen ob es nun ein Problem des Programmer ist oder ein von mir verursachtes. Herausgesucht habe ich mir daher folgende Zusammenstellung NXP: Programmer/Eval-Board: http://de.farnell.com/nxp/om11048/kit-dev-lpcxpresso-lpc1343/dp/1777673 Dieses Board kann auch gleich als JTAG benutzt werden und unterstützt alle Cortex M3/Cortex M0 von NXP. Es können auch einige LPC200 8ARM 7)Derivate programmiert werden. Als Software wird eine eigene IDE (die auf Eclipse basiert) verwendet. ST: Programmer: http://de.farnell.com/stmicroelectronics/st-link/programmierer-icd-f-stm8-stm32/dp/1779159 Ist ein reiner Debugger/Programmer für alle STM32 und STM8 Derivate. Also müsste mans ich noch ein eigenes Eval-Board machen, was aber nicht das Problem wäre. Ausserdem verwenden bereits viele Leute diese Controllerfamilie, also denke ich mal sollte man sie auch Privat irgendwo bestellen können TI: Programmer/Eval-board: http://de.farnell.com/luminary-micro/eki-lm3s811/kit-eval-lm3s811-iar/dp/1712248 oder aber http://de.farnell.com/luminary-micro/eki-lm3s6965/kit-eval-lm3s6965-enet-iar/dp/1712247 Das erste Board ist natürlich eine sehr günstige Variante mit kelinem Display. Oder aber doch die "Luxusvariante" mit schon einigem an Peripherie drauf (Ethernet, SD Card). Beide Boards können als JTAG/SWD verwendet werden und stellen somit die Programmierung eigener Boards zur Verfügung. Nun kann ich micha ber nciht entscheiden, da ich eifnach nciht weiß wie es um der Verfügbarkeit der Controller steht. STM32 macht wahrscheinlich die geringsten probleme, von dem was amn so hört. Mit dem Boards von TI habe ich ebreits gearbeitet und war echt begeistert. Die von NXP sind aber sehr günstig. Wer also Erfahrung mit einem von den 3 varianten hat könnte mir diese bitte mitteilen? Dann fällt die Entscheidung bestimmt einfacher.
Die STM32 kriegt man auch privat probemlos, beispielsweise bei TME und bei Sander - und natürlich bei HBE/Farnell. Development-Boards gibt es günstig bei futurlec und ebay. Beim JTAG drauf achten, dass die Lösung mit der becorzugten Software-Umgebung zusammenpasst. Nicht jedes JTAG-Interface wird von jeder Software akzeptiert. Komplettpakete mit USB-Controller-Stick und I/O-Board mitsamt JTAG und Development-Software findet man bei Hitex, für STM32 und diverse andere ARMe.
Also ich habe nun etwas die verschiedenen Controller der hersteller durchgeschaut und muss sagen: TI fällt für mich raus. Die uC mit integriertem USB sind alle im 100-LQFP Gehäuse, was mir doch zu viel Aufwand fürs hobby sind. Die 64-LQFP Varianten sind noch nicht auf dem markt (comming soon laut ihrer Homepage). Bleiben also noch NXP und STM32
Bei den STM32 gibt es CAN/USB ab 48 Pins. Diese Controller können dann beides, aber nicht gleichzeitig.
Die FW-Lib von ST gefällt mir sehr gut. Eine LIB für alle STM32F103xx Prozessoren. Einmal SW schreiben, für jede Variante nutzbar. Und zu jeder Pheriperie gibt es Beispiele, z.T. auch mehrere. Im Internet gibt es auch schon viel Code und das STM32 Forum von ST ist auch sehr gut.
Versuche mich zu diesem, meinem Lieblingsthema, kurz zu fassen. Stand heute: TI/Stellaris war zuerst am Markt und ist gut verfuegbar, kann nur noch besser werden als Teil von TI. STM32 war naechster, die meisten Teile auch gut verfuegbar, NXP relativ spaet gekommen aber stark aufgeholt und in vielen Faellen sogar die Mitbewerber ueberholt. Verfuegbarkeit sollte bei allen 3 Herstellern grundsaetzlich gut sein. Neuankuendigungen brauchen immer ne Weile bis man sie ohne Probleme bekommt. Features: Im High-End ist vieles an Peripherals vergleichbar. Die Unterschiede liegen im Detail. Nur mal eine kleine Liste; NXP, kann am schnellsten laufen TI hat integrierten Ethernet PHY und das schnellste Flash STM32 hat wohl bessere Analog-Features als die beiden andern Bei 50 MHz ist TI der schnellste, bei 100 MHz wird es knapp zwischen TI und NXP. Persoenlich mag ich den Primer2 von Raisonance / ST sehr, viele Moeglichkeiten relativ guter Preis. Mit M3 bist Du auf einer guten Schiene und es wird sich noch einiges bei ARM tun. Wuerde mich nicht wundern, wenn der naechste Mx auf der Embedded World angekuendigt wuerde. Robert
Schon irgendwo ausserhalb eines teuren Demo-Boards gesehen?
Albert Krenz schrieb: > (Habe bisher mit IAR und Eclipse Derivaten gearbeitet). Ein ordentlicher > Programmer unter 100€ ist natürlich Pflicht! Das habe ich vorher irgenwie ueberlesen. IAR fuer professionellen Einsatz faengt bei ca. 2500 Euro an falls das Programm in 256 KB reinpasst. Was spielt es da fuer eine Rolle ob der Programmer unter 100 Euro kostet. Ich koennte verstehen wenn der Satz so lautet. Ein guter Programmer ist natuerlich Pflicht. Und den gibts fuer alle o.g. Typen. Zum Thema SAM3; Leider sehe ich den SAM3 derzeit auch nicht als echte Alternative fuer die meisten Anwender. Hauptgrund ist der Focus auf USB 2.0 HS und sonst eigentlich nichts. Kein CAN, kein Ethernet, schade.. Ich hoffe Atmel bekommt das noch auf die Reihe und investiert nicht alles in den AVR32, denn dieser wird es gegenuer all den Cortex-Derivaten sehr schwer haben. Wer natuerlich einen HS USB moechte, der hat keinen anderen M3 zur Auswahl, nur den SAM3. Robert http://mcu-related.com/architectures/35-cortex-m3/76-sam3u-cortex-m3
hallo, wenn ich albert richtig verstanden habe dann sucht er einen chip mit max. tqfp64 gehäuse. da kommt bei nxp wohl nur die lpc13xx familie in frage und die hat auch weder can noch ethernet und ist speichermäßig auch etwas "unterausgestattet". gruss gerhard
Nachdem ich mich für ST entschieden haben, würde ich das nächste mal eher NXP nehmen. Die FWLib von ST ist teilweise verbuggt oder seltsam. Insbesondere die Umsetzung des I²C ist die Hölle.
In jeder CPU ist die Umsetzung des I2C die Hölle. Nur bei STM verleitet die FW-Lib den Eindruck dass es leichter geht. STM hat nur den Vorteil, dass der IIC Bus einfacher initialisierbar ist. Die Schrittkette der gesicherten IIC Übertragung muss in JEDER CPU eingebaut werden und jede CPU hat das gleiche Problem (Hölle). Ich habe IIC bei Microchip, NXP und STM eingebunden, nirgends war es leicht.
Robert Teufel schrieb: > Das habe ich vorher irgenwie ueberlesen. > IAR fuer professionellen Einsatz faengt bei ca. 2500 Euro an falls das > Programm in 256 KB reinpasst. Was spielt es da fuer eine Rolle ob der > Programmer unter 100 Euro kostet. Ich koennte verstehen wenn der Satz so > lautet. Ein guter Programmer ist natuerlich Pflicht. Und den gibts fuer > alle o.g. Typen. Nunja, ich würde schon rein die Kickstart Version nehmen. Und diese ist auf 32kByte beschränkt. Was aber für die meisten hobbybereiche ausreichend ist. Bei NXP liegt die Codebeschränkung bei 128kByte, wenn man die NXP eigene Software verwendet (basiert auf Eclipse und wäre für mich daher voll in Ordnung). gerhard schrieb: > wenn ich albert richtig verstanden habe dann sucht er einen chip mit > max. tqfp64 gehäuse Fast richtig. Bisher habe ich eben maximal IC's im LQFP48 Gehäuse verbaut (also Layout selber gemacht und Platine selber hergestellt). LQFP64 würde ich mich noch trauen, aber LQFP80 wird schon verdammt eng. Drüber würde ich nicht gehen wollen. Eng ist in dem Sinne zu verstehen, das es dann vom Verlöten herr einfach sehr aufwendig wird. Und der IC ggf. einfach zu groß wird. gerhard schrieb: > @albert: > ist atmel SAM3x kein thema? > > gruss > gerhard Ich möchte keine ATMEL Cortex M3 verwenden, da diese in ihrer Ausstattung/Peripherie nicht so umfangreich sind wie einige IC's der anderen Hersteller. Robert Teufel schrieb: > Features: Im High-End ist vieles an Peripherals vergleichbar. Die > Unterschiede liegen im Detail. > > Nur mal eine kleine Liste; > NXP, kann am schnellsten laufen > TI hat integrierten Ethernet PHY und das schnellste Flash > STM32 hat wohl bessere Analog-Features als die beiden andern Was heißt besserer Analog teil? beziehst du dich darauf das die STM32 bsw. zwei AD-Wandlungen gleichzeitig durchführen können? (meine dies in den Datenblättern gelesen zu haben, bin sie aber nur überflogen). hat vl. mal jmd. einen TI M3 gesehen der USB auch in Gehäusen mit weniger Pins als 100 gesehen hat? Oder muss man da auf die angekündigten, wie den LM3S5956, warten?
Mache doch so die Auswahl des Prozessors: Nimm Google und suche mal Demo Code für die unterschiedlichen Typen. Denn wenn es da nichts/wenig gibt, dann ist es schwierig. Oder einfacher: In diesem µC Forum auf den ARM Filter klicken, dann siehst Du auch welchen Prozessor gerne häufig verwendet wird. Denn wenn Du einen "Exoten" verwendest wirst Du kaum Hilfe in diesem Forum bekommen. Ja, der STM32 hat 2 eigenständige AD-Wandler. Die Typen ab 256KB Flash sogar 3. (Nennt sich High Density Device und ist viel mehr pheriperie drin.) Also auch ein Grund mehr einen STM32 zu verwenden. Bracuht man z.B. einen 5. oder 6. Timer, dann einfach das Pinkompatible größere HD-Device nehmen.
@Albert, Hab mit besseren A/D auch gemeint, dass sich bei ST die 12-bit 5x schneller konvertieren lassen als z.B. bei NXP oder auch, dass 12-bit vielleicht gar nicht da ist bei LM. Zu analogen features gehoeren aber auch andere Dinge wie ein genauer und zum Wake-Up brauchbarer OSC auf dem Chip ist, falls Batterie-Betrieb ein Thema ist, ein guter brownout, eine RTC die im Bereich 1 uA ist und so weiter. Da scheint jeder so seine Schwaechen und Staerken zu haben und die sind je nach Anwendung wichtig oder vernachlaessigbar. Zum Thema Beispielsoftware, da wo viel ist, ist auch viel Mist. Da wo keine ist, faengst Du aber von vorne an, oder auf gut schwaebisch "s'isch nix wie's isch". Frei ins deutsche uebertragen, man kann's nur falsch machen :-) Robert
@albert >Ich möchte keine ATMEL Cortex M3 verwenden, da diese in ihrer >Ausstattung/Peripherie nicht so umfangreich sind wie einige IC's der >anderen Hersteller. was fehlt dir den an peripherie am sam3? bzw. welcher chip im 64 pin gehäuse hat mehr an peripherie? gruss gerhard
Wie Robert schon schrieb: Atmel kann USB 2.0 Highspeed, was in dieser Klasse nicht unbedingt üblich ist. Üblich ist Fullspeed, also 12Mbps. Allerdings sollte man bedenken, dass man mit einem 50-100MHz ARM7 oder Cortex-M3 schon ins schwitzen kommen kann, wenn man nur Fullspeed USB gesättigt kriegen will, wenn das USB kein Selbstzweck sein soll, sondern noch was anderes auf dem Controller läuft, das diese Daten nutzt.
Albert Krenz schrieb: > Nunja, ich würde schon rein die Kickstart Version nehmen. Und diese ist > auf 32kByte beschränkt. Was aber für die meisten hobbybereiche > ausreichend ist. Wenn du meinst... Du erwähnst oben Ethernet, also wohl TCP/IP. Sich dabei von vorneherein in 32KB einzuigeln wird etwas stachelig. Anders gesagt: Was machst du, wenn die Kickstart-Version nicht ausreicht? Sehr tief ins Sparschwein greifen - oder komplett umsteigen?
Habe mir die Tage mal die M3 Reihe von NXP angesehen. Ich verwende selbst den ARM7, v. a. den LPC2365 und 2478 für 'größere' Sachen. Für alles andere AVR, manchmal auch PIC. Noch, denn für Neuentwicklungen sehe ich keinen Grund mehr auf der 8-Bit Schiene zu bleiben. Mit M0 und M3 gibt es keine Ausreden mehr ;). Interessant finde ich die LPCexpresso Umgebung und auch die entsprechenden Boards für die es auch (für NXP Verhältnisse) erfreulich viele Beispiele gibt (auch für USB HID + Mass Storage und Ethernet). Benutzt wird da nämlich der GCC und die 128kB Beschränkung gilt nur für den Software Download über diesen LPC-Link. Ich nehme an das Debuggen über 128kb auch nicht geht, auch wenn man das Programm auf einem anderen Weg in den Controller schiebt. Der Compiler/Linker ist aber nicht eingeschränkt. Debuggen geht über den LPC-Link aber angeblich nicht unter Vista-64 bzw. Win7-64. Ich schätze das das auch so bleiben wird da sich der Fall (schneller + günstiger Einstieg) für NXP erledigt hat und die Firma Code-Red, von der die Software stammt, ein eigenes JTAG Interface anbietet das unter 64-Bit funktioniert. Programm-Download soll aber gehen. Die STM32 Familie macht auf mich auch einen sehr guten Eindruck. Da ich aber auf einen 8-Bit Ersatz und USB-Hid aus bin (die LPC13xx haben HID fertig im ROM) und nicht weiß was man mit einem zweiten AD-Wandler macht, ziehe ich die LPCs vor. Luminary und Atmel interessieren mich nicht da die SAM3 und die interessanten LM3S nicht lieferbar sind. Gut, der LM3S6965 mit seiner PHY reizt mich schon etwas - doch der alleine ist etwas mau. Im unteren Segment (32-Pin) kann ich nichts gescheites entdecken.
Wenn man schon den LPC23xx / LPC24xx hat und SW für deren Pheriperie, dann ist es natürlich Sinnvoll dden LPC17xx zu nehmen, denn die haben exakt die gleiche Pheriperie drin. Das hat NXP gut hin bekommen. Für einen neueunsteiger würde ich eher zum STM32 raten. Ich habe selbst schon LPC2368 programmiert. Irgendwie gefallen mir die STM32 dennoch besser. Liegt wohl an der mitgelieferten FW Lib, mit der ich nur kurz Demos anschaue und dann selbst in mein Programm einbinden kann ohne mich großartig mit den Datenblättern herumschlagen zu müssen. Mit dem STM32 komme ich einfach schneller zum Ziel. Der NXP LPC ist auch sehr gut. Schlussendlich entscheidet zwischen den beiden die Pheriperie. Mit Eclipse / Codesourcery kann man Cortex kompillieren. Mit Eclipse / Yagarto den ARM7. Also man muss in der Makefilel nur den Name des Kompillers umbenennen und schon kann man mit der gleichen Umgebung beide Typen erschlagen. Wenn man Eclipse, Yagarto usw. allesamt in das gleiche Verzeichnis installiert, dann kann man die Entwicklungsumgebaung mit einfachem Kopieren (nicht erneut installieren) auf einen weiteren PC übertragen. Einziges, die PATH-Einträge in der Systemsteuerung mit übernehmen. Ist auch ein Vorteil, wenn man mehrere PCs nutzt. Ich habe mit eine kleine Patch gesschrieben, die in der Registry einen Eintrag "ECLIPSE" erzeugt und ich muss nur noch in die Path Variable %ECLIPSE% hinzufügen. (Siehe Dateianhang)
Plan schrieb: > Mit Eclipse / Codesourcery kann man Cortex kompillieren. > Mit Eclipse / Yagarto den ARM7. Und wieso kompilierst du den ARM-Code nicht auch mit Codesourcery? Dann brauchst du nichst umbenennen.
Ich hab das noch nicht probiert. Aber den Cortex-M3 Code mit Yagarto kompillieren klappt nicht recht, der braucht dann unmengen RAM. (hab schon länger keinen ARM7 zu programmieren gehabt und never touch a running system)
A. K. schrieb: > Albert Krenz schrieb: > >> Nunja, ich würde schon rein die Kickstart Version nehmen. Und diese ist >> auf 32kByte beschränkt. Was aber für die meisten hobbybereiche >> ausreichend ist. > > Wenn du meinst... > > Du erwähnst oben Ethernet, also wohl TCP/IP. Sich dabei von vorneherein > in 32KB einzuigeln wird etwas stachelig. > > Anders gesagt: Was machst du, wenn die Kickstart-Version nicht > ausreicht? Sehr tief ins Sparschwein greifen - oder komplett umsteigen? Da hast du allerdings recht. Da könntes es nun wirklich eng werden, hatte ich nicht bedacht. Ich werde wohl das Set von NXP nehmen (http://de.farnell.com/nxp/om11048/kit-dev-lpcxpresso-lpc1343/dp/1777673). Entscheidungsgründe sind da bei mir: - 128kByte Code möglich - USB im 48LQFP Gehäuse (LPC1343) - Ethernet in den größeren Controllern vorhanden - Möglichkeit auch einige ARM7 und einen ARM9 zu programmieren - Günstige Erweiterungsmöglichkeit der IDE auf 256kByte und 512kByte (für 256$ und 512$). Wenn es mal nötig sein sollte. Anbieter ist Code Red - Es ist direkt ein LPC1343 dabei mit dem ich dann anfangen würde.
Nachtrag zu LPCexpresso und 64Bit: Der Treiber stammt von NXP und angeblich wird an einer 64Bit Unterstützung gearbeitet. Genau genommen sind es zwei Treiber die gebraucht werden. Der eine ist für den Normalbetrieb zuständig und läuft unter 64-Bit. Der ARM9 auf dem JTAG Interface hat aber kein Flash, nur RAM. Die Firmware wird also bei der Initialisierung per USB zum Board geschickt. Und der Treiber der dafür zuständig ist, unterstützt nur ein 32-Bit Windows. Angeblich ist es möglich das Board von einer virtuellen Maschine mit Win32 aus zu booten um dann mit 64-Bit weiter zu machen. PS: Diese aufgebrezelte Eclipse IDE macht Laune. Ich habe damit mal eben eine LPC1766 Platine die hier schon seit Monaten unbenutzt rumliegt in Betrieb genommen (wird eigentlich mit LPC2365 bestückt). Habe zuvor noch nichts mit dem M3 gemacht. Jetzt habe ich einen 100MHz LED Blinker ;).
32K sind ein wenig knapp. Ansonsten ist das ein nettes Angebot. Zumindest hat man damit Eclipse und bereits als fertige Umgebung :) Zum Entwickeln sollte man immer die Optimierung deaktiviern, dann kann man ordentlich debuggen. Allerdings wird dann doppelt so viel Code benötigt. Und deshalb sind 32Kb etwas dünn. Ich hab hier eine Heizungssteuerung gemacht, die braucht 100KB Code (Cortex M3 mit STM32). Beitrag "Re: Heizungssteurung im Eigenbau" Bevor ich die Platinen hatte konnte ich mit einer anderen CPU das Programm größtenteils schon schreiben. 32KB hätten mir da nicht gereicht. Bei dem Farnell-Angebot, ich bin mir nicht sicher, ist der JTAG ist im Board mit eingebaut. Also wenn man da eine andere CPU bespielen/debuggen möchte, dann braucht es einen extra JTAG Adapter. Aber die LPCxxxx kann man auch mit Flash-Magic seriell bespielen. Dennoch für des erste Einsteigen und Schnuppern an 32 Bit ist das Angebot sehr gut. Wenn man konkret schon was größeres vor hat, z.B. TCP/IP dann sollte man sich gleich ein größeres Board hohlen.
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.