welche freie Toolchain für Microcontroller??

Tach Elektronenschubser,

nachdem mein Kalender wieder ein wenig mehr freie Zeit aufweist, wollte ich mal wieder ein paar Projekte von mir aufgreifen, die alle irgendwie auch nen Microcontroller beinhalten. Die wollen ja üblicherweise auch programmiert werden, und da fängt meine Rätselei an: je nach Gusto der Chiphersteller werden die verschiedensten Varianten präferiert (Keil, codesurcery, WinAVR, codewarrior und wie sie alle heißen), doch wer ohne Windows unterwegs ist wird im Regen stehen gelassen was Unterstützung seitens des Herstellers angeht. Gut, insoweit verschmerzbar, daß der gcc für nahezu alles kompiliert, was ne "1" von ner "0" unterscheiden kann. Doch brauchts für ne brauchbare Entwicklungsumgebung ja mehr als nur nen Compiler: der Transfer der Software ins Zielsystem will erledigt werden, In-Circuit-Debugging ist mitunter auch ganz hilfreich und ähnliches mehr. Und da habe ich überhaupt keinen Überblick. Es gibt nen Haufen JTAG-Zeugs, bei dem mir nicht klar ist, inwieweit das mit fremden Umgebungen (andere Prozessorarchitektur, anderer Hersteller etc.) klarkommt, und auch sonst bin ich in dieser Hinsicht recht wenig bewandert (lies: ich hab keinen Schimmer).

Konkret zur Anwendung kommen werden wohl ein paar ARM Cortexe von luminary, da zum einen wohl ausreichend performant für mich und gleichzeitig preiswert sowie in handlötbaren Gehäusen erhältlich. Aber wie gesagt: Im Laufe der Zeit werden sicher auch andere zum Einsatz kommen, hier liegen noch ein paar unbenutzte 68k-Varianten rum, und auf den PowerPC in nem Virtex-2 Pro oder Virtex-4 hätte ich auch Lust...

Also, womit habt Ihr Erfahrungen gemacht, was könnt Ihr empfehlen bzw. wovon ist eher abzuraten?

Gruß, Florian

Reply to
Florian Teply
Loading thread data ...

Das Zeug von Freescale ist extrem aufgebläht. Weil es wohl "alle" Controller von Freescale unterstützen will. Mag sein daß ein C-Coder bei einem automotive-Zulieferer der 5 Tage die Woche damit werkelt damit klar kommt. Für Hobbyanwender dürfte die Einarbeitungszeit unakzeptabel sein. Für den Zugriff auf typische Freescale-Controller ist kein JTAG sondern eine BDM-Hardware nötig. Die kann auf einem Evaluationboard integriert sein, typisch würde Codewarrior eine nicht ganz billige Schachtel von P&E die an USB hängt benötigen. D.h. Codewarrior ist mit Speicherbeschränkung ( 8k Byte ? ) kostenlos, BDM kostet aber.

MfG JRD

Reply to
Rafael Deliano

Florian Teplyschrieb: "

Also performant und handlötbares Gehäuse schließt sich irgendwie aus. Für einen schnellen Einstieg würd ich dann eher auch ein fertiges Evaluation board nehmen und auf die fertig mitgelieferte Entwicklungsumgebung vertrauen. Ich würde auch eher zu einem "größeren" Controller als Privatanwender greifen, weil fünf Euros mehr keine Rolle spielen, der Zugewinn an Leistungsfähigkeit aber ganz erheblich ist. Der Preis scaliert in erster Linie mit dem eingebauten RAM und Flash. OTP und romless wird man als Privatanwender nicht mehr ernsthaft in Erwägung ziehen, wenn Controller mit 1MB Flash erhältlich sind.

Positiv aufgefallen sind mir die Renesas-Controller, weil die für ihren Preis nicht so mit den Ressourcen knausern und der Hersteller eine kostenlose Entwicklungssuite zur Verfügung stellt. Z.B. gibt es einen R8C/21 ca. 3,50 EUR mit 64k/3k - Flash/RAM mit

