Gast
#7260209
Hallo, ich programmiere gerade einen ATMega328 mit Arduino und bin bei 80% Flash. Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch etwas zu komprimieren?
Peter schrieb: > Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch > etwas zu komprimieren? Nicht wirklich, da wird schon auf minimale Codegröße optimiert. Wie sieht dein Programm aus? Spaghetticode oder viele Funktionen? AVR-GCC-Codeoptimierung Hinter der Arduino-IDE steckt der avr gcc, also sind viele der Vorschläge machbar, wenn gleich nicht immer sinnvoll.
Peter schrieb: > Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch > etwas zu komprimieren? soweit ich weiss ja. https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung preferences.txt
Gast
#7260273
Peter schrieb: > Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch > etwas zu komprimieren? Meiner Einschätzung nach: Das ist die falsche Frage!
Gast
#7260293
Gibt es nicht auch noch einen Arduino Due, mit mehr Speicher?
Beitrag #7260296 wurde von einem Moderator gelöscht.
Peter schrieb: > Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch > etwas zu komprimieren? Die beste Optimierung macht Brain 1.0. Also kein C&P bis der Arzt kommt (sog. Spaghetticode), sondern Unterteilung in Unterfunktionen und Schleifen.
Gast
#7260306
Benutzt du bereits PROGMEM und F-Strings für konstante Strings? https://www.arduino.cc/reference/en/language/variables/utilities/progmem/
PittyJ schrieb: > Gibt es nicht auch noch einen Arduino Due, mit mehr Speicher? mir gefiel der 1284p https://github.com/JChristensen/mini1284 http://www.amateurfunkbasteln.de/arduino1284/index.html https://prominimicros.com/how-to-use-the-pro-mini-xl-or-atmega-1284p-with-the-arduino-ide/ https://github.com/MCUdude/MightyCore https://ednieuw.home.xs4all.nl/Woordklok/ATMEGA1280P_Project/Project_around_the_ATMEGA1284P.htm
Steve van de Grens schrieb: > Benutzt du bereits PROGMEM und F-Strings für konstante Strings? > > https://www.arduino.cc/reference/en/language/variables/utilities/progmem/ Wenn er FLASH sparen will hilft das nix, nur RAM.
Gast
#7260373
Falk B. schrieb: > Wenn er FLASH sparen will hilft das nix, nur RAM. Ach ja. Ich weiß gar nicht warum ich an RAM dachte. Hat er doch klar geschrieben. Sorry.
Steve van de Grens schrieb: > Falk B. schrieb: >> Wenn er FLASH sparen will hilft das nix, nur RAM. > > Ach ja. Ich weiß gar nicht warum ich an RAM dachte. Hat er doch klar > geschrieben. Sorry. aber er könnte Texte und Konstanten ins EEMEM auslagern, raus aus dem flash spart auch. Dummerweise löscht die IDE auch den EEPROM, wer das verhindert kann den MEM nutzen.
Beitrag #7260539 wurde von einem Moderator gelöscht.
Gast
#7260559
Peter schrieb: > Hallo, > ich programmiere gerade einen ATMega328 mit Arduino und bin bei 80% > Flash. Auf das Arduino-Framework und den damit verbundenen Overhead verzichten.
Gast
#7260574
Alt G. schrieb im Beitrag #7260539:
> Wäre mir neu dass die arduino ide den eprom löscht.
Tut es nicht!
Tut es doch!
Beides ist wahr.
Zuständig, für das Verhalten, ist die EESAVE Fuse.
Also nicht die Arduino IDE.
Gast
#7260587
Bei Arduino Nanos verhilft der Optiboot Bootloader zu etwas mehr Programmspeicher. In einer Endversion des Sketches kann man z.B. nicht unbedingt nötige serielle Ausgabe abschalten, die vorher zum Debuggen erforderlich waren. Manchmal hilft auch ein Blick in die Libraries und deren Entschlacken. Und direkte Portmanipulation statt digitalWrite() etc. Hardcore wäre dann noch, auf Assembler umzusteigen 🥳
Gast
#7260595
Martin schrieb: > Bei Arduino Nanos verhilft der Optiboot Bootloader zu etwas mehr > Programmspeicher. Leider nicht! Nur, wenn man den UNO Bootloader auf den Nano spielt.
EAF schrieb: > Beides ist wahr. > Zuständig, für das Verhalten, ist die EESAVE Fuse. > Also nicht die Arduino IDE. genau, ich vergaß aber in der Programmentwicklung setzt man üblicherweise EESAVE nicht ausser man kennt schon alle Texte, dann ist das eine Option
Auf den Bootloader pfeifen, spart auch nochmal rund 2 kb ;-) Wenn du nur 1x über USB programmierst, oder einen ISP Programmer (z.B. USBasp) hast, ist das möglich.
Gast
#7260737
Joachim B. schrieb: > aber in der Programmentwicklung setzt man > üblicherweise EESAVE nicht Du vielleicht nicht! Aber du bist nicht "man", zumindest nicht "jederman"
Gast
#7260771
Peter schrieb: > bei 80% > Flash. für ungenutzten Flash bekommst du kein Geld zurück. Wenn du Flash sparen willst um noch mehr Funktionalität einzubauen, zeig mal deinen Code her.
EAF schrieb: > Du vielleicht nicht! stimmt, ich fine ISP Programmierung lästig, immer das 6-polige Kabel suchen den Prommer.
Gast
#7260791
Joachim B. schrieb: > stimmt, ich fine ISP Programmierung lästig, immer das 6-polige Kabel > suchen den Prommer. Ist das eine Nebelkerze, oder nur ein arg schräges Argument?
EAF schrieb: > Ist das eine Nebelkerze, oder nur ein arg schräges Argument? die passende Antwort auf Gepöbel
Joachim B. schrieb: > immer das 6-polige Kabel > suchen den Prommer. und darum hab ich beim freundlichen Chinesen gleich 3 Stück davon bestellt und alle auf die letzte verfügbare FW geflasht und die Jumper eingelötet, um auch den Speed drosseln zu können, weil neue Prozzis ab Werk mit 1 MHz takten. Zu "Friedenszeiten" haben die Dinger unter 2€ p. Stck gekostet. Eins davon taucht immer irgendwo auf. ;-)
Gast
#7260836
Gerald B. schrieb: > alle auf die letzte verfügbare FW geflasht und die Jumper > eingelötet Meine stelle die Geschwindigkeit automatisch runter, ohne Jumper, ohne Firmware Upgrade. Die sind schon ein paar Jahre alt.
Gast
#7260935
EAF schrieb: > Martin schrieb: >> Bei Arduino Nanos verhilft der Optiboot Bootloader zu etwas mehr >> Programmspeicher. > Leider nicht! Verstehendes Lesen ist nicht Dein Ding? > Nur, wenn man den UNO Bootloader auf den Nano spielt. Genau das wird Martin gemeint haben, den Bootloader austauschen. Gerüchteweise soll es auch Nanos geben, wo ab Werk der Optiboot drauf ist. Ob das helfen könnte, wissen wir aber nicht, Peter (Gast) hat nicht geschrieben, welchen Arduino er benutzt. noiasca schrieb: > Peter schrieb: >> bei 80% Flash. > für ungenutzten Flash bekommst du kein Geld zurück. Es scheint da noch andere Mechanismen zu geben, die Ärger machen. Ich habe erst diesen Nachmittag aufgegeben, eine Anwendung mit 83% Auslastung, stabil und über 'zig Tage erprobt. Sobald ich weitere Funktionen hinzufüge, klemmt das Gebilde. Nehme ich einige serial.print raus, läuft es wieder - also eindeutig ein Problem des freien Flash. Andere Anwendungen funktionieren bei deutlich höherer Auslastung, eine mit 99% Flash! EAF schrieb: > Joachim B. schrieb: >> stimmt, ich finde ISP Programmierung lästig, immer das 6-polige Kabel >> suchen den Prommer. > Ist das eine Nebelkerze, oder nur ein arg schräges Argument? Wo Joachim recht hat, hat er recht. Ich baue keine Steckbrett-Lose-Selbstzweck-Dinge, sondern benutzbare Geräte, also Gehäuse drum und Deckel zu. Es macht wenig Aufwand, den USB von außen zugänglich zu machen, dass man später noch eine Korrektur einspielen kann.
Angehängte Dateien:
-
USB_Kappe.jpg
(13 KB)
Gast
#7260951
Peter schrieb: > Gibt es in der Arduino IDE Compileroptionen, die helfen, den Code noch > etwas zu komprimieren? Es gibt die Option eine .lst-Datei anzulegen. Da sieht man dann recht gut welche Bibliotheken wieviel Flash-Speicher wofür benötigen ... LG, Sebastian
Manfred schrieb: > Es scheint da noch andere Mechanismen zu geben, die Ärger machen. Ich > habe erst diesen Nachmittag aufgegeben, eine Anwendung mit 83% > Auslastung, stabil und über 'zig Tage erprobt. Sobald ich weitere > Funktionen hinzufüge, klemmt das Gebilde. Nehme ich einige serial.print > raus, läuft es wieder - also eindeutig ein Problem des freien Flash. Ganz sicher nicht. Denn der Flash ist ROM, read only memory. Da kannst du lesen was und wie du willst, es wird IMMER funktionieren! Ganz anders mit RAM, denn dort ist der echte Verbrauch zur Laufzeit dynamisch. Die Anzeige in der Arduino-IDE zeigt nur den statischen Verbrauch an. Der dynamische Teil ist unbekannt und man probiert es praktisch auf gut Glück. Meistens reicht es, manchmal nicht.
Falk B. schrieb: > Ganz anders mit RAM, denn dort ist der echte Verbrauch zur Laufzeit > dynamisch. +1 ich liebe den Luxus im Ram vom ATmega1284p oder ESP32
Gast
#7261039
Manfred schrieb: > EAF schrieb: >> Martin schrieb: >>> Bei Arduino Nanos verhilft der Optiboot Bootloader zu etwas mehr >>> Programmspeicher. >> Leider nicht! > > Verstehendes Lesen ist nicht Dein Ding? > >> Nur, wenn man den UNO Bootloader auf den Nano spielt. > > Genau das wird Martin gemeint haben, den Bootloader austauschen. > Gerüchteweise soll es auch Nanos geben, wo ab Werk der Optiboot drauf > ist. Verstehendes Lesen ist wohl nicht so dein Ding. Und kundig machen auch wohl nicht. Der Bootloader ist beim "modernen" Nano der gleiche, wie beim UNO, aber nicht die Fuses Einstellungen. Man fällt also auf die Fresse, wenn man die frei gewordenen 1,5kB nuten will, weil der Bootloader Einsprungspunkt dann ins Ende von der Anwendung zeigt. Doofe Konstruktion, aber ist so. Erst wenn man den UNO Bootloader brennt, werden die Fuses auch so gesetzt, dass man den Speicher nutzen kann. -------------- Manfred schrieb: > EAF schrieb: >> Joachim B. schrieb: >>> stimmt, ich finde ISP Programmierung lästig, immer das 6-polige Kabel >>> suchen den Prommer. >> Ist das eine Nebelkerze, oder nur ein arg schräges Argument? > Wo Joachim recht hat, hat er recht. Ich baue keine > Steckbrett-Lose-Selbstzweck-Dinge, sondern benutzbare Geräte, also > Gehäuse drum und Deckel zu. Es macht wenig Aufwand, den USB von außen > zugänglich zu machen, dass man später noch eine Korrektur einspielen > kann. Hat das was mit der EESAVE Fuse zu tun? Nein! Also hat Ihm nicht recht. Bedenke über den "kleinen" Bootloader kann man das EEPROM nicht beschreiben. Zusätzlich: Beim UNO ist die EEFUSE gesetzt, das EEPROM wird nicht automatisch mit gelöscht. Beim Mega ist die Fuse im Auslieferungszustand. Das EEPROM wird beim Erase mit gelöscht.
Gast
#7261041
Manfred schrieb: > Es scheint da noch andere Mechanismen zu geben, die Ärger machen. Ich > habe erst diesen Nachmittag aufgegeben, eine Anwendung mit 83% > Auslastung, stabil und über 'zig Tage erprobt. Sobald ich weitere > Funktionen hinzufüge, klemmt das Gebilde. Nehme ich einige serial.print > raus, läuft es wieder - also eindeutig ein Problem des freien Flash. Symptom mag stimmig sein, aber deine Diagnose ist Müll, bzw. ein Irrtum.
Gast
#7261043
> man probiert es praktisch auf gut Glück.
Wir hätten beim 6510 bleiben sollen.
Bei 256 Byte Stack konnten wir noch berechnen, ob es im ungünstigsten
Fall ausreicht. Und alle anderen Variablen hatten einen festen
Speicherplatz.
Beitrag #7261140 wurde von einem Moderator gelöscht.
Manfred schrieb: > Nehme ich einige serial.print > raus, läuft es wieder - also eindeutig ein Problem des freien Flash. Eindeutig nicht. Deine serial.print vernichten CPU-Zeit wie blöde, wenn der FIFO voll ist. D.h. Dein CPU dreht Däumchen, während die Bytes raus tröpfeln. Ist ein gern gemachter Anfängerfehler, überall Debugausgaben rein und sich wundern, warum es an allen Ecken klemmt. Ganz böses Foul sind dann noch serial.print in Interrupts, das ergibt einen Deadlock, sobald der FIFO nicht mehr genug Platz hat.
Gast
#7261157
Fn schrieb im Beitrag #7261140: > EAF schrieb: >> Symptom mag stimmig sein, aber deine Diagnose ist Müll, bzw. ein Irrtum. > > Er hat ein ram-grössen problem. Richtig? Keine Ahnung! Wir haben hier eine Ursachenbehauptung(Flash Mangel), ohne Reproduzierbarkeit(Code geheim). Sogar die Hardware ist Geheim. Wie schon gesagt, ich glaube ihm, dass ihm da ein Problem hat, aber darüber nachzudenken, welches das sein könnte? Eigentlich nicht! Einen möglichen Grund habe ich schon genannt: Nano mit dem moderne Bootloader aber der falschen Fuseeseinstellung, dann startet es nicht mehr, wenn der Code die unteren 1,5K des Bootloaderbereiches nutzt. Das kann nur passieren, wenn man ohne Wissen in der platform.txt rumpfuscht, oder den Nano als UNO anspricht, ohne die Fuses zu ändern.
Gast
#7261221
Wie man den freien RAM kontrolliert, ist dort ganz gut beschrieben: https://learn.adafruit.com/memories-of-an-arduino/measuring-free-memory
Gast
#7261247
Kleiner Hinweis. Wenn der Compiler Variablen-Warnung ausgibt, dann passe höllisch auf. Ich habe gemerkt das das Programm eigentlich sauber läuft, aber die Variablen am spinnen sind. k.a. wie die das Handhaben. Mir wäre ein Absturz lieber gewesen. So habe ich 2 Wochen gesucht. Dann mal aus irgend einer Idee in der Badewanne ein Mega gekauft und das selbe Programm ohne Änderung drauf geknallt und keine Variable spinnt.
Schlaumaier schrieb: > Wenn der Compiler Variablen-Warnung ausgibt, dann passe höllisch auf. Worauf soll er da aufpassen. Er muß die Warnung lesen, verstehen und den Code entsprechend korrigieren. Warnungen bestehen nämlich aus lesbarem Text und der Zeilennummer, die angewarnt wird. In seltenen Fällen kann trotz Warnung der Code arbeiten, wie gewünscht. Dann kann man mit einem Cast die Warnung unterdrücken.
Gast
#7261261
Schlaumaier schrieb: > k.a. wie die das Handhaben. Mir wäre ein Absturz lieber gewesen. Die kleinen µC haben keine Hardware um Kollisionen zu verhindern, bzw. frühzeitig zu erkennen und damit auch behandeln zu können. Salopp gesagt: Eine fehlende MMU spuckt dir auf deine Wunschliste.
Steve van de Grens schrieb: > Wie man den freien RAM kontrolliert, ist dort ganz gut beschrieben: Ich fülle den freien Bereich mit 0x77. Eine Testfunktion prüft zyklisch, wieviel 0x77 Bytes noch übrig sind. Bei <16 Byte schlägt sie Alarm.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.