Arduino oder GNU GCC wie hoch ist der Unterschied ?

Arduino hat riesige Vorteile -
...einarbeiten in kurzer Zeit,
... sehr gute IDE
...extrem viele Beispiele,
...viele Standardlibs und Standardfunktionen,
...sehr viele Applikationsbeispiele

  • aber auch ordentliche Grenzen,
  • keinen Einblick in Register und Timerverwendung.
  • Fehleranalyse schwierig

Wie schwierig ist der Umstieg und wie viele Libs existieren bei der AVR GNU GCC ?
Serielle mit Buffer?, One Wire, CRC, SD-Karte, Grafik LCD, Modbus, Stringverarbeitung, ???
oder muss man sich dann das meiste selber machen ?

Du musst dir nur die Libraries anschauen. Dann siehst du auch welche Timer verwendet werden. Ist meistens schnell aus dem Header ersichtlich.

Wie durch AVR C die Fehleranalyse besser werden soll verstehe ich nicht.

Und bei der IDE geht es auch besser. Visual Studio Community Edition oder Atmel Studio mit Visual Micro Plugin. Damit hast du alle Funktionen einer professionellen IDE. Für VM gibt es sogar einen (kostenpflichtigen) Debugger.

Ernst16:
Arduino hat riesige Vorteile -

Die Vorteile der Arduino-Umgebung waren für mich der Grund, meine Vorhaben in eben dieser Umgebung umzusetzen.

Als ich mit Arduino anfing, war mein erstes Interesse, den µC ohne das ganze Arduino-Geraffel programmieren zu können. Als ich dann „richtig loslegen“ wollte, ging mir allerdings ein Licht auf, als ich an die ganzen Bibliotheken dachte, die ich mir selbst hätte schreiben müssen und die in der Arduino-Umgebung standardmäßig zur Verfügung stehen.

Mein Kurz-Senf zur Sache: Nimm die Arduino-IDE. Alles Andere ist zu aufwändig. Obendrein bekommst Du hier kompetente Hilfe, wenn's mal klemmt.

Wenn Du es trotzdem ohne probieren möchtest: Hier das Makefile eines meiner damaligen Projekte.

HTH

Gregor

Ernst16:
Wie schwierig ist der Umstieg....

Kommt drauf an. Wenn du dir ne fest eingerichtete Eclipse-Umgebung saugst und nur noch auf "Clear All", "Make" und "Flash" drücken musst, ist der Aufwand gering und dann stellt sich die Frage, wieso du das eigentlich gemacht hast, da es dir wenig bringen wird.

Möchtest du wirklich auf eine nackte GNU-Toolchain wechseln bzw. diese wo einbinden, siehts ganz anders aus.
Hast du wenig Wissen über Instruction Sets, Assembler, C, Kompiliervorgänge, andere IDE's und den generellen Aufbau eines Prozessors, wie viele Arduino-Nutzer, dann wird diese Aufgabe im ersten Moment schier unlösbar sein. Da steckt einfach zuviel dahinter.

Du kannst alle Arduino-Libs weiterhin verwenden. Möglicherweise, musst du teils kleine Änderungen vornehmen, wenn du Arduino-Standardfunktionen nicht in dein Projekt einbindest.

Da du dies eigentlich wissen müsstest, als geübter uC-Entwickler, schätze ich deine Kenntnisse mal auf moderat bis gering ein.

In diesem Falle, würde ich dir wenns um kleine Projekte geht, empfehlen, vorerst bei Arduino zu bleiben. Du kannst ja bereits in der Arduino IDE Sachen machen, wie Register direkt ansprechen und son Kram. Aber voll aufs Ganze gehen, ist sehr heftig.

Willst du diesen Weg trotzdem gehen. Glückwunsch, du hast dir ein ehrgeiziges Ziel gesetzt, was du hoffentlich erreichst. Bleib am Ball, dann schaffst du das auch :smiley:
Dann würde ich dir zu Beginn empfehlen, Rechnerarchitekturen im Allgemeinen zu studieren. Das ist die Grundlage für alles.

Gruss

Felix

Ein Grund für den Wechsel wäre die beabsichtigte Nutzung des ATMEGA128 - habe zwar schon das einbinden in die IDE geschafft - aber mangels Chip noch nicht testen können. Im Forum habe ich noch keinen Erfolgsbericht hiefür gefunden. Der 1,-€ Chip hat 2 serielle, mehr Speicher, eine 16bit Timer mehr und ist gerade noch lötbar ...
Ich sehe schon - ein Umstieg wäre ein enormer Aufwand...

Hallo,

du könntest nach Core Bibliotheken schauen und diese in die IDE einbinden. Das heißt, jemand ganz Liebes hat sich die Mühe gemacht ein "Übersetzungsfile" zu schreiben für die IDE. Dann könnte man den Chip ganz normal wie gewohnt in der IDE programmieren. Die geänderte Pinbelegung/Namen muß man natürlich beachten.

haste Glück, gibt es ...