16bit-Core. Dazu kostenlos On-Chip-Debugging über Monitor (Bootloader bereits vom Hersteller programmiert), kostenloser C-Compiler (bis 64k) und einfaches flashen über die Entwicklungsumgebung über eine serielle Schnittstelle (USB nach RS232 - Wandler). Man muss also wirklich nur den Controller kaufen und hat so einen schnellen und kostenfreien Einstieg. Nach oben ist alles offen, man kann also auch einen M32C 1MB/48k für ca. 25,- EUR erwerben. Der Compiler reicht dann aber nicht mehr aus.

Falls du was in Richtung USB und Ethernet machen möchtest, könnte auch sowas interessant sein:

formatting link
Der Preis liegt m.W. so bei ca. 65,- EUR.

Dirk

Reply to
Dirk Ruth

Das finde ich nicht weiter schlimm -- die beworbenen Toolchains der Hersteller sind (mit Ausnahme von Atmel mit der sehr guten AVRstudio/WinAVR-Kombination) meist sauteuer und proprietär.

Der gcc ist schonmal eine gute Wahl. Ich würde die anderen Compiler mit einem zehn-Meter langen Stock nicht anfassen. Keil und IAR generieren zwar manchmal schnelleren und kleineren Code, dafür ist man dem Hersteller aber auf Gedeih und Verderb ausgeliefert.

Lieber einen etwas größeren Controller nehmen, wenn's drauf ankommt.

Guck' dir mal Eclipse als Umgebung an. Ansonsten geht jeder andere Texteditor natürlich auch. Debuggen kann man fast alles per GDB-Verbindung und Insight oder halt Eclipse als Frontend.

Das kommt auf die Platform an. Ein wirklich allgemeines Tool gibt's noch nicht.

OpenOCD geht aber schon in die Richtung, und Unterstüzt die ARM-Famile, XScales und wohl auch MIPS.

Für AVRs gibt's dann wieder eigenes. Zu anderen Controllern kann ich nicht viel sagen.

Bei Luminary hab' ich immer ein wenig Bauchschmerzen.. 200+ verschieden Typen in undurchsichtigen und nicht-Pinkompatiblen(?) Varianten.. welcher wird sich da wohl durchsetzen?!

Die STM32 von ST sind auch Bastelfreundlich im LPQF, und dabei noch etwas schneller. Brauchen nur 3.3V, ein paar Abblock-Kondensatoren, und schon geht's los.

Was sind denn deine Anforderungen?!

So für die allgemeine Entwicklung:

  • Atmel AVR als 8-Bitter. Würde ich persönlich aber nicht mehr neu mit anfangen (Hey, wir haben 2009!). Der Preisunterschied zu den
32-Bittern ist zu gering.
  • STM32 mit CodeSourcery-Toolchain, OpenOCD und Amontec-JTAGkey-Tiny (29?, Vorsicht: heftige Versandkosten).
  • Für alles größere direkt 'nen XScale, Atom, o.ä. mit embedded Linux.

Alles, wofür es keine freie (Beer+Speech) Toolchain gibt. Und Architekturen ohne größere Entwicklergemeinde würde ich auch meiden wollen.

--
Thomas Kindler, mail@t-kindler.de
Reply to
Thomas Kindler

...

Gibt's eine freie DebugWire-Lösung? Sowas suche ich gerade, idealerweise lauffähig unter Linux.

...

Gruß, Falk P.S.: CodeWarrior nutze ich nur bei vorgehaltener Waffe bzw. Euro-Scheinen. Wir mögen uns nicht. Dafür mag WINE den CodeWarrior.

--
http://willberg.homelinux.org/
Reply to
Falk Willberg

Hi,

Also, ich kann das nicht nachvollziehen. Vielleicht ja auch deswegen, weil ich an die MCs von der Softwareseite (also noch vieeeeel größere Entwicklungsumgebungen) herangegangen bin. Ich beschäftige mich hier mit HCS08-Prozessoren und bin immer wieder erstaunt, wie leicht mit dem CodeWarrior Projekte erstellt werden können. Mit dem Processor-Expert klickert man sich seine Registerbelegungen und Interrupts zusammen, das ganze erzeugt dann C-Code, der eingebunden wird. Ich finde die vielen Hilfestellungen zu den Registern schon sehr praktisch. Einarbeitungszeit war bei mir so 3-4 Abende, natürlich abhängig vom Vorkenntnisstand.

