Jetzt habe ich mit der Entwicklung von AVR-Projekten unter Linux bisher sehr gute Erfahrungen gemacht (avra, gcc, avrdude, avarice...) das läuft alles sehr rund und macht (fast) keine Zicken. Da ich aber mittelfristig meine Controllererfahrung nicht auf AVRs beschränken möchte, aber mit Windows schlicht nicht mehr klar komme, wollte ich mal fragen wie die Lage bei enderen Controllern aussieht, dass es mit den meisten uCs möglich ist weiss ich, aber wieviele Hindernisse gilt es dabei zu überwinden. Speziell würden mich MSP430, Z80 (ja ich bin ein Nostalgiker), Propeller, PAL, 8051 und falls es mich mal packen sollte auch ARM interessieren. Wenn ich die Lage richtig einschätze sind AVR in sachen Popularität (grade auch bei OpenSource Entwicklern) ungeschlagene Platzhirsche, von daher gehe ich mal davon aus, dass die Toolchains der anderen uCs nicht ganz so ausgereift sind. Also, welche anderen uC sind ähnlich unproblematisch und was für Schwierigkeiten treten bei anderen auf (Crosscompiling Umgebung, Debugging,...). Selbstverständlich wäre ich über derartige Hinweise im Bezug auf DSP, CPLD, FPGA auch dankbar, die Teile sinda ja auch alles andere als uninteressant. Ich habe schon etwas mit VHDL unter Linux herumprobiert, das würde ich aber als gutes Beispiel für einen steinigen Weg heranziehen. Natürlich abgesehen von dem phantastischen VHDL-mode von emacs (das allerdings ist schon eher sehenswert zu nennen als einfach nur gut hint). Also habt ihr mit irgendetwas, ausser AVR, unter Linux Erfahrungen gemacht, dann schreibt doch einfach und wenns nur eine Schulnote ist. (1-"easy peasy ala AVR" <--> 6-"Ich hab da mal ein Patch für kernel 2.0.9 gesehen.") -wiebel
EzUSB (8051 + USB): 2 Mit sdcc, ist aber schon eine Weile her, der sdcc hat inzwischen etliche neue Versionen gesehen... PIC (pic16-Architektur, also die 18Fxxxx-Pics): 1, 3 3 für den SDCC, der ist bei PICs halt noch nicht so weit um mit den komerziellen Compilern mitzuhalten. 1 für KTechlab, pikdev, piklab CPLD: 4 (Xilinx Webpak) Gibt zwar eine Linux-Version, die läuft aber bei mir (auf 64Bit Linux) alles andere als zufriedenstellend.
ARM: klare 1 MSP430: 2 (GCC ist etwas altertümlich) Z80, 8051: 3 (SDCC ist nicht so leistungsfähig wie der GCC, und Bootloader für den Controller muss man auch erst mal finden) Xilinx-FPGAs: 2 (ISE soll recht problemlos laufen, keine eigene Erfahrung)
Xilinx-FPGA: 2 Läuft zwar problemlos auf einem 32-bit (K)ubuntu, aber die Xilinx Software an sich ist nicht gerade ein Glanzstück... Arbeiten kann man damit aber ARM: 1 GCC + Eclipse oder auch Rowley's CrossWorks laufen einwandfrei Debugging mit freier Software möglich, Rowley klappt ebenfalls sehr gut ARM/Linux: 1++ Wer ernsthaft mit ARM/Linux (sprich Linux auf dem Target) arbeiten will kommt um einen Linux Host kaum herum. Gruß, Dominic
Super, danke für die (ersten) schnellen Antworten, gut ARM war eigentlich klar, hätte ich gar nicht erst fragen müssen. Da auf ARMs ja oft genug Linux selbst läuft ist ab einem gewissen entwicklungsstand wahrscheinlich Telnet/Minicom das Hauptwerkzeug, schätze ich jetzt mal ganz frei, aber auch mal gut zu wissen, dass das drumherum bei ARM auch so problemlos zu sein scheint. Auch schön zu sehen das Xilinx an uns denkt, wenn auch sicher nicht mit der selben Entschlossenheit wie an Windows User. Eine 2 für den MPS, das klingt ja gar nicht schlecht, der Controller an sich soll ja ganz toll zu programmieren sein soweit ich das verstanden hab, mal abgesehen von den Stromverbrauchseigenschaften. Das klingt doch mal nach was. Das piklab sieht ja sehr nett aus schon die Liste der unterstützen Backends lässt vermuten, das hier einiges zu erwarten ist. Auf jedenfall scheint der SDCC ja eine gewichtige Rolle zu spielen, den werd ich mir mal ansehen. Brauchen Z80 zwingend einen Bootloader? Wie verhält sich das eigentlich mit Assembler? Sollte ja eigentlich nicht zu schwierig zu Implementieren sein.
Michael Waiblinger wrote: > Wie verhält sich das eigentlich mit Assembler? Sollte ja eigentlich > nicht zu schwierig zu Implementieren sein. Gibt's wie Sand am Meer, in unterschiedlicher Qualität. Wenn sie nur einen Prozessor behandeln, orientieren sie sich für gewöhnlich in allen Punkten der Syntax maximal am Originalassembler. Dann gibt es noch Universalassembler, die für zigtausend Prozessoren assemblieren können, aber dafür normalerweise zumindest bei den Pseudo-Ops nicht jede Herstellermacke mitmachen. Zu letzteren zählt durchaus auch der GNU-Assembler selbst, der ja hinter dem GCC im Hintergrund werkelt.
Ich entwickel vollkommen problemlos R8C/M16C unter Linux. Olaf
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.