mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik uC Entwicklung unter Linux (vs AVR)


Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich entwickel vollkommen problemlos R8C/M16C unter Linux.

Olaf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.