Also für die HCS08-Teile gibt es bei Elektor das kleine SPYDER Discovery Kit, was ich mit gerade mal 12,50 Euro schon sensationell günstig finde (für ein echtes BDM!). Das Teil wird am USB angeschlossen und man kann dann auch in der Schaltung damit debuggen und viele der HCS08-Controller programmieren. CodeWarrior (16K Limit) und der ProcessorExpert ist auch dabei. Ich hatte jedenfalls damit schon viel Spaß und recht schnelle Erfolge.

Gruß, Oliver

Reply to
Oliver Rutsch

Rafael Deliano schrieb:

Naja, Codewarrior wäre für mich - abgesehen davon, daß ich mir dann extra ne Windows-Büchse für zulegen müsste, was ich definitiv nicht machen werde - nur halb so schlimm weil ich es bereits kenne. Du hast recht, schlank ist anders und sonderlich flexibel ist das trotz ProcessorExpert auch nicht, da die Beschränkung auf 8, 16 oder 32 kB Code-Size (je nach Zielprozessor, teilweise inkl. Datensegment) schon echt lästig werden kann. Mal davon abgesehen, daß zumindest die kostenlosen versionen jeweils nur eine Prozessorfamilie können (nur HC11 oder nur S12/S12X oder nur 68k oder nur PPC), so daß selbst der Umstieg innerhalb desselben Herstellers unangenehm wird, da die unterschiedlichen Versionen IIRC auch zum Teil wichtige Funktionen an unterschiedlichen Orten verstecken. Spaß macht das nicht.

Nun ja. hätte ich vielleicht dazusagen sollen: mein erstes Projekt ist das nicht, ich hab auch schon mehrere Architekturen jeweils in C und Assembler durch (S12, 8051, 68k) und habe da schon mal die 8-Bitter für mich als obsolet abgehakt, die 16-Bitter sehen bei mir dem selben Schicksal entgegen weil inzwischen auch kein Preisvorteil gegenüber den günstigen 32-Bittern mehr besteht (zumindest nicht in Einzelstückzahlen).

Ich habe also eigentlich nur noch 32-Bitter auf dem Radar, da ist es mir aber prinzipiell Wurst, welche Architektur das nun ist. Durch die Abstraktionsebene "C" ist das meist eh ausreichend entkoppelt, und in Sonderfällen muß ich eh die Denkmurmel einschalten. Es geht also in erster Linie nach der Devise: Wo muß ich am wenigsten investieren in Sachen Zeit (Einarbeitung), Geld (notwendige Zusatzhardware wie Evalboard, Programmierschnittstelle, Debugtools) oder Peripherie (intern vs. extern). Okay, persönliche Präferenzen werden auch noch ne Rolle spielen, aber bei eigentlich allen aktuell verfügbaren 32-Bittern ist innerhalb der Produktpalette so viel Luft nach oben, daß man im Zweifelsfall Performance-Engpässe durch ein einfaches Upgrade erschießt. und wenn das nicht mehr geht, sollte ich mir Gedanken darüber machen, ob ein Microcontroller (was "unsichtbaren" Betrieb impliziert) wirklich das richtige Werkzeug für die Aufgabe ist ;-)

Die Stellaris-serie von Luminary hatte ich mir rausgesucht, weil auch die Evalboards sehr preiswert sind und bei den interessanten Teilen Ethernet komplett on-chip abgefackelt wird, nur noch nen MagJack dran und gut. Und fast alle sind auch im LQFP erhältlich. BGA fällt für mich aus weil ich das dann - sofern es mal eine dedizierte Hardware geben soll - extern bestücken lassen müsste, was ich für Einzelstücke auch nicht toll finde.

Und auf der Softwareseite (Toolchain) ist mir halt wichtig, daß ich mich nicht an einen Hersteller fesseln muß, sondern möglichst dieselbe Umgebung habe, die sich auch über verschiedene Hardwarearchitekturen hinweg nicht ändert. Das schreit geradezu nach gcc und OpenOCD, dazu als Oberfläche vermutlich Eclipse inkl. passender Plugins. Dazu muß der Kram natürlich auch auf Meiner Linux-Kiste laufen, was den Großteil der Herstellerspezifischen Lösungen schonmal ausschließt, wenn man sich nicht auch noch um Emulationsschichten wie wine kümmern will. Aber vielleicht habe ich ja was übersehen...

