Hallo Leute,
in letzter Zeit schaue ich ab und zu mal nach geeigneten
Mikrocontroller-Boards, ich komme programmiertechnisch aus der PC-Welt
und habe andererseits etwas Erfahrung gewonnen mit FPGAs - die schiere
Fülle der Möglichkeiten im Mikrocontrollerbereich überwältigt mich aber
stets, je mehr ich schaue, desto kirrer werde ich. Ich möchte die
Möglichkeit erlangen, eine Brücke zwischen FPGA und PC zu schlagen, für
Abstraktions- und Verwaltungszwecke, oder um die Kommunikation zu
bündeln, rudimentäre Eingabemöglichkeiten zu erhalten, sowie den PC als
Steuerorgan im Normalbetrieb zu ersetzen.
Gerne möchte ich die Gelegenheit ergreifen, mich in die ARM-Architektur
einzuarbeiten, speziell Cortex M4. Da ich auf dem PC hauptsächlich mit
Visual Studio zu tun habe, wirkt das AVR-Studio sehr attraktiv auf mich.
Habt ihr Erfahrung damit, taugt das etwas? Wenn ja, kennt ihr IO-Boards
mit "fetten" (also hoffnungslos überdimensionierten) Cortexen? Ich
möchte kein eigenes Entwicklerboard entwerfen (und ich würde viel zu
lange dafür brauchen), aber ich möchte auch kein normales EK-Board mit
Tausend Displays, LED-Leisten etc.. Im Prinzip würde mir ein Board mit
Seriell/USB/LAN zur Kommunikation mit dem PC reichen, bei dem alle
freien IOs einfach nach außen geführt sind, statt an irgendwelche
unnötigen Spielereien gekoppelt zu sein. Wenn es kompatible "Module"
dazu gibt, um meinetwegen ein Display nachzurüsten, dann soll mir das
natürlich trotzdem Recht sein.
Also um es kurz zu machen: Cortex M4, AVR Studio-kompatibel, viele freie
IOs, Kommunikationsmöglichkeit mit PC. Und ein kompatibles
Proggrammer/Debugger-Device würde ich wohl auch benötigen. Bei den
Teilen steige ich sowieso noch nicht so ganz durch... Ich weiß, dass das
alles seinen Preis hat, aber gibt's da was bis maximal so um die 200€?
Würde mich sehr freuen, wenn mich da jemand von euch etwas an die Hand
nehmen könnte, bis ich wieder Bäume sehe.
Viele Grüße!
Achso, vielleicht wäre es praktisch, wenn das Board noch ein paar
gängige Versorgungsspannungen für "fitzel"-Peripherie liefern würde,
damit ich mir bei den kleineren Spielereien Probleme mit
unterschiedlichen Potentialen ersparen kann.
Also wenn Du Ethernet-Kommunikation benötigst, dann schau Dir mal
Raspberry Pi oder Beaglenone Black an. Da wirst Du für ca. 50-60€
glücklich. Vielleicht noch ein Gertboard dazu.
Wenn es Dir um die Programmier-Basics geht, dann vielleicht ein
STM32F4Disocvery plus Network-Modul (gibt es beim Chinesen) plus Coocox
IDE.
Hrmmm, ja, das Discovery-Board gefällt mir irgendwie. Ich möchte
eigentlich kein richtiges Betriebssystem darauf laufen lassen, die
A9-Sachen gehen mir irgendwie zu sehr in Richtung Spar-PC, aber ich habe
schon einen "mächtigen" PC, den wollte ich auch nicht ersetzen
eigentlich. Das einzige was ich mir vorstellen könnte wäre, dass ich
irgendwann einmal ein richtig schlankes RTOS drauf laufen lassen möchte,
aber das wäre schon das höchste der Gefühle.
Coocox sieht ziemlich brauchbar aus, auch wenn ich zugeben muss, dass
ich von diesem Eclipse-Java-Gui-Kram eigentlich immer Augenkrebs
bekomme, und das Auge programmiert ja bekanntlich mit, hehe.
Von STM gibt's auch direkt ein Base-Board zu kaufen, sehe ich, das
Ethernet-Anschlüsse und ein paar IO-Sortierungen mitbringt. Ist das
empfehlenswert, oder gibt's da bessere? Gibt's da evtl. schon eine
fertige Bibliothek, so dass ich sofort UDP verwenden könnte und somit
alle Kommunikationssorgen los bin? TCP scheint mir eher ziemlich heftig
zu sein, genauso wie "echtes" USB (Also keine RS232-Brücke)...
decimad schrieb:> Also um es kurz zu machen: Cortex M4, AVR Studio-kompatibel,
Wie willst du denn im AVR-Studio, das für die AVR-Architektur ist, Code
für Cortex-M produzieren?! Du meinst vielleicht das neuere Atmel Studio,
mit dem man für die Atmel Cortex-M programmieren kann? Wenn es unbedingt
Visual Studio sein muss, kannst du dir auch Visual GDB kaufen und dann
die GNU Toolchain nutzen.
@Dr. Sommer: Ich meinte natürlich auf das Atmel-Studio, nicht das
nicht-existente AVR-Studio, das meinem Verständnis nach alle gängigen
Atmel MCUs unterstützt (inklusive deren Cortex-MCUs) und auf Visual
Studio basiert.
Aber ich habe kein Atmel-Cortex-Board gesehen, das so "sinnvoll" wie das
Discovery-Board aussieht. Von daher wird die Sache wohl ausfallen.
Den Artikel lese ich gerade, dankeschön!
decimad schrieb:> nicht-existente AVR-Studio,
Das existiert(e) schon. Nur ist das ersetzt durch das Atmel Studio, was
eben auch die Atmel Cortexe kann.
Das Lauchpad scheint mir jetzt irgendwie ein bisschen minimalistisch zu
sein... Bei einer 20 Pin MCU stelle ich mir vor, dass ich schon vorher
ziemlich genau wissen muss, was ich damit nun anstelle, oder auf
irgendwelche Dekodier-Peripherie angewiesen bin, um die IO-Anzahl
künstlich zu vergößern. Ich würde mir wünschen, dass die
"applikationsspezifische" Ressourcen-Optimierung für Mini-MCUs eher ein
nachgelagerter Vorgang ist, nachdem die Sache erstmal läuft und man
(ich) genau weiß, was geht und was nicht. Ist das eher eine schlechte
Herangehensweise?
Alles klar, das Discovery wird's!
Ich hab nur noch eine Frage, auf diesem 15€-Board ist ja auch ein
Programmierer&Debugger eingelötet. Weshalb kosten eigentlich
Stand-Alone-Programmierer hunderte Euro, wenn man da auf so einem
15€-Board auch etwas hinfrickeln kann? Was macht diese
Programmer&Debugger eigentlich so teuer und was hebt sie von diesen
Lösungen ab?
Überhaupt frage ich mich, wie die das eigentlich machen. Ist das bei so
ziemlich allen MCUs ein JTAG/Schieberegister-Port, mit dem man die Daten
in's Flash bekommt? Also irgendwie Versorgungspannung bei
Programmier-Flag-Pin geben, reinschieben und dann Programmierspannung
anlegen, alles Vendor-spezifisch?
decimad schrieb:> Was macht diese> Programmer&Debugger eigentlich so teuer und was hebt sie von diesen> Lösungen ab?
Die Software. Die Segger J-Link z.B. sind wesentlich schneller, und auch
stabiler. Die ST-Link, ob auf dem Discovery oder einzeln, sind ziemlich
instabil; bei manchen laufen sie perfekt, bei manchen nur an Vollmond.
> Überhaupt frage ich mich, wie die das eigentlich machen. Ist das bei so> ziemlich allen MCUs ein JTAG/Schieberegister-Port, mit dem man die Daten> in's Flash bekommt? Also irgendwie Versorgungspannung bei> Programmier-Flag-Pin geben, reinschieben und dann Programmierspannung> anlegen, alles Vendor-spezifisch?
Bei ARM-Prozessoren ist das JTAG-Zeug von ARM selber vorgegeben, daher
bei allen Implementationen gleich. Der Segger J-Link unterstützt
beispielsweise alle ARM7/9/11, Cortex-A5/A8/A9, Cortex-M0/M0+/M1/M3/M4,
Cortex-R4/R5. Aber andere µC wie zB AVR funktionieren da ganz anders.
Okay, danke Dir, der allgemein-konfuse Mega-Nebel lüftet sich
allmählich. Ich freue mich schon auf das Studieren der Dokumentation,
damit ich weiß welches Bit ich setzen muss, damit A funktioniert, dafür
aber B und C nicht mehr :D (den Eindruck habe ich irgendwie ziemlich
schnell von MCUs gewonnen).
Ich kann euch nur wünschen, dass ihr nie unter meinen Erzeugnissen
leiden müsst! :)
Der LPC4088 ist auch ein moderner, fetter M4. Gibts als QuickStart Board
und hat auch Ethernet drauf.
Als Programmieradapter geht da der LPCLink2, der kann auch per Firmware
zum Segger kompatiblen gemacht werden.
Oje, die Möglichkeiten! Das Teil sieht natürlich auch gut aus! Ist die
Combo mit dem LPCLink2 zuverlässiger/schneller als die SWD-Schnittstelle
des Discovery? Da das die Ethernet-Schnittstelle direkt auf dem
Hauptboard hat, kommt es eigentlich selbst mit Programmer kaum teurer
als das Discovery + Basisboard. Den könnte ich dann aber wohl auch für
Eigentwicklungen einsetzen.
Embeddedartists pushen da irgendwie ihre eigene Entwicklungsumgebung,
aber ich würde lieber auf eine verbreitete offene Lösung setzen, als
mich irgendwie unter die Fittiche eines Herstellers zu begeben. Das ist
ja schon für die FPGAs schlimm genug. Ich nehme an, dass der Programmer
genausogut mit Coocox IDE zusammenarbeitet?
Oder ist eine der beiden Cortex-Materialisierungen vorzuziehen?
Viele Grüße
die Qual der Wahl...
Die LPCXpresso sind sehr minimal, das STM Discovery hat schon etwas mehr
Spielkram drauf den man nicht braucht wenn man das Board komplett in
eine eigene Schaltung übernehmen will. Das STM ist ausserdem schon fast
so gross wie ein Motherboard. Dafür ist das hier schon weiter verbreitet
und der Einstieg damit ist vermutlich einfacher. Wenn man so einen
grossen Prozessor in eigene Designs einplanen will dann wird das aber
schon anspruchsvoll, die Frage ist für welche Hobbyprojekte man sowas
braucht.
Den LPC4088 + LPCLink2 habe ich und wollte über Weihnachten etwas damit
spielen, aber dummerweise ist da ein 20 pol. JTAG Kabel nötig mit 50 mil
Steckerchen, und wer hat schon sowas... Aber heute morgen habe ich die
Stecker bekommen und versuche mal dem Board etwas Leben einzuhauchen.
Theorethisch soll das auch mit Coocox funktionieren über die Segger Emu,
aber probiert habe ich das noch nicht. Coocox hat auch schon eine gute
Unterstützung für verschiedene Prozessoren, aber nicht für alle. Und
gerade bei neuen Teilen muss man lange auf die offiziellen Erweiterungen
warten oder versuchen selber die Resourcen- und Linkerfiles hinzubiegen.
Die Entwicklungsumgebung für die LPC Boards ist nicht von EA sondern von
CodeRed und die haben eine limitierte Versiion für die LPCXpresso Boards
(und zur Verwirrung noch eine für NXP Prozessoren) erstellt.
Eingeschränkt ist die Prozessorunterstützung (eben nur NXP), die
Debuggrösse von 128k und kein C++. Trotzdem gefällt mir diese Umgebung
sehr gut weil wesentlich umfangreicher in Projektverwaltung,
Debugmöglichkeiten und Optionen. Wenn man CodeRed kaufen möchte haben
die auch verschiedene Stufen und einen guten Support und eine sehr
hilfreiche FAQ Sammlung.
Auf jedenfall ist hier nix mit VisualStudio. Obwohl das auch gehen
müsste mit dem neuen Konzept das Atmel ja auch nutzt. Aber Eclipse läuft
auch in der Mac und Linuxwelt. Alternativ gibts natürlich noch einige
andere: Keil, Rowley uvm. und jeder hat hier seine Fans :-)
Hrmm, ich habe mich auf der mbed-Seite weiter umgeschaut und es scheint
ja noch ziemlich viele Software-Probleme mit dem 4088-Board zu geben.
Deren Offline-Entwicklungsumgebung unterstützt das Teil auch (noch?) gar
nicht, das Tutorial beschreibt die Benutzung eines Online-Compilers mit
Device-Registrierung O.O. Irgendwie habe ich da den Eindruck, dass man
hauptsächlich angeknebelt werden soll, das ist nicht so mein Geschmack.
Die Größe des Boards spielt eigentlich keine Rolle für mich, der Plan
für die große MCU sieht eher vor, dass ich das als "Breadboard" für
Entwicklungen einsetze. Wenn ich dann spezialisierte Schaltungen
entwerfe, kann ich natürlich viel kleinere Devices verwenden, da ich
dann ja schon alle Anforderungen genauestens kenne. Ich schaue immer mit
Staunen, wie hier Entwicklungen oft direkt im Ziel-Device betrieben
werden. Ich hätte in diesem Fall irgendwie Bedenken, vom Device bestimmt
zu werden, denn andersherum.
Das Board "Core407Z" wäre dann schon ideal für den Start eigener
Entwicklungen.
Die CPU STM32F407ZE hat 144 Pins und ist SW-Kompatibel mit allen CPU's
von ST mit STM32F4xx - von 64 PIN LQFP ... 216 Pin BGA.
Wenn man hingegen eine Entwicklung mit TCP/IP machen möchte, dann sollte
man sich ein Board heraussuchen mit dem RICHTIGEN PHY Chip drauf, denn
z.B. der viel verbreitete DP83848 ist schon ziemlich alt und ein
Stromfresser. Hingegen der KSZ8031 ist sogar günstiger.
Die mbed Umgebung ist die standardisierte Pinbelegung der Module und die
Softwarelib, fast wie Arduino. Und das kann man mögen, muss man aber
nicht. Also JTAG/SWD dran und bei Null anfangen, so bevorzuge ich das
auch.
Der Segger (-EDU) scheint mir echt eine gute Investition zu sein, aber
ich hätte Bedenken, ob ich die Lizenz einhalten kann. Ich könnte mir gut
vorstellen, Anbindungen für die PC-Software die in meiner Verantwortung
entsteht, zu entwerfen und das könnte auf alle Fälle mal im
minimal-gewerblichen Umfeld Anwendung finden. Aber direkt privat 400€
auf den Tisch zu legen dafür ist mir jetzt wiederum auch etwas heftig,
Weihnachten ist ja gerade rum.
Ja, klar, 400 sind schon verdammt viel für Privat. Daher kaufe erst mal
den EDU und später Upgrade oder kaufe einen zweiten für das Gewerbe.
(Ich habe 2 J-LINK, 2 Olimex ARM-USB-OCD und einen ST-LINK und
STM32F4DISCOVERY's. Mit den J-LINK bin ich am meisten zufrieden und die
gehen am Problemlosesten sowie flashen am schnellsten.)
Okay, danke Dir. Ich werde die Lizenzbestimmungen nochmal ordentlich
studieren. Wenn ein nachträgliches Upgrade noch drin ist, dann wäre
eigentlich alles in Butter und bei der Combo J-Link + Entwicklungsboard
ohne Pipapo hätte ich ein sehr gutes Gefühl.
decimad schrieb:> Gerne möchte ich die Gelegenheit ergreifen, mich in die ARM-Architektur> einzuarbeiten, speziell Cortex M4. Da ich auf dem PC hauptsächlich mit> Visual Studio zu tun habe,
Klingt wie ne Übung zum Bewerbungsschreiben. Also, was willst du denn
nun EIGENTLICH?
In die ARM-Architektur einarbeiten?
Das tut man durch Lesen der Doku von Arm. Den Cortex M4 versteht man
ebenfalls durch Doku-lesen.
Mit Visual Studio dich befassen? ABer das kannst du ja bereits am PC
tun.
In irgendeiner anderen IDE herumstochern? Zu welchem Zweck?
Dir irgendeinen konkreten µC mit Cortex-Kern zulegen um herauszufinden,
wie man dessen Peripherie programmseitig benutzt? OK, dann leg dir den
µC zu und mache. Aber dann? wenn du dann herausgefunden hast, wie's
geht, was dann? Neues Spielzeug suchen?
Warum soll es ausgerechnet ein Cortex M4 sein? Weil der hier grad hipp
ist? Kannst du dessen Spezifika überhaupt ausnutzen oder willst du nur
in C basteln?
Also: Hast du denn irgendein wirklich faßbares Projekt? ein Bauvorhaben?
ein Gerät, was du realisieren willst? Oder ist das alles nur
Herumdaddeln?
Kurzum, du solltest schon mal etwas gründlicher deine eigentlichen
Ziele formulieren, sonst kann dir jeder andere hier nur seine eigenen
Lieblinge präsentieren und rufen "Nimm dieses, aber bloß nicht jenes".
W.S.
Junge, komm bitte mal runter. Ich kann Dir versichern, dass ich damit
etwas vorhabe. Aber ich Posaune nicht gerne mit meinen Zielen herum,
bevor ich nicht etwas konkretes vorzuweisen habe.
Wenn ich davon ausginge, dass ich für meine Ziele eine mega-spezielle
MCU benötige, weil alle anderen das entsprechende nicht können, dann
hätte ich das erwähnt. Aber für mich reicht einfach irgendeine und da es
keinen großen Kostenunterschied macht, nehme ich einfach eine der
größeren, sodass ich mich nicht von Anfang an eingeengt fühle, ist doch
nicht so skandalös, oder?
Wenn ich nun meinen Tagesjob mit Visual Studio bestreite, wird es
wahrscheinlich auch nachzuvollziehen sein, dass ich mich da am wohlsten
fühlen würde, statt einen neuen Satz von Shortcuts, Menüs und
Benutzerführungen lernen zu müssen, oder? Da ich wohl nicht drumherum
kommen werde, wird das aber nix.
Außerdem habe ich explizit angegeben: Keine Schnickschnack
On-Board-Peripherie, einfach viele IOs. Das 250€-Board von Atmel erfüllt
diese Kriterien sicherlich nicht und die meisten anderen Vorschläge der
Benutzer hier haben doch die Essenz davon getroffen.
