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.
:
Bearbeitet durch User
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.
Lese mal in den Artikel, da ist alles gut beschrieben: STM32 für Einsteiger STM32 CooCox Installation Für USB und TCP/IP gibt es auf der ST Seite vom STM32 viele Demos
:
Bearbeitet durch User
@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 :-)
Ein brauchbares Board mit einem STM32F405 wäre z.B dieses: http://re.reworld.eu/de/produkte/s64dil-405/index.htm mit einreihiger Stiftleiste, und somit auch Steckbrettauglich. Dazu am besten ein Segger J-LINK EDU zum debuggen. Es gibt natürlich auch größere Boards für kleinere Preise: http://www.amazon.com/Core407Z-STM32F407ZxT6-STM32F407ZET6-Cortex-M4-Development/dp/B00E0FJFVG Man muss nur suchen... (Auch für NXP und andere.) Der Segger ist zwar nicht der billigste, dafür ist der für sehr viele µC brauchbar und auch mit den meisten Entwicklungsumgebungen unter Win/Linux und MAC.
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.
:
Bearbeitet durch User
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.
hast Du dir das Board angesehen? http://store.atmel.com/PartDetail.aspx?q=p:10500331;c:100113 damit kann man dann auch schon schön viel machen
Whoah Robert, sorry, das geht ganz in die falsche Richtung. Da fehlt ja nur noch der USB-Ventilator!
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.
Bitte 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.