Gruß, Florian

Reply to
Florian teply

Dirk Ruth schrieb:

Das hängt wohl von der Definition von "handlötbar" ab ;-) Ich finde ein LQFP mit 0,5mm Pinabstand ist da schon okay, das ist auch recht fix mit Lötzinn aufs Board geklebt. Aber ich mach ja auch gelegentlich 0201 von Hand ;-)

Die hören sich schon interessant an und sind ebenfalls in Gehäusen, die ich von Hand auf ne Platine löten kann. Nur habe ich noch keinen Distributor gefunden, der die Dinger auch an Privatleute verkaufen will :-/ dazu kommt, daß ich bisher nur den Renesas-Compiler gefunden hab, der soweit ich sehen kann auch nur für Windows verfügbar ist.

formatting link

Sieht ja ganz nett aus. Allerdings stört mich ein wenig, daß die Entwicklungsumgebung nur für Windows XP und Vista supported wird. Okay, wenn es sich wie es aussieht nahtlos in Eclipse integriert, dann besteht zumindest die Möglichkeit, daß es Systemunabhängig geschrieben ist und auch in ner unixoiden Umgebung zum laufen zu bekommen ist. Wahrscheinlichkeit ist aber was anderes :-/

Gruß, Florian

Reply to
Florian teply
8 Bit CPU leben.

MfG JRD

Reply to
Rafael Deliano

Wenn der erste Computer Windows als OS hatte sieht man vieles als normal an. Bei mir hat sich Codewarrior für den QY-Evaluationkit mal geweigert auf einem Windows 98 Rechner zu installieren weil der keine 64MByte RAM hatte. Der QY auf dem Board war in DIL8 mit 1k FLASH. Irgendwo sind da die Proportionen völlig abhanden gekommen.

Damit die Controller laufen muß die Peripherie nach Reset im Code oder per FLASH konfiguriert werden. Wie genau kann man sich aus den dicken Handbüchern raussuchen. Freescale hat das in fertige Routinen verpackt was den Anwender "entlastet" weil er die Details nicht selber kennen muß. Interessant wirds dann wenn Freescale leicht inkompatible Shrinks der Controller rausbringt, oder diese Routinen Bugs haben oder ihre Verwendung Nebeneffekte hat die man nicht berücksichtigt eben weil man sich mit diesen Details nicht beschäftigt hat. Für einen Hobby-Anwender mag das ja alles unkritisch sein. Industrielle Kunden mögen Fehlerdichte ähnlich wie bei PC-Software nicht. Da die Zahl der Bugs auch mit dem Umfang des Codes zunimmt legen also viele Programmierer in dem Bereich Wert darauf die Komplexität niedrig zu halten und möglichst viel selber unter Kontrolle zu haben.

Ich habe mir das Teil mal von ebay geholt: es ist eine lowest-cost Variante die eher wenige Controller unterstützt. Es ist kein Ersatz für die echte BDM-Hardware von P&E. Die BDM-Schnittstelle zum IC ist in den Datenbüchern, kann man sich Hardware bauen. Die Schnittstelle zu Codewarrior aber wohl nicht. Freescale will entweder gut/teuer oder billig/verkrüppelt und kontrolliert das Angebot entsprechend.

MfG JRD

Reply to
Rafael Deliano

Glyn war immer recht nett.

MfG JRD

Reply to
Rafael Deliano

Rafael Delianoschrieb: "

Genau, die verkaufen auch ab ein Stück. Haben zu fast allen Controller Evalboards.

Linux hat bei den Entwicklungsumgebungen in Embeded eher eine untergeordnete Bedeutung, es sei denn, dass Linux direkt auf dem Target eingesetzt wird, was vielleicht auch für Florian interessant sein könnte. Für eine Entwicklerfirma spielt das BS keine Rolle, da wird halt noch ein Win-PC angeschafft. Hatte mal mit einer Entwicklerfirma zu tun, die mehrere ICEs für 12.000 EUR im Einsatz hatte, da spielt der Win-PC dann auch keine Rolle mehr.

Dirk