Alles andere in Atmel Studio oder Visual Studio wäre normale C Programmierung mit direkten Zugriffen. Die Hardware Schnittstellen sind im Datenblatt beschrieben mit Bsp. Das Datenblatt sollte man halbwegs verstehen. Den Rest der gewohnten Libs wie LCD oder Sensoren muß man selber schreiben wenn man keine findet. Oder die bekannten von Arduino umtexten. Kann mühsam sein. Also wenn du bis jetzt noch nie in der IDE mal für hier und da nackte "C Befehle" für direkte Zugriffe verwendest hast, dann wird der Umstieg hart. Lies dazu mal im Nachbarforum die Anleitungen, dann weiste was auf dich zukommt. Ich denke mit der Core Bilbliothek biste erstmal besser dran. Zudem gibt es fertige Boards die man wie die Arduino Boards behandeln kann. Google hilft.

Doc_Arduino:
haste Glück, gibt es ...
GitHub - MCUdude/MegaCore: Arduino hardware package for ATmega64, ATmega128, ATmega165, ATmega169, ATmega325, ATmega329, ATmega640, ATmega645, ATmega649, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega3250, ATmega3290, ATmega6450, ATmega6490, AT90CAN32, AT90CAN64 and AT90CAN128

Das habe ich auch schon erfolgreich implementiert und im Forum die Anleitung dazu gepostet. Allerdings warte ich noch auf das Board mit dem 128er von China ... - Praxistest schaut dann leider oft anders aus.

Doc_Arduino:
Alles andere in Atmel Studio oder Visual Studio wäre normale C Programmierung mit direkten Zugriffen.

Mit Visual Micro hat man allen Komfort der Arduino Software

Serenifly:
Mit Visual Micro hat man allen Komfort der Arduino Software

Das schaut ja perfekt aus - im Debugging Mode die Inhalte von Variablen sichtbar -
Hast du Visual Micro in Verwendung ?
Dauert es lange bis man das erste Erfolgserlebnis hat ?

Ernst16:
Das schaut ja perfekt aus - im Debugging Mode die Inhalte von Variablen sichtbar -

Mit einem einem Arduino und nem normalen USB-A/B-Kabel wird das wohl kaum funzen. Da brauchst du nen Programmer. Oder gibt es nen Arduino Bootloader mit eingebauten Debug-Funktionalitäten?

Ernst16:
Hast du Visual Micro in Verwendung ?

Ich programmiere schon lange nur damit, weil die Arduino IDE sehr lange Zeit nicht mal einfachste Dinge wie Zeilennummern hatte. Da hat sich in letzter Zeit einiges verbessert und sie ist inzwischen durchaus brauchbar. Sogar Code Folding gibt es inzwischen. Es fehlen aber immer noch Dinge, wie z.B. eine Variable wählen und direkt dahin zu springen wo sie deklariert ist.

Den Debugger habe ich nicht. Der kostet Geld. Schaut aber nicht besonders kompliziert aus.

Dauert es lange bis man das erste Erfolgserlebnis hat ?

Als Anfänger kann es sein, dass dich die Funktionalität der IDE erschlägt und du bestimmte Sachen vor lauter Menüs nicht findest. Ich verwendete Visual Studio aber auch schon längere Zeit vorher für C# und C++. Daher war es für mich kein Problem

Aresloom:
Mit einem einem Arduino und nem normalen USB-A/B-Kabel wird das wohl kaum funzen. Da brauchst du nen Programmer. Oder gibt es nen Arduino Bootloader mit eingebauten Debug-Funktionalitäten?

Es gibt das debugWire Interface, das nur (per Fuses) aktiviert werden muß, und dann über den RESET Pin ansprechbar ist. Ob das allerdings über USB funktioniert, entzieht sich meiner Kenntnis. Funktioniert der AVR Debugger über USB, oder braucht der ein eigenes Kabel oder Programmer?

Unter Debugger ist hier offensichtlich nicht gemeint das von den Registern des Prozessors gelesen werden kann, sondern es wird von VisualStudio ein kleiner Code dazugemischt der eben die Variablen bzw. die Breakpoints an die IDE weitergibt.
Solche Programmer hätte ich im übrigen vermutlich alle: MK3, STK500, MK1 teilweise Original und Nachbauten.
Also bis ich einen neuen Bootloader in den 128er bekomme wäre ich gerüstet.

Es ist keine gute Idee, eine IDE extra Debug-Code hinzuzufügen zu lassen, schon garnicht zu einem Realtime-Programm. Das würde auch garnicht funktionieren, wenn das Programm Serial für andere Zwecke verwendet.

Kommt darauf an. In normalen C++ Compilern ist Debug Code auch nicht zwangsweise das gleiche wie Release Code (vor allem bezüglich der Optimierung) und gibt gemeine Bugs die nur in einem oder dem anderen auftauchen.
Auf dem Arduino muss das nicht unbedingt problematisch sein, solange das Programm nicht sehr zeit-kritisch ist. Es gibt genug Programme die lange Zeit nichts tun. Welches Serial Interface verwendet wird kann man einstellen.

