Mit welchem Programm programmiert ihr Controller?

Privat Freepascal auf dem STM32 und AVR, beruflich in C (ist aber nur 
eine Nebenaufgabe).

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

Visual studio code, plus passenden debugger.

Martin schrieb:
> Ich nutze die Arduino IDE für UNO und Nanos mit C.
Vermutlich doch eher in C++, oder?

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

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

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?

vscode und rust.

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.

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.

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 ;-)

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 ;-)

gcc mit vim, manchmal auch emacs.

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

AVR (ATmega/ATtiny): Bascom (Vollversion)
ESP32: Arduino
PC: Python oder Batch für "einmal hingerotzt und nie wieder verändert"

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?

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.

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:
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

Bascom mit ISP ist gut!

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.