Reply to
Dirk Ruth

Dirk Ruthschrieb: "

Sorry, es muss heisen für je 12k EUR ;-))

Dirk

Reply to
Dirk Ruth

Rafael Deliano schrieb:

Naja, fragen kostet ja nix.

Nun ja, heutzutage ist man ja in der relativ komfortablen Lage, sich für quasi jede beliebige Kombination an on-chip-Peripherieteilen Controller aus verschiedenen Architekturfamilien raussuchen zu können. Dann kann man als Wahlkriterium auch heranziehen, welche Targets von der bevorzugten Umgebung unterstützt werden, und alles was nicht passt fällt durchs Raster. Ich kann sogar verstehen, daß die Hersteller sich nicht noch ein weiteres zu unterstützendes Betriebssystem ans Bein binden wollen. Auch die Tatsache, daß die Kosten für ein Entwicklungssystem im kommerziellen Bereich nicht so sehr von Bedeutung sind, kann ich gut nachvollziehen. Ich find die Situation (Windows-only) doof, aber ich kann ohne entsprechende Nachfrage/Marktmacht auch nix dran ändern. Also bleibt mir nur, alles auszusieben was mir nicht passt. Übrig bleibt, was von der Community unterstützt wird. Wenn mir was dran liegt, kann ich ja dann an der Unterstützung für mein Lieblingsrechnerchen basteln, oder andere dafür motivieren (wie auch immer), das zu tun. Gerade als Privatmensch habe ich ja auch keine Veranlassung, immer dem neuesten Modell hinterherhecheln zu müssen.

Gruß, Florian

Reply to
Florian Teply

Freescale verschickt keine kostenlosen Samples an Kleinkunden ( es sei denn man lügt denen was vonwegen Firma/Großserie vor ). Die Distributoren haben bei Freescale nur sehr beschränkte Auswahl im Angebot, oft nicht lagernd, meist nur in Packungseinheiten abzugeben ( das sind bei kleinen QFPs enorme Mengen zu sattem Preis ). Läden wie Reichelt/Conrad haben Freescale nicht im Angebot weil keine Nachfrage in dem Kundenkreis ( den GP32 kriegt man allerdings bei Kessler, der ist aber auch ein sehr gängiger Oldtimer ). Dabei ist Freescale nicht irgend eine kleine Klitsche sondern bei

8 Bit und automotive einer der grössten Hersteller. Die Situation ist bei z.B. AVR via Reichelt etwas besser. Aber auch da garantiert einem niemand daß die einen bestimmten Typ noch in 12 Monaten im Angebot haben.
6 Monaten sanft entschlummern lassen ist einfacher.

MfG JRD

Reply to
Rafael Deliano

Rafael Deliano schrieb:

Daß freescale in Einzelstückzahlen schwer bis garnicht beschaffbar ist, ist von meiner Sicht aus eigentlich das größte Problem. Denn insbesondere die 68k-Familie gefällt mir (neben PPC) ausgesprochen gut. Es würde ja schon reichen, wenn freescale die in Einzelstückzahlen zum regulären Preis anbieten würde, ich will das Zeug ja nichtmal geschenkt haben. Bei Dingern wie AVR und PIC ist die Beschaffungssituation IMHO deswegen besser, weil insbesondere mehr Privatmenschen soetwas einsetzen, weil die Beschaffungssituation einfacher ist, weil mehr Privatmenschen soetwas einsetzen, weil die Beschaffung... You get the picture. Ist halt immer dasselbe: Was alle haben wollen, weil es jeder andere hat, kann man an jeder Ecke kaufen. Exoten bleiben Exoten, weil man sie nirgendwo bekommt.

