Welches Programm, also Compiler und welche Programmiersprache nutzt ihr für 8Bit AVR und 32Bit ARM Controller? Und würdest ihr lieber was anderes nutzen? Und wenn, warum geht das nicht? Wer dieses Thema für unsinnig hält, enthält sich einfach;-) Du schaffst das.
Ich nutze die Arduino IDE für UNO und Nanos mit C. Hier suche ich eigentlich eine bessere IDE-Lösung mit Versionsverwaltung, gˋscheiten Programm-Vergleichsmöglichkeiten und evtl. Debugging. Microchip PICs programmiere ich in Assembler mit MPLAB X IDE. Ja, so was gibts heute noch. Bin zu faul auf C umzusteigen und kenne auch keinen kostenlosen C-Compiler. Tipps are welcome!
Martin schrieb: > Hier suche ich eigentlich eine bessere IDE-Lösung mit > Versionsverwaltung, gˋscheiten Programm-Vergleichsmöglichkeiten und > evtl. Debugging. http://stefanfrings.de/avr_tools/index.html#ide http://stefanfrings.de/esp8266/index.html#otheride
Martin schrieb: > Ich nutze die Arduino IDE für UNO und Nanos mit C. Vermutlich doch eher in C++, oder?
Paul Kistner schrieb: > Welches Programm, also Compiler und welche Programmiersprache nutzt ihr > für 8Bit AVR und 32Bit ARM Controller? C, seltener C++, GCC > Und würdest ihr lieber was anderes nutzen? Clang vielleicht, mal gucken. ;-) Beruflich Keil, aber allein schon das Lizenzgewurschtel ist abstoßend.
EAF schrieb: > Martin schrieb: >> Ich nutze die Arduino IDE für UNO und Nanos mit C. > Vermutlich doch eher in C++, oder? Ja, nur den Unterschied habe ich noch nie verstanden ;-) Aber Hauptsache, die Programme funktionieren.
Martin schrieb: > Ja, so was gibts heute noch. Bin zu faul auf C umzusteigen und kenne > auch keinen kostenlosen C-Compiler. Hä? Bei Microchip gibt's doch für alle Architekturen kostenlose Compilerversionen??
GCC, C++. Zufrieden ja, aber Rust könnte mal eine Alternative werden. C++ ist halt sehr technisch, aber man brauchts auf den µC auch oft genug.
Ich selbst nutze am PC FreePascal / Lazarus Mir ist aufgefallen, das Pascal Programmierer eigentlich, bis heute, immer vollständig die Programme anbieten, also ohne Abhängigkeiten von DLLS. Das schöne ist das die Programme nicht installiert werden müssen, sondern beliebig hin und her kopiert werden können. Klar, das geht bei C auch, nur da wird es so gut wie nie gemacht. Ständig bekommt man die Meldung das man von MS irgendwelche Frameworks nachinstallieren muss, ätzend. Und das bisschen Speicher, das meistens dadurch mehr benötigt wird, ist ja echt kein Thema mehr. Auf Controllern nutze ich ebenfalls ausschließlich Pascal. Der einzige Grund gelegentlich mal ein Blick auf die andere Seite zu werfen ist die größere Vielfallt an Libs. Jedoch werden das seit einiger Zeit eher Arduino Schnipsel.... Aber dennoch bevorzuge ich alles in allem, als Programmiersprache Pascal
Pail Kistner schrieb: > Auf Controllern nutze ich ebenfalls ausschließlich Pascal. Dann solltest du aber zumindest mal dazu schreiben, welcher Compiler und welche Controller. Ist ja nun nicht so, dass das so verbreitet wäre wie Sand am Meer in diesem Umfeld.
Auf dem Controller Mikroe Pascal Beschäftige mich aber auch da immer wieder mit FreePascal und hoffe das sich da auch die Anzahl der vorgefertigten Definitionsdateien weiter erhöt
Pail Kistner schrieb: > Und das bisschen Speicher, das meistens dadurch mehr benötigt wird, ist > ja echt kein Thema mehr. Deswegen hat Google bei der Sprache Go auf dynamisch gelinkte (Go) Bibliotheken verzichtet. Die sagen auch: Braucht man nicht mehr, ist nur unnötig kompliziert.
eben so sieht es aus. Ich bin eigentlich auch ein Sparfuchs wenn es um Speicher und Rechenleistung geht, aber das habe ich inzwischen aufgegeben. Offenbar bin ich der Einzige der das so sieht. Daher sehe ich eher den praktischen Nutzen darin, Programme beliebig auf einen Stick etc hin und her kopieren zu können und spare mir den Nervfaktor mit den MS Komponenten die ewig nachgeladen werden müssen. Und bei Pascal ist das halt default:-)
Mit dem, welches mitgeliefert wird. Sei es Atmelstudio, STM32CubeIDE oder Dave. Mir egal.
Da Brain schrieb: > Visual studio code, plus passenden debugger. Also kurz gesagt: in Wirklichkeit Arduino IDE :-D
Privat AVR in C und Assembler mit GCC als Compiler, AVRA als Assembler und VS Code als IDE. Da ich nur 'nen ISP und keinen JTAG habe, kann ich ohnehin nicht live debuggen und behelfe mir dann da mit Debug-Ausgaben über seriell, Display oder im schlimmsten Fall LEDs. Arduino.. ja, die Hardwaremodule nehme ich gerne mal her, wenn ich keinen Bock habe, extra eine Schaltung zu entwerfen. Aber die "IDE" und diese vermurkste Bibliothek... nein. Da wird dann auch einfach in C mit GCC programmiert und vmo Arduino bleibt nur noch der Bootloader in Benutzung, AVRdude kann ja zum Glück Arduino direkt flashen, ist also letztlich nur eine andere Zeile im Makefile, ob ich auf nen Arduino flashe oder auf eine eigene Schaltung per ISP. Bei der Arbeit ARM in C (und ganz wenig Assembler) mit einer sacketeuren Compilerumgebung von Green Hills, die aber (vermutlich aufgrund des Alters) einen fürchterlichen Editor hat. Also auch VS Code, Mit ein paar Batchdateien Kommandozeilen-Buildscripts gebastelt, und die grafischen Tools rund um den Compiler nur noch zum Debuggen.
Sowohl Atmel als auch STM32 jeweils in C. Für die STM32 nehme ich SW4STM32, bei den Atmel Atmel Studio. Beides mit gcc
Hi, beruflich Visual Studio, C++, GCC, Keil mit Clang und immer das was man gerade dafür braucht :-) Gruß Daniel
Da Brain schrieb: > Visual studio code, plus passenden debugger. Thomas schrieb: > Also kurz gesagt: in Wirklichkeit Arduino IDE :-D Da würde ich auch gerne mal nachhaken. Denn nach meinem Kenntnisstand gibt es keine praktikable Alternative zum Atmel Studio, wenn man AVR Controller debuggen will. Da Brain, hast du etwa eine entsprechende Lösung für Visual studio code gefunden?
Stefan ⛄ F. schrieb: > Da würde ich auch gerne mal nachhaken. Denn nach meinem Kenntnisstand > gibt es keine praktikable Alternative zum Atmel Studio, wenn man AVR > Controller debuggen will. Es gibt keine (bzw. keine so einfach einsetzbare) Alternative, wenn man AVR Controller SIMULIEREN will, aber debuggen auf der Hardware geht mit gdb und passendem Programmieradapter, und damit mit alle IDEs, die die toolchain benutzen, wenn man die dazu benötigte Hardware hat. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > debuggen auf der Hardware geht mit > gdb und passendem Programmieradapter Ich habe das mal mit einem Dragon versucht, hat nicht geklappt. Sämtliche Anleitungen dazu waren offenbar veraltet und ich bekam Fehlermeldungen zu denen ich keine Erklärungen fand. Ich habe den Dragon inzwischen an jemanden veräußert, der ihn mit dem AVR Studio benutzen wollte. Dennoch würden sich bestimmt viele über einen Link zu einer funktionierenden Anleitung freuen. Das wäre sicher auch einen separaten Artikel auf Mikrocontroller.net wert.
Stefan ⛄ F. schrieb: > Insofern würde ich mich über einen Link zu einer funktionierenden > Anleitung durchaus freuen. Aus den release-notes: "# $Id: NEWS 308 2012-11-05 16:41:14Z joerg_wunsch $ Summary of changes in AVaRICE 2.13" Vielleicht liest er deinen Wunsch ja ;) Oliver
Pail Kistner schrieb: > Auf Controllern nutze ich ebenfalls ausschließlich Pascal. Pail Kistner schrieb: > Ich bin eigentlich auch ein Sparfuchs wenn es um Speicher und > Rechenleistung geht, Öhm. ;-) Zum Thema: 8-Bit AVR: gcc (Assembler nur bei Tiny10), Kate als Editor + makefiles 32-Bit (LPC) MCUXpresso IDE (C) (Debug mit BMP) ESP: Arduino PC: Lazarus (Freepascal)
Stefan ⛄ F. schrieb: > Ich habe das mal mit einem Dragon versucht, hat nicht geklappt. Das Problem von Dragon (und dem alten JTAGICEmkII) war, dass sie massiv auf den Einsatz mit AVR Studio 4 "optimiert" waren: das hatte einen selbst gestrickten Debugger, und manche Dinge, die üblicherweise halt der Debugger erledigt, hat man dort (mit relativ viel Aufwand vor allem hinsichtlich des notwendigen RAMs) auf das ICE ausgelagert. Das hatte aber zur Folge, dass diese Teile nur mit AVR Studio 4 einigermaßen schnell waren. Andere (aufwändiger gebaute) Debugger wie GDB oder auch später der Visual-Studio-Debugger vom Atmel Studio konnten diese Features nicht nutzen, und übrig blieb ein vergleichsweise langsames Transportinterface über den USB. Mit den Nachfolgern (dem kurzlebigen JTAGICE3 und dem Atmel ICE) haben sie das behoben. Allerdings wären die Änderungen in AVaRICE für die Anpassung auf das CMSIS-DAP-Protokoll so umfassend gewesen, dass ich nie Zeit und Nerven hatte, das ordentlich zu implementieren. Das ist daher alles ein bissel halbgar. Für ARMs kann man dann OpenOCD benutzen, das läuft sauber mit einem Atmel ICE (auch mit nicht-Atmel-ARMs ;-).
immer noch Mbed mit VSCode, so langsam auch mit CMake.
Wird langsam Zeit, dass das alte Zeug ausstirbt. Nichts gegen AVR, sind an sich schöne Controller. Nur das Tooling ist halt leider sehr eigenwillig, gerade wenn ich das mit den Adaptern oben lese. Mit einem offenen Tooling ist es z.B. kein Problem sich eine Debugausgabe (ala printf("some debug message")) über einen beliebigen Debugadapter selbst zu stricken, auch parallel z.B. zum Flashen neuer Software oder einer offenen GDB session. Dank OpenOCD bekommt man dann schön seine Meldungen ins Terminal und braucht keinen zusätzlichen Debug Port an der Hardware der meist auch langsamer ist.
Johannes schrieb: > Wird langsam Zeit, dass das alte Zeug ausstirbt. Nö, die 8-Bit Controller haben immer noch ihre Berechtigung. 32-Bitter braucht man eigentlich nur, wenn Displays, SD Karten und ähnliches ins Spiel kommen.
Johannes schrieb: > Wird langsam Zeit, dass das alte Zeug ausstirbt. Du wirst mit Sicherheit vor denen ausgestorben sein.
Der Klassiker, gleich 2 Leute outen sich als unfähig zu lesen.
Direkt nach dem zitierten Satz schrieb ich:
> Nichts gegen AVR, sind an sich schöne Controller.
Lässt sich daraus eine Abneigung gegen 8bitter konstruieren? Nein.
Noch schöner ist natürlich gleich die persönliche Schiene die gefahren
wird. So macht man keine gute Werbung für seine Firma ;-)
ESP32: MicroPython(PyCharm) und Arduino C++ (IDE) ESP32S2, nrf52840, PiPico: CircuitPython (pyCharm) Micro/Circuitpython, weil ich eher Steuerungen/Spiele mache, die nicht zwingend Echtzeit Reaktionen brauchen, aber ich mich so auf die Steuer/Spiellogik konzentrieren kann und auch Bibliotheken für viele Sensoren und Displays habe.
Johannes schrieb > Wird langsam Zeit, dass das alte Zeug ausstirbt. > Lässt sich daraus eine Abneigung gegen 8bitter konstruieren? Ja, das würde ich so sehen. Dafür sehe ich aber die extremen Anfeindungen nicht, von denen Du sprichst. Sowas ist bei MC.net schon fast ein zärtlicher Umgangston ;-)
Jörg W. schrieb: > Hildegard schrieb: >> vscode und rust. > > Auf welchem Controller läuft Rust? Auf allen wichtigen, oder? Na gut, es braucht noch ein wenig Handarbeit... https://rust-gcc.github.io/ Ach so, die Frage war ja eine andere, also C, vim, make, gcc, binutils und Macroassembler, vim, as (http://john.ccac.rwth-aachen.de:8000/as/as_EN.html)
:
Bearbeitet durch User
Paul Kistner schrieb: > Wer dieses Thema für unsinnig hält, enthält sich einfach;-) Du schaffst > das. +1 :) Na gut, auch noch zur Frage: beruflich (aber selten, da ich Hardwareentwickler bin): AVR: C mit Atmel Studio 7.0, STM32: C mit STM32CubeIDE, nein. (Ich würde auf Controllern derzeit nix anderes machen wollen.) War zwar nicht die Frage, ich schreib's aber trotzdem: Beruflich und privat auf dem PC nur noch Python mit Spyder.
:
Bearbeitet durch User
Prokrastinator schrieb: > Johannes schrieb >> Wird langsam Zeit, dass das alte Zeug ausstirbt. >> Lässt sich daraus eine Abneigung gegen 8bitter konstruieren? > Ja, das würde ich so sehen. Ich schrieb: > Wird langsam Zeit, dass das alte Zeug ausstirbt. > > Nichts gegen AVR, sind an sich schöne Controller. Wenn man korrekt zitiert nicht ;-) Prokrastinator schrieb: > Dafür sehe ich aber die extremen Anfeindungen nicht, von denen Du > sprichst. > Sowas ist bei MC.net schon fast ein zärtlicher Umgangston ;-) Ja das stimmt. ... leider
Beitrag #6855009 wurde von einem Moderator gelöscht.
Beitrag #6855015 wurde von einem Moderator gelöscht.
AVR (ATmega/ATtiny): Bascom (Vollversion) ESP32: Arduino PC: Python oder Batch für "einmal hingerotzt und nie wieder verändert"
Paul Kistner schrieb: > Welches Programm, also Compiler und welche Programmiersprache nutzt ihr > für 8Bit AVR Hallo, da ich nur privat programmiere, nutze ich für den AVR das AVR-Studio mit AVR-GCC für Programmierung in C, oder AVRASM für Assembler, wobei es da noch andere Assembler gibt. Dann Ponyprog oder Avrdude. mfG
Bauform B. schrieb: > Auf allen wichtigen, oder? Na gut, es braucht noch ein wenig > Handarbeit... > https://rust-gcc.github.io/ Verstehe ich das richtig, Rust wird erst mal in C/C++ übersetzt damit am Ende der gcc daraus ein binarie baut? Wenn ja, warum tut man sich diese Klimzüge an?
temp schrieb: > Verstehe ich das richtig, Rust wird erst mal in C/C++ übersetzt damit am > Ende der gcc daraus ein binarie baut? Wenn ja, warum tut man sich diese > Klimzüge an? Das sehe ich nicht so. Der gcc ist nicht mehr nur der C-Compiler, sondern die GNU compiler collection. C ist nur ein Teil davon. Für jede unterstützte Sprache gibt es ein Frontend, das in irgendwas internes übersetzt. Ab da geht es dann unabhängig von der ursprünglichen Sprache weiter. Bei deinem Link geht es um ein solches zusätzliches Frontend, das halt Rust vorübersetzt. Aber nicht nach C, sondern in das interne Format.
:
Bearbeitet durch User
Johannes schrieb: > Prokrastinator schrieb: >> Dafür sehe ich aber die extremen Anfeindungen nicht, von denen Du >> sprichst. >> Sowas ist bei MC.net schon fast ein zärtlicher Umgangston ;-) > > Ja das stimmt. > > ... leider Johannes schrieb: > Der Klassiker, gleich 2 Leute outen sich als unfähig zu lesen. Aha. Wie war das nochmal mit dem Wald? ;-) (OK, Deiner kam später, aber ersteres würde ich auch nicht als persönlichen Angriff definieren) Johannes schrieb: > Ich schrieb: >> Wird langsam Zeit, dass das alte Zeug ausstirbt. >> >> Nichts gegen AVR, sind an sich schöne Controller. > > Wenn man korrekt zitiert nicht ;-) Doch. Erst sollen die AVRs aussterben, dann kommt eine kleine Einschränkung nach dem Motto: soo schlimm sind die ja eigentlich nicht. Das kann man lesen wie man will. Mit den Tools gebe ich Dir Recht, das kommt an die 32 Bitter bei weitem nicht ran.
Beobachter. schrieb: > gcc mit vim, manchmal auch emacs. Warum tut man sich das an? Ok, cooler Hacker-style, aber ... Ich liebe Visual Studio mit seinen ganzen Debug Möglichkeiten, mir ist selbst VS Code schon zu minimalistisch :-) Ich kann auch mit vi und gcc umgehen, finde es nur umständlich. Ich mag es, mich auf meine Aufgabe, und nicht auf die Tools zu konzentrieren. Tools müssen funktionieren.
Random .. schrieb: > Beobachter. schrieb: >> gcc mit vim, manchmal auch emacs. > > Warum tut man sich das an? Weil es einfach mal funktioniert? Weil man auf die Weise eine konsistente Entwicklungsumgebung über alle Targets hinweg hat? > Ok, cooler Hacker-style, aber ... Es geht halt nichts über ein gepflegtes Vorurteil, oder? Denn vim oder Emacs kennst du ganz offensichtlich nicht. > Tools müssen funktionieren. Genau so, darum benutze ich privat übrigens auch Emacs für alle Entwicklungsarbeiten.
Random .. schrieb: > Ich liebe Visual Studio mit seinen ganzen Debug Möglichkeiten, mir ist > selbst VS Code schon zu minimalistisch :-) Dafür wächst VSCode täglich durch die vielen Extensions, auch das Debuggen für die Cortex-M wird noch stetig weiterentwickelt. Und git ist bei VSC um Längen besser integriert als beim großen VS Studio. Sehr cool an VSC ist auch man sich mit einem Remote Rechner verbinden kann und dann komplett auf dem Remote arbeitet. Remote kann dabei auch das WSL auf dem Windwos Rechner sein. Bei Projekten mit vielen Quellcodedateien macht das Freude, gcc unter Linux kompiliert/linkt immer noch um einiges schneller als unter Windows.
Johannes S. schrieb: > Sehr cool an VSC ist auch man sich mit einem Remote Rechner verbinden > kann und dann komplett auf dem Remote arbeitet. Cool, dass man das nach gefühlt einem halben Jahrhundert immer noch cool findet ;)
naja, es gibt ja immer noch Leute die VSCode für nur irgendeine IDE halten, und dieses Feature haben nicht viele.
Johannes S. schrieb: > Dafür wächst VSCode täglich durch die vielen Extensions Ich fürchte es wird wie Eclipse enden: Gewaltig groß und träge. Aber wir werden sehen. Momentan gefällt mir vscode gut.
Also 70% C 25% Pascal und etwas Basic bzw sonstiges noch Ich selbst nutze nahezu ausschließlich Freepascal am PC und wenn immer möglich auch Pascal auf dem Controller (MikroE)
Stefan ⛄ F. schrieb: > Ich fürchte es wird wie Eclipse enden: Gewaltig groß und träge. Da bin ich mir sicher das es nicht so ist. Extensions lassen sich auch je Verzeichnis abschalten wenn die irgendwo stören. Und es ist schon deutlich schlanker und übersichtlicher als das Java Eclipse. Habe gestern den STLink GDBServer in VSCode/ Cortex-Debug eingebaut. Das nutzt die ST Installation wo der GDB Server im Java vergraben ist. Unter Windows wird das automatisch gefunden, unter Ubuntu war das eine lange Suche. Da hat sicher nicht jeder Bock drauf, aber trotzdem ist so etwas lösbar. Und die Extensions sind als Source auf GitHub verfügbar, und können selbst im VSCode Debugger laufen.
Hallo , ich benutze seid ca. 15 Jahren die Compiler von Mikroelektronika für PIC, PIC32 und ARM. Habe damit auch relativ große Projekte inclusive 7 Zoll TFT mit STM32F7 zum Erfolg gebracht.Ganz selten MPLAB und Thonny (Micropython) Frank
Beruflich und Privat c mit Visual Studio. Je nachdem ob CPU oder Mikrocontroller noch mit dem VisualGDB Plugin. Macht alles sehr angenehm.
Beruflich: Editor ist Eclipse Compiler/Linker IAR/MSP430 oder IAR/STM32... (-> BuildServer) Privat: dazu ein Sammelsurium aus den alten Zeiten (alt_beruflich + privat): * FreescaleCodeWarrior für alte Nitron HC08-Chips * MPLAP für (alte) PIC's * PsOC-Creator von Cypress Semi * zT. AVR
...dazu kommt noch (beruflich wie auch privat): Python
MaWin schrieb: > Bascom mit ISP ist gut! Liebster MaWin ... Es wurde nicht nach gut und böse gefragt. Sondern, was "du" verwendest. Ich mache dir es mal vor: Früher, war Forth mein Ding auf Controllerboards. z.Zt. ist es Arduino, oder besser gesagt: C++ Die IDE ist etwas spartanisch, aber so eine breit gefächerte µC Abdeckung, und das so Problemlos, habe ich woanders noch nicht gefunden.
Ich benutze gerne für möglichst alles Eclipse mit GCC-Compilern. Da wird dann zu 99,999% in C oder C++ programmiert - zumindest ist dies so, solange wir bei Mikrocontrollern bleiben. (AVR-Mikrocontroller habe ich allerdings schon immer selten benutzt und jetzt schon >10 Jahre kein einziges Mal mehr.)
EAF schrieb: > Die IDE ist etwas spartanisch Die V2 beta gits doch auch schon länger, das ist doch keine große Umgewöhnung bei deutlich mehr Funktionsumfang.
Johannes S. schrieb: > Die V2 beta gits doch auch schon länger, das ist doch keine große > Umgewöhnung bei deutlich mehr Funktionsumfang. Schon getestet. KO Kriterien: Leider keine portable Installation, auch keine Möglichkeit den Code Formatter zu konfigurieren. Das muss also noch ein wenig reifen, bis das für mich nutzbar wird.
Paul Kistner schrieb: > Welches Programm, also Compiler gcc und vor ewigen Zeiten Keil C51/ASM51. 16 Bitter hast du ja nicht gefragt... > und welche Programmiersprache nutzt ihr Heute praktisch nur noch C. > für 8Bit AVR 8 Bitter greif ich schon lange nicht mehr an. Und Atmel generell eh nur unter Zwang. > und 32Bit ARM Controller? Zwar nicht gefragt, aber IDE ist bevorzugt Rowley Crossworks.
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.