Ein richtiges Debug Interface ist natürlich was anderes. Das heißt aber nicht dass es die einzige Option ist.

Den Unterschied zwischen Debug und Release stellt der Programmierer ein. Sind beide Einstellungen gleich, sind die erzeugten Programme identisch. Wenn Fehler nur in einer Version auftreten, dann liegt das entweder an zu aggresiver Optimierung, oder an eingeschalteten Laufzeittests (Index-Bereiche...), die Fehler im Programm aufdecken.

Der Grad der Optimierung läßt sich in der Arduino IDE nicht einstellen, und diese Standard-Optimierung ist ziemlich aggressiv. Laufzeittests können ebenfalls nicht automatisch eingefügt werden, was allerdings weitgehend an der unsicheren Sprache und Verwendung von C liegt. Wenn nun der Programmierer eigenen Debug-Code einfügt, kann ein Fehler (aufgrund weniger Optimierungsmöglichkeiten) verschwinden, und das ist wirklich nicht hilfreich.

Da die meisten Arduinos nur über eine einzige serielle Hardware-Schnittstelle verfügen, wird die oft für andere Zwecke verwendet. Wenn dann zum Debuggen zusätzlich eine Verbindung zum Serial Monitor eingefügt wird, hat das weitreichende Konsequenzen für das ganze Programm.

Mit Visual Micro hat man allen Komfort der Arduino Software.

ja ist klar. :slight_smile:
Ich habe sein anliegen anders verstanden. In der Form das er komplett umsteigen wollte um seinen 128er zu programmieren. Und fragte wie und woher er nun seine gewohnten Libs bekommt. Die es so nun nicht gibt.

Wenn er die Core Bibliothek hat und in die IDE einbindet, dann kann er auch bei der Arduino IDE bleiben.
Und wenn er wechselt mit Visual Micro Plugin, dann kommt am Ende das gleiche bei raus. Die zusätzlichen Möglichkeiten der Studios muß man auch erstmal nutzen lernen.

Das mit der 2. Seriellen ist der Hauptgrund für den 128er - da ich dann den seriellen Monitor - eventuell die Neuprogrammierung (wenn ich das mit dem Bootloader hinkriege) nutzen kann und dennoch eine Hardware 2. Serielle für die Anwendungen habe.
Also dem Arduino werde ich treu bleiben - wurde ausführlich argumentiert.
Betreffend Laufzeitverlust mit Debugcode - dieser ist äußerst gering und wird wohl nur für aktivierte Variablen eingefügt werden - das müsste schon eine extrem zeitkritische Anwendung sein das etwas beeinflusst wird.
Habe mir den Zeitverlust einer seriellen Übertragung (Bytes in den internen Puffer schreiben) mit dem Logik Analyzer angeschaut - sehr gering.

DrDiettrich:
Wenn Fehler nur in einer Version auftreten, dann liegt das entweder an zu aggresiver Optimierung, oder an eingeschalteten Laufzeittests (Index-Bereiche...), die Fehler im Programm aufdecken.

Oder die Fehler überdecken. Debugger können z.B. Variablen initialisieren, während das im eigentlichen Code nicht gemacht wird. Oder generell das Laufzeitverhalten verändern. Es gibt nicht ohne Grund einen Namen für Bugs die beim Debuggen verschwinden: Heisenbug

Ein Debugger, der eigenwillig den zu debuggenden Code verändert, verdient diese Bezeichnung nicht. Wenn bei der Verwendung solcher Tools Fehler verschwinden können, dann zeigt das doch eindeutig die Unbrauchbarkeit eines solchen Tools für die ernsthafte Fehlersuche. Ebenso die Unfähigkeit von Leuten, die sich mit solchen Tools beschäftigen, statt sich erst einmal ein brauchbares Entwicklungssystem zu suchen :-]

Wenn solche Probleme gemeldet werden, dann sitzt der größte Bug meist vor dem Bildschirm. Wer seine Unfähigkeit auf Heisenberg schiebt, der sollte sich eine einfachere Beschäftigung suchen, die ihn nicht so überfordert :-]

Es gibt zwar Tools, die für spezielle Analysen (Aufrufstatistik, Timing...) speziellen Code einfügen, doch das sind eben Analyse-Tools und keine Debugger.

Zudem muß man bei der Steuerung eines Systems berücksichtigen, daß asynchrone Vorgänge (PWM Ausgänge, Encoder-Eingänge...) ihr eigenes Timing haben, das beim Anhalten des Prozessors weiterläuft und deshalb beim Debuggen mit solchen Methoden zu ganz neuen Fehlern führen kann. Dann bleiben nur Debug-Ausgaben, die in der Zeit ausgeführt werden, in welcher der Prozessor nichts anderes zu tun hat. Oder die Verwendung eines Emulators, ggf. ICE, der eine rückwirkungsfreie Beobachtung des Systems in Echtzeit erlaubt. Aber bei den Problemen, um die es in diesem Forum meist geht, ist so ein Aufwand eher nicht notwendig.