Es wäre schön, könnte ich Dir jetzt fundiert belegen, daß Du in diesem Punkt unrecht hast. Vermutlich wären wir auch beide froh darüber, hättest Du Unrecht. Allerdings ist leider so wie Du sagst :-(

Gruß, Florian

Reply to
Florian Teply

Naja, das AVRStudio ist zwar für lau, aber auch ganz furchtbar buggy. Man muß die Bugs kennen, um erfolgreich komplexere Anwendungen damit entwickeln zu können. Das Grundproblem steckt in einem sehr unsauberen Multithreading. Das ist so dermaßen unsauber, daß die ganze Chose überhaupt nur dann halbwegs funktioniert, wenn alle Threads auf einem CPU-Kern laufen (wofür diese Gülle immerhin selbst sorgt) und selbst dann gibt es oft genug noch "lustige" Probleme.

Dazu kommen ein Haufen Fehler im Simulator-Teil. Nichtmal der emulierte CPU-Core verhält sich in jeder Hinsicht wie ein echter. OK, man muß in diesem Bereich schon gezielt nach Fehlern suchen, um sie zu finden. Aber die Emulation der Timer, insbesondere der 16Bit-Timer ist nochmal eine Größenordnung schlechter. Hier braucht man nach Bugs nicht suchen, sie drängen sich förmlich auf. Das ist nahezu unbrauchbar, um echten Code zu testen. Oft genug läuft es darauf hinaus, eine Debug-Version zu schreiben, die die Fehler der der Emulation korrigiert, aber dann bezüglich des Zeitverhaltens kaum noch was mit dem echten Code zu tuen hat.

Ich würde (und werde) bei diesen kleinen Teilen überhaupt keinen Compiler benutzen. ASM rules.

Reply to
Heiko Nocon

Der sample service war früher kostenlos, aber auf 3 Stück/Typ begrenzt. Inzwischen geändert, liefern bis zu 3 Stück aber wollen eine handlingcharge $10 (?). Akzeptieren nur Kreditkarte u.ä. nicht Paypal. Handlingcharge wird nur für Privatleute erhoben, bei Firmenkunden anscheinend nicht. D.h. nicht Kostendeckung sondern unbeliebte Anwender rausekeln. Für mich war der sample-service damit gestorben obwohl ich ihn früher manchmal benutzt habe. Buy-direct von der Webseite gibts laut ihren Vertrieblern explizit weil die Distributoren die Exoten nicht führen und Freescale also keine design-ins für die bekäme. Aber wie alles nur halbherzig: buy-direct nicht so forciert daß sie die ollen Distributoren damit komplett ersetzen.

Langjährige FORTH e.V. Erfahrung. Da werden seit Mitte der 80er Jahre die Vorzüge von public domain gepriesen. Endresultat war nur daß ausser Paysan und meiner Wenigkeit fast niemand mehr hierzulande Systeme anbietet und unterstützt. Was natürlich nicht gerade die Zahl der Anwender erhöht.

MfG JRD

Reply to
Rafael Deliano

Irgendwie war mir das auch so in Erinnerung daß das früher in Einzelstücken auch an Privatleute kostenlos ging. So bin ich damals auch an die hier rumliegenden 68020 und 68360 gekommen. Und wenn ich 10$ Handlingcharge zahlen soll, wär mir das auch nicht sooo wichtig, solange ich nicht versuche, einzelne Widerstände als Samples zu ordern ;-) Nee, im Ernst: wenn der Controller auf dem freien Markt eh schon mind.

8? mal Mindeststückzahl plus Versand kostet, dann investiere ich die 10$ in Samples gerne. Bei den meisten von freescale reicht das noch nichtmal für einen einzelnen im freien Verkauf... Daß das etwas stiefmütterlich behandelt wird, ist zwar doof, aber besser als nix.

Gruß, Florian

Reply to
Florian Teply

Christian Dietrich schrieb: ...

Aber das ist doch total umständlich: Auf der KOMMANDOZEILE(!11) muß man vi foo.c ... edit .... :w ... :!make flash tippen ;-)

...

Falk, die Nase voll habend von den nervenden aufpoppenden Fenster "The source file has been changed outside of CodeWarrior. Reload? [OK] [Cancel]". JA, ICH HABE DAS FILE GEÄNDERT! NIMM DAS GEFÄLLIGST HIN, OHNE DUMME FRAGEN ZU STELLEN! WENN DU SO SCHLAU BIST, DANN PRÜFE GEFÄLLIGST GLEICH DIE ABHÄNGIGKEITEN! Und das von einem IDE, das minutenlang Zeile 0 kompiliert, um dann in den Logs versteckt zu schreiben, daß es den License-Server nicht erreichen konnte. You get, what you pay for? Hahahaha.

Reply to
Falk Willberg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.