ATMega Flash wird langsam knapp. Upgrade o. Plattformwechsel?

Ist denn der Stromverbrauch oder besondere Echtzeitfähigkeit ein 
wichtiges Kriterium? Falls nicht, hätte ich da schon einen Raspi Zero W 
genommen ;)

Da müsste man den Code sehen.. wenn das so schnell voll ist für so eine 
einfache Aufgabe muss da wohl die Arduino IDE am Werk sein?

Bei Arduino und anderen normalen Librarys kann man eine Menge 
optimieren/abspecken..

EDIT: das meisste müsste der ENC28J60 ausmachen.. da sollte man 
heutzutage lieber den W5100 oder nen ESP8266 nehmen. ( beim ENC baust Du 
die kommunikation im Atmega zusammen, beim w5100 macht das der w5100 
schon selbst)

Welche IDE wird denn benutzt?

Mein Vorschlag:

https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware

Das erschlägt sehr viel von dem, was Du selber mühselig programmieren 
musstest:
- TFT Display, wahlweise mit Touch direkt anschließbar, z.B. das hier
https://www.olimex.com/Products/OLinuXino/LCD/LCD-OLinuXino-7/open-source-hardware

- SD-Karte wird direkt vom Linux unterstützt
- Gigabit Ethernet ist direkt da.
- EEPROM brauchst Du wahrscheinlich nicht mehr, ist aber leicht 
anschließbar
- RTC ist bereits drin
- Encoder sollte kein Problem sein, aber den könntest Du eventuell mit 
Toucheingabe besser in Software implementieren
- Akustischer Signalgeber: Audio 3.5" Stereo-Klinke vorhanden, Beeper 
kann einfach über GPIO angeschlossen werden
- SMTP: installier einfach einen postfix auf dem Linux, und gut ist.
- USV: LiPo-Akku anschließbar.

Du wirst das meiste sofort da haben, ohne groß basteln zu müssen.

fchk

PS: Einen Pi würde ich nicht nehmen, da verlierst Du einfach zu viele 
IOs, wenn Du ein RGB-TFT anschließen willst. Die Peripherie ist beim PI 
viel schlechter als bei Alternativprodukten.

Ver Wunderter schrieb:
> Frank K. schrieb:
>> Mein Vorschlag:
>
> Booaaahhhh, einen Quad Core für die Aquariumsteuerung.
>
> Das ist wirklich die optimale Lösung!

Ja und? Für die AVR-Lösung wird der Fragesteller sicher insgesamt mehr 
bezahlt haben als die 36 Oiro, die Olimex für das Board aufruft.

fchk

Wie wäre denn ein XMega384? Neben mehr Flash gibt dazu bis zu 60MHz 
(inoffiziell 64MHz) und zusätzliche Ports, SPIs, I2Cs, UARTs, .....

Hallo,

micha schrieb:
> Wenn du eh eine SD-Karte planst eventuell Texte auslagern?

SD Karte ist schon drin, habe ich auch schon gedacht jedoch kann man die 
SD Karte aus dem System entfernen um zb. den Fehlermeldungen am PC 
auslesen zu können. Die Grundfunktionen sollen erhalten bleiben. Daher 
fiel diese Auswahl weg.

Philipp K. schrieb:
> Arduino IDE am Werk sein?

Nein, programmiere das Ding in Atmel Studio 7 in C.

Philipp K. schrieb:
> Bei Arduino und anderen normalen Librarys kann man eine Menge
> optimieren/abspecken..

ENC28J60 -> Eine Library von Tuxgraphics welche vom Inhalt her größten 
Teils auf der Arduino EtherShield und EtherCard Lib basiert.

ILI9341 -> Hat Ähnlichkeit mit der Adafruit Lib

SD Karte -> FatFs von ELM ChaN

Rotary Encoder -> kommt aus diesen Forum.

Andere Sachen wie Kommunikation wie I2C, SPI, USART, EEPROM sind selbst 
geschrieben

Philipp K. schrieb:
> das meisste müsste der ENC28J60 ausmachen

Ja ein großen Anteil macht der ENC aus mit der SD Karte zusammen. Der 
ENC28J60 ist halt im rohen zustand Dumm wie Brot. TCP/IP HTTP ist halt 
in Software gelöst.

Philipp K. schrieb:
> lieber den W5100 oder nen ESP8266 nehmen.

Muss mal schauen ob es den W5100 in einzel Ausführung gibt ohne Arduino 
Shield.

Frank K. schrieb:
> Das erschlägt sehr viel von dem, was Du selber mühselig programmieren
> musstest:

Ich hatte am Anfang ein PI in der Hand gehabt, habe mich letzte endlich 
aber für den AVR entschieden da dich das ganze gerne selber "klassisch" 
programmieren wollte.

Lg

W5100Usa schrieb:
> Gibt es. Ganz handlich ...
>
> Ebay-Artikel Nr. 223614689695

Ah okay du warst schneller als ich :) Danke

Werde ich mal bestellen und ausprobieren.

Crazy H. schrieb:
> Wie wäre denn ein XMega384?

Hmm, hörst sich ja auf im ersten Moment nicht schlecht an, weißt du ob 
es möglich ist mit bestehen ATMega Kenntnissen den XMega programmieren 
zu können. Oder ist der von der Struktur komplett anderes?

Mfg

W5100Usa schrieb:
> Wenn du erst mal die Last des Ethernet- und TCP-Handling vom
> ENC weg hast wirst du schon mal eine ganze Menge Speicher
> gewonnen haben.

Ich habe kurz die Netzwerk Initialisierung und Anfragen auskommentiert.

Mit ENC verwende ich Aktuell:
Program Memory Usage   :  99750 bytes   76,1 % Full
Data Memory Usage   :  7001 bytes   42,7 % Full

Und ohne:
Program Memory Usage   :  85646 bytes   65,3 % Full
Data Memory Usage   :  5746 bytes   35,1 % Full

W5100Usa schrieb:
> Und falls du bis jetzt Arduino-Klassen verwendet hast und
> auf "normale" Programmierung umsteigst noch mal eine ganze
> Menge.

Ich nutze kein Arduino IDE, Ich habe mit Header und C Dateien.

W5100Usa schrieb:
> ATXmegas sind meines Wissens nach nicht vom Arduino
> Environment unterstützt.

Muss es ja auch nicht. Ich kann den ATXMega in Atmel Studio ja als 
Prozessor auswählen.

Lg

Felix N. schrieb:
> Ein großer Teil des Flash Speicher geht
> für die Text drauf die ich auf dem ILI9341 TFT Display darstelle.

Dann machst Du irgendwas grundlegend falsch.
Mußt Du wirklich ganze Romane an Text anzeigen?
Was belegen denn die vielen Zeichensätze allein?
In der Regel reicht ein Font in 3 Größen völlig aus.

Wenn Du ein intelligentes Display verwendest hast Du plötzlich eine 
Menge Speicher über, Touch läuft dann nebenbei und Anzeige und Bedienung 
werden viel flüssiger, weil die Bildrate sehr viel höher sein kann bei 
einem
Bruchteil an zu übertragenden Daten.

Sowas wie das hier:
https://www.matrixorbital.com/ftdi-eve/eve-bt815-bt816/eve3-43g

Das hat Zeichensätze eingebaut und einen FLASH Chip den man mit u.a. 
Bildern, UTF-8 Zeichensätzen und Texten füllen kann.

Die Kapazitiv-Touch Version habe ich ausgewählt, weil Resistiv-Touch im 
Vergleich einfach nur eklig ist.
Resistiv-Touch werde ich mir hoffentlich nie wieder antun müssen.

Die haben eine SPI Schnittstelle die mit 3,3V Pegeln läuft und benötigen 
ein 3,3V Netzteil, je größer das Display, desto mehr Strom.
Das sind so ~200mA bei 3,5", ~300mA bei 4,3", ~500mA bei 5" und ~750mA 
bei 7".

Ja, die Größen habe ich alle schon mit AVR benutzt, bei 40+ Bildern pro 
Sekunde hat der Controller auch noch nicht wirklich was zu tun.
Aber sowas wie eine Animation für z.B. eine Pumpe läuft schön flüssig, 
so mit Drehung des Bildes durch den Grafik-Chip.

BerAVRter schrieb:
> Sehr gut. Nun machst die selbe Datenerhebung für jeden anderen
> Teilbereich deines Aquariumprogramms auch und führst Buch.

Man könnte aber auch die Größe der einzelnen Programmteile im MAP-File 
ablesen.

Felix N. schrieb:

> Frank K. schrieb:
>> Das erschlägt sehr viel von dem, was Du selber mühselig programmieren
>> musstest:
>
> Ich hatte am Anfang ein PI in der Hand gehabt, habe mich letzte endlich
> aber für den AVR entschieden da dich das ganze gerne selber "klassisch"
> programmieren wollte.

Was heißt für Dich "klassisch"? Unter Unix haben schon Generationen vor 
Dir in C und C++ entwickelt. Und solche Sachen wie TCP/IP, USB, 
Filesysteme usw. muss man heute nicht mehr selber entwickeln, das kann 
man ruhig einem Betriebssystem überlassen. Das ist jedenfalls der Weg, 
über den Du mit minimaler Arbeit das Maximum an Möglichkeiten bekommst.

Alternativ:
http://www.ti.com/tool/EK-TM4C1294XL

Da bekommst Du auch eine ganze Menge an Rechenleistung und Speicher, 
dazu 10/100 MBit Ethernet MAC+PHY im Chip, USB und was man sonst noch 
alles so braucht. Und dazu gibts ein schönes RTOS und eine umfangreiche 
Treiberbibliothek.

fchk

Es gibt auch neuere AVRs mit deutlich mehr Speicher. Sie lösen das 
Problem der Optimierung nur bedingt ;).

Im wirklichen Leben wäre das der Gau, da man sich im Vorfeld keine 
Gedanken über die richtige Plattform für sein Projekt gemacht hat.

Der ESP32 wäre die Lösung allerdings muss dein Code auch für ein OS 
geeignet sein. Das heißt sich mit Threads und einem völlig anderen 
Framework beschäftigen zu müssen.

Wie viel Aufwand es ist den Code auf einer anderen Plattform zum laufen 
zu bringen hängt von deinem Programmierstil ab.

Durch geschickte Programmoptimierungen kann man immer ein paar Bytes 
heraus schinden (z. B fixed point statt floating point nutzen)

Kann man die Texte oder Fonts komprimiert abspeichern? (z. B. nur 7 bit 
statt 8 verwenden, würde schon 12,5% sparen)

Hast du denn schon heraus gefunden, was den meisten Speicher braucht?

Gruß Roland

W5100Usa schrieb:
> Ob du damt alles wegbekommst?

Nein ich habe die #includes ja nicht auskommentiert. Es sollte ja auch 
nur verdeutlichen das der ENC28J60 circa. 20Kbyte an Speicher frisst.

W5100Usa schrieb:
> die W5100 Einbindung kostet
> natürlich trotzdem was an Programm-Speicher und RAM ....

logisch.

Peter D. schrieb:
> Mußt Du wirklich ganze Romane an Text anzeigen?

Sorry, habe mich vertan ich die Texte liegen im RAM und nicht im Flash. 
Ich habe im Moment ja nur die Grundlegende Menüs fertig(Hauptmenü, 
Uhrzeit, Co2, pH Elektrode, SD Karte, Netzwerk und Lichtsteuerung) die 
Texte die da drin sind brauche ich so wie sie sind.

BerAVRter schrieb:
> Dann steckst Du Hirnschmalz erstmal in die 3 Speicherintensivsten
> Bereiche, mit Fokus auf Verkleinerung.

Ich weiß zb. das die ENC Lib auch UDP und NTP vorhanden sind und auch 
benutzt werde diese Funktionen mal entfernen da ich diese nicht verwende 
und auch nicht vor habe zu verwenden.

Rudolph R. schrieb:
> intelligentes Display

Hört sich auf jeden Fall interessant an, gut die FPS bei dem ILI9341 mit 
8 MHz Clock Speed sind jetzt nicht sonderlich hoch aber ich hatte bis 
jetzt noch nicht vor Grafiken zu verwenden. Aber werde ich auf jeden 
Fall im Hinterkopf behalten.

m.n. schrieb:
> Ich vermute eher, ungeschickte Programmierung uneinheitlicher Menüs
> benötigt zu viel Speicher.

Ich habe jetzt mal mein letztes Menü angehängt in diesem wird die 
Lichtsteuerung gehandelt.

m.n. schrieb:
> Um nicht den µC komplett zu wechseln, würde ich Funktionen in einen 2.
> AVR auslagern und über IIC ankoppeln. Der Hauptprozessor erledigt dabei
> die Bedienung.

Also würde ein Prozessor als Externer Speicher arbeiten? Würde SPI nicht 
besser sein weil dort höhere Geschwindigkeiten erreicht werden als max. 
400KHz bei I2C?

Erfahrener Entwickler schrieb:
> Die Wahrscheinlichkeit
> dass Du zwingend TLS brauchst

Ja deswegen steht da auch hinter (nicht sicher) ...

Roland P. schrieb:
> Hast du denn schon heraus gefunden, was den meisten Speicher braucht?

Ja der ENC und die SD Karte. Der ENC ca. 20Kb die SD ca. 15kb. Und der 
Rest geht wahrscheinlich auf die sprintf's drauf, habe gehört die sollen 
auch nicht so speicher Schonend sein.

Mfg

Felix N. schrieb:
> Von den 128K gehen noch 4K für den Bootloader runter.

Optiboot 512 Byte
https://github.com/Optiboot/optiboot

woher kommen deine 4K?

Theor schrieb:
> Das sowas sich so (aus-)wächst ist bei einem Anfänger der dann noch
> dieses oder jenes Feature haben will normal (und auch nichts Schlimmes),
> Aber, das macht die Entwicklung auf die Dauer immer schwieriger und
> schwieriger.

Hallo,

Gut das ich ein guter Programmier bin habe ich nie gesagt, ich habe mir 
mein gesamtes Programmier wissen aus YouTube Videos, Code Schnippels, 
teilweise Bücher und Foren zusammen gesammelt. Habe Beruflich nix damit 
zutun. Nur Hobby.

Das was funktioniert hat habe ich am Anfang erst mal auch nicht mehr 
verändert. Warum? Es hat ja funktioniert da habe ich mir kein Kopf 
gemacht ob dieses nun maximal Optimiert ist oder nicht. Gut das mag 
vielleicht nach einer schlechten Einstellung klingen. So soll es aber 
nicht rüber kommen.

Ich bin jeder Zeit bereit aus meinen Fehlern zu lernen und diese zu dann 
zu verhindern/verbessern. Schließlich siehst Du den Code ja ganz anderen 
Augen als Ich, mag vielleicht an deiner Erfahrung liegen.

Stefanus F. schrieb:
> Warum? Schau Dir mal in der Doku der AVR C Library die Beschreibung der
> PSTR und PROGMEM Makros an. Ich habe dafür zwar ein -1 bekommen, aber
> ich bin zuversichtlich, dass du damit eine große Menge RAM frei bekommen
> wirst. Statt sprintf nutzt du dann sprintf_P.

Hi,

Wenn ich mich nicht irre werden Texts die man direkt übergibt im RAM 
ausgelagert. Ich kenne die PSTR und PROGMEM Makros. Ich weiß auch das 
Sie Texte in den Flash auslagern und so Platz im RAM Schaffen. Nur ich 
habe 16K RAM und belege 7K zurzeit. Wenn die die ganzen Texte in den 
Flash Schiebe wird mein Programmspeicher doch noch weniger. Und gerade 
der Flash Speicher ist ja mein Problem. Oder habe ich jetzt da was 
falsch verstanden?

MaWin schrieb im Beitrag #5966040:
> Poste mal bitte deinen Sourcecode

Hi, ich habe jetzt mal eine rar Datei angehängt wo mein ganzer Source 
Code drin ist.

Mfg

Und Du benutzt float. Das ist meistens vermeidbar.

Wenn ich Bruchteile von Volt messen will, dann nehme ich einfach die 
passende Einheit. Nicht Volt, sondern mV oder uV. Zack, schon kann ich 
mit Ganzzahlen rechnen. Floats brauchst DU nur, wenn Du einen hohen 
Dynamikbereich brauchst, d.h. gleichzeitig sehr kleine und sehr große 
Zahlen und dazwischen 10 oder mehr Zehnerpotenzen.

Ohne float wird auch stdio sehr viel kleiner.

Das ist mir nach 30s aufgefallen.

Auf dem vomn mir vorgeschlagenen Olimex-Board wäre das völlig egal. Da 
brauchst Du Dich auch nicht um Menüs oder Strings im ROM zu kümmern. Als 
Programmierumgebung nimmst Du Qt, das nimmt Dir alles ab.

In der richtigen Welt würde niemand mehr den von Dir gewählten Weg 
nehmen. Zu viele Einschränkungen, zu aufwändig zu programmieren, zu 
aufwändig zu warten. Schlicht zu teuer in der Entwicklung.

fchk

Felix N. schrieb:

> Wenn ich mich nicht irre werden Texts die man direkt übergibt im RAM
> ausgelagert. Ich kenne die PSTR und PROGMEM Makros. Ich weiß auch das
> Sie Texte in den Flash auslagern und so Platz im RAM Schaffen. Nur ich
> habe 16K RAM und belege 7K zurzeit. Wenn die die ganzen Texte in den
> Flash Schiebe wird mein Programmspeicher doch noch weniger. Und gerade
> der Flash Speicher ist ja mein Problem. Oder habe ich jetzt da was
> falsch verstanden?

Die Texte sind doch sowieso im Flash. Müssen sie auch. Von wo anders als 
auch dem Flash sollen sie denn nach dem Einschalten herkommen? Klar, aus 
einem .data-Segment, das von der Compiler-Runtime noch vor main() ins 
RAM kopiert wird. Und DAS ist vermeidbar.

Ja, nun hast DU auch eine Architektur (AVR) gewählt, wo Programm- und 
Daten in getrennten Adressräumen liegen. Bei anderen Architekturen wie 
ARM oder MIPS (PIC32) oder x86 ist das nicht so. Bei AVR, 8051 und 8-Bit 
PIC muss halt der Programmierer entsprechend Grips in der Birne haben.

fchk

Frank K. schrieb:
> Nicht Volt, sondern mV oder uV

ich nehme cV centi Volt oder dV dezi Volt als Ganzzahl und füge das 
Komma per Stringmanipulation ein.

mal als Beispiel..
im code sind 34 mal "ili9341_drawRect(277, 17, 36, 32,BLABLA); und auch 
andere doppelt und dreifach..


dann lieber komprimieren mit:

void RechteckBLA(uint32_t color){
ili9341_drawRect(277, 17, 36, 32,color)
}

an der richtigen stelle dann ersetzen rechteckBLA(ORANGE);

Manfred schrieb:
> wie toll Ethernet vom
> ESP unterstützt würde, nachvollziehen kann ich das nicht.

mindestens jede ENC oder W5100 Arduino library kann das.. 
praktischerweise ist das bestimmt Via WLAN gemeint.

Frank K. schrieb:
> Und Du benutzt float. Das ist meistens vermeidbar.

Diese Angst ist unbegründet, die float Lib kostet nur einmal Flash (~1kB 
ohne printf, scanf).
Bei einem AVR mit 4kB Flash würde ich überlegen, aber nicht bei 128kB.

Felix N. schrieb:

> SD Karte ist schon drin, habe ich auch schon gedacht jedoch kann man die
> SD Karte aus dem System entfernen um zb. den Fehlermeldungen am PC
> auslesen zu können. Die Grundfunktionen sollen erhalten bleiben. Daher
> fiel diese Auswahl weg.

Dann schliess parallel am SPI noch einen kleinen SPI-Flash-Baustein an. 
Kein Grund für reine Daten einen uC mit größerem Flash zu nehmen. Gibts 
für wenig Geld bis in MByte-Größen und kannst du einfach im Programm von 
der SD-Karte aus befüllen.

PSTR wird doch schon benutzt.

Theor schrieb:

> Zusätzlich: Ich habe das vorher nicht erwähnt.
>
> 3. Vermeide die Verwendung von Literalen, insbesondere von
> Zahlenliteralen im Code. Halte sie lieber an einer zentralen Stelle,
> falls möglich.

Das ist Quatsch bzw. stimmt nur für C-Strings (bei AVR). Zahlliterale 
(als core-constant) werden vom Compiler immer direkt in den generierten 
Code eingebaut.

Wenn Du doch sowieso schon ein externes Eeprom hast: Warum nicht dort 
die Strings ablegen?

m.n. schrieb:
> Andreas B. schrieb:
>> Wenn Du doch sowieso schon ein externes Eeprom hast: Warum nicht dort
>> die Strings ablegen?
>
> Die paar Texte sind doch überhaupt nicht das Problem, zumal der Compiler
> gleiche Texte in der Regel erkennt und nur einmal anlegt.

Ich sehe eine ganze Menge Strings. 10% Einsparung würde ich schätzen.

>
> Die wiederholten, nahezu gleichen Abläufe fressen Platz. Geschickter ist
> es, mit Strukturen für die Bedienfelder zu arbeiten. Das ist einmaliger
> Aufwand aber danach sehr effizient und transparent.

Das ist allerdings wahr. Das ganze Bediengedöns sieht recht ineffektiv 
aus.

Felix N. schrieb:
> Ich weiß auch das
> Sie Texte in den Flash auslagern und so Platz im RAM Schaffen.

Nein, sie werden nicht ins Flash ausgelagert. Da stehen sie sowieso. Sie 
werden mit Progmen/PSTR nur nicht ins RAM geschoben beim Start des uCs.

Ich hab mir den Thread jetzt nicht genau durchgelesen, nur überflogen. 
Aber generell würde ich mir über Optimierungen mal Gedanken machen wenn 
ich sehe, dass 128 kB Flash nicht reichen.

Felix N. schrieb:
> Hallo,
>
> Gut das ich ein guter Programmier bin habe ich nie gesagt, ich habe mir
> mein gesamtes Programmier wissen aus YouTube Videos, Code Schnippels,
> teilweise Bücher und Foren zusammen gesammelt. Habe Beruflich nix damit
> zutun. Nur Hobby.

Naja, da haben wir schon deutlich schlimmere Dinge gesehen ;-)

1

void getTempCompensation(void) {

2

  if(temperature >= 20 && temperature <= 21) {

3

    reAmpDiff = TEMP_20 * 3;

4

  }

Diese Funktion ist maximal albern, wenn gleich sie sicher nicht 
wahnsinnig viel Flash braucht.

1

void getpHValue(uint8_t withTemperatureMeasuring) {

2

...

3

voltageOnPin = (avgVolt[0] + avgVolt[1] + avgVolt[2] + avgVolt[3] + avgVolt[4] + avgVolt[5] + avgVolt[6] + avgVolt[7] + avgVolt[8] + avgVolt[9] + avgVolt[10] + avgVolt[11] + avgVolt[12] + avgVolt[13] + avgVolt[14] + avgVolt[15] + avgVolt[16] + avgVolt[17] + avgVolt[18] + avgVolt[19]) / 20;

Schon mal was von einer Schleife gehört?

1

void init_EEPROM(void) {

Au weia! Sieht du in den Massen an Schreibzugriffen selber noch durch? 
Schon mal was von einem struct gehört?

1

char * stringReplace(char *search, char *replace, char *string) {

2

  // Speicher reservieren

3

  tempString = (char*) malloc(strlen(string) * sizeof(char));

Naja, theoretisch korrekt, praktisch eher ungünstig. Du hast so oder so 
nur wenig Speicher, da reicht es, eine lokale, temporäre Variable 
(Array) anzulegen. Mit ein wenig Nachdenken kommt diese Funktion sogar 
ohne Zwischenspeicher aus, wenn man einfach die Lücke im Originalstring 
vor dem Austausch passend zurecht schiebt.

1

void ili9341_init(void)//set up display using predefined command sequence

Auch hier wieder sinnlose, endlose Funktionsaufrufe, die nur einen 
anderen Parameter haben! Sowas macht man mit einem Array, idealerweise 
liegt der im Flash (PROGMEM) und einer Schleife. Das ergibt nicht nur 
deutlich weniger Quelltext, der deutlich übersichtlicher ist, sondern 
auch deutlich weniger Flashverbrauch.

1

sprintf(buffer, "pH: %-.2f", phValue);

Du hast viele sprintf() Funtkionen drin. Nimm sprintf_P, dann liegt der 
Formatstring direkt im FLASH und verbraucht keinen RAM!

Denk dran, konstante Strings und Array, welche "normal" benutzt werden, 
verbrauchen beim AVR Flash UND RAM in gleicher Größe. Erst wenn man sie 
mittels der passenden Funktionen in den Flash schiebt und entsprechend 
anspricht, entfällt der RAM-Verbrauch.

1

  ili9341_combo(5, 105, WHITE, BLACK, 2, 3, 0, 0, "Karbonathaerte:");

Auch hier das Gleiche. Du musst deine Funktion auf PROGMEM-Strings 
umbauen. Dann sparst du massiv RAM.

1

void getTimeBasedInformation(void) {

2

  ontime_co2_hour  = readEEPROM(0x0F);

3

  ontime_co2_min   = readEEPROM(0x10);

4

  offtime_co2_hour = readEEPROM(0x11);

5

  offtime_co2_min  = readEEPROM(0x12);

Gleiches Problem wie oben. Du spricht direkte, absolute Adressen im 
EERPOM an. Das ist Low Level Programmierung, wie man sie nicht mal in 
Assembler machen will. Man will Variablen mit gescheitem Namen 
ansprechen! Denn sonst sieht man irgendwann nicht mehr durch.

1

uint8_t compare_float(float f1, float f2){

2

  float precision = 0.00001;

Hier hast du schon eines der Probleme bei Fließkommazahlen erkannt. Ein 
direkter Vergleich auf Gleichheit geht meist schief. Vermutlich ist für 
deine Anwendung Festkommaarithmetik ausreichend und macht dir nicht 
solche Probleme.

1

 strcpy(smallBuffer, "Manuell")

Auch hier bringt die Funktion strcpy_P RAM-Ersparnis.

Allgemein sieht man in deinem Ansatz zum Menuaufbau tonnenweise 
Funktionsaufrufe zum Zeichnen. Vermutlich ist da sehr viel doppelt und 
dreifach drin, das kostet schon einiges an Flash. Das kann man mit einem 
besseren Ansatz lösen. Man muss ja nicht gleich eine GUI-Menu-Bibliothek 
programmieren. Aber man sollte mit deutlich mehr Datenstrukturen 
arbeiten, welche die einzelnen Menus beschreiben. Ein kleine, kompakte 
Funktion kann diese dann auswerten und ja nach Menu zeichnen. Außerdem 
sollte man mehr mit universellen Hilffunktionen arbeiten, damit 
wiederholende Aufgaben nicht mehrfach aufgedröselt hingeschrieben werden 
müssen. Das spart FLASH, Tipparbeit und minimiert Fehlerquellen.

Strukturierte Programmierung auf Mikrocontrollern

1

  switch(dayOfTheWeek()) {

2

    case 1:

3

      strcpy(buffer, "Mo.");

4

      break;

5

    case 2:

Ist auch maximaler Unsinn. Das macht man mit einem PROGMEM-Array!
Etwa so

1

const char DoW[][4] = PROGMEM {"Mo.", "Di.", "Mi.", "Do.", "Fr.", "Sa.", "So.", };

2

strcpy_P(buffer, DoW[dayOfTheWeek()]);

Falk B. schrieb:
> Ist auch maximaler Unsinn. Das macht man mit einem PROGMEM-Array!

Das zum einem, es zeigt aber noch etwas weiteres: So eine Woche hat ja 
nur 7 Tage: Ein Case hätte man sich auch hier sparen können.
Auch ein ENUM hätte hier wahrscheinlich besser gepasst als das 
Switch-Statement.

Aber es wurde ja schon festgestellt, dass in dem Code enorm viel 
Optimierungspotential steckt.

Noch was

1

void encode_init(void){

2

  int8_t new;

3

4

  CODER_DDR |= (0<<CODER_PINA) | (0<<CODER_PINB) | (0<<CODER_BUTTON);

Das ist Unsinn und macht im Extremfall nicht das, was du willst. Eine 0 
durch die Gegend schieben ist sinnlos. Das funktioniert hier nur, weil 
die Bits im Register nach dem Reset sowieso schon auf Null stehen. Wenn 
man sicherstellen will, daß diese Pins Eingänge werden, dann eher so, 
siehe Bitmanipulation.

1

void encode_init(void){

2

  int8_t new;

3

4

  CODER_DDR &= ~((1<<CODER_PINA) | (1<<CODER_PINB) | (1<<CODER_BUTTON));

MaWin schrieb:
>> Autor: MaWin (Gast)
>> Datum: 08.09.2019 20:47
>
> Noch so ein Trollbeitrag vom Psychopathen...

Und du Plinse schaffst es seit Jahren nicht, dir einen Login zuzulegen. 
Selber Schuld! Aber was wäre die Welt ohne Paranoia?

Noch was

1

ISR(TIMER1_COMPA_vect){            // 1ms for manual movement

2

  int8_t new, diff;

3

4

  static uint8_t cnt_10ms;

5

  cnt_10ms++;

6

  if (cnt_10ms==10 && useSD) { //needed for sd card

7

    cnt_10ms=0;

8

    disk_timerproc();

9

  }

10

11

  new = 0;

12

  if( PHASE_A ) new = 3;

13

  if( PHASE_B ) new ^= 1;          // convert gray to binary

14

  diff = last - new;               // difference last - new

15

  if( diff & 1 ) {                 // bit 0 = value (1)

16

    last = new;                    // store new as next last

17

    enc_delta += (diff & 2) - 1;   // bit 1 = direction (+/-)

18

  }

19

20

  encoder_position += encode_read4();

21

}

Genau SO macht man das eben nicht! Der Witz der Funktion encode_read4() 
ist es ja, daß man sie relativ langsam und selten in einer Schleife im 
Hauptprogramm aufrufen kann und als Ergebnis die Anzahl der Schritte 
seit dem letzten Aufruf nach links oder rechts bekommt. Ein Aufruf in 
der ISR ist sinnlos und kontraproduktiv! Die Beispiele hier im Wiki 
machen das auch nicht!

Stefanus F. schrieb:
> Falk B. schrieb:
>> CODER_DDR |= (0<<CODER_PINA) | (0<<CODER_PINB) | (0<<CODER_BUTTON);
>> Eine 0 durch die Gegend schieben ist sinnlos.
>
> Kostet allerdings auch keinen Speicherplatz. Der Compiler reduziert das
> auf eine simple Zuweisung: CODER_DDR |=0

Wenn der Compiler schlau ist, macht er dabei gar nichts (was ich mal 
stark vermute). Mit 0 verodern gibt immer noch das gleiche wie vorher.

Stefanus F. schrieb:
> Alle Register sind volatile, ich glaube dass der Compiler die Zugriffe
> daher nicht weg optimieren darf.

Macht er auch nicht:

1

  TCCR2A |= 0;

2

  d2:  e0 eb         ldi  r30, 0xB0  ; 176

3

  d4:  f0 e0         ldi  r31, 0x00  ; 0

4

  d6:  80 81         ld  r24, Z

5

  d8:  80 83         st  Z, r24

Hallo,

Theor schrieb:
>> Hallo,
>>
>> Gut das ich ein guter Programmier bin habe ich nie gesagt,
>> [...]
>
> Und ich habe auch nicht behauptet, dass Du das von Dir gesagt hättest.
> :-)
>
> Darum ging es mir nicht.

Okay, dann hatte ich das falsch aufnehmen. Sorry!

leo schrieb:
> Das wird dann noch gemacht mit nur anderem Text. Du findest sowas zuhauf
> im Code.

Ja weil ich zuvor den bestehen Text überschreiben muss mit einem 
schwarzen Rechteck um da sonst wildes Zeug raus kommt wenn ich es weg 
lasse.

Andreas K. schrieb:
> Dann schliess parallel am SPI noch einen kleinen SPI-Flash-Baustein an.

Andreas K. schrieb:
> kannst du einfach im Programm von
> der SD-Karte aus befüllen.

Das heißt wenn ich das richtig verstehe ich schreibe 1x die meine ganzen 
Strings auf die SD Karte und schreibe sie dann in den SPI Flash und dort 
bleiben sie ja bis ich sie wieder lösche.

Muss ich dann nicht massig Zugriffe machen, um die Strings dort wieder 
raus zubekommen?

M. K. schrieb:
> Sie
> werden mit Progmen/PSTR nur nicht ins RAM geschoben beim Start des uCs.

Achso.

Falk B. schrieb:
> Diese Funktion ist maximal albern, wenn gleich sie sicher nicht
> wahnsinnig viel Flash braucht.

500 Bytes hat Sie verbraucht. War noch eine alte Funktion um die 
Temperatur Korrektur zu machen für die pH Elektrode ist aber 
Mittlerweile nicht mehr in Gebrauch.

Falk B. schrieb:
> Schon mal was von einer Schleife gehört?

Ja habe. Ich habe jetzt eine for Schleife eingefügt.

Falk B. schrieb:
> Auch hier wieder sinnlose, endlose Funktionsaufrufe, die nur einen
> anderen Parameter haben! Sowas macht man mit einem Array, idealerweise
> liegt der im Flash (PROGMEM) und einer Schleife. Das ergibt nicht nur
> deutlich weniger Quelltext, der deutlich übersichtlicher ist, sondern
> auch deutlich weniger Flashverbrauch.

Also ich habe das mal versucht umzusetzen, doch ist der Flash verbrauch 
nicht gesunken sondern um 0,2%(256Bytes) gestiegen. Möglicherweiße habe 
ich es auch falsch gemacht, habe den Quellcode von ili9341_init() als 
Datei angehängt.

Falk B. schrieb:
> Nimm sprintf_P

Falk B. schrieb:
> direkt im FLASH und verbraucht keinen RAM!

Falk B. schrieb:
> Du musst deine Funktion auf PROGMEM-Strings
> umbauen. Dann sparst du massiv RAM.

Irgendwie stehe ich gerade auf den Schlauch. Es wurde ja bereits öfters 
geschrieben das ich mit PSTR und PROGMEM oder _P Strings aus dem RAM ins 
Flash lege.

Aber erhöhe ich nicht zwangsweise dadurch den Flash Verbrauch? RAM habe 
ich ja 16K wovon ich nicht mal 50 % im Moment benutze oder habe ich da 
was falsch verstanden?

Falk B. schrieb:
> Du spricht direkte, absolute Adressen im
> EERPOM an. Das ist Low Level Programmierung
> Man will Variablen mit gescheitem Namen
> ansprechen!

Was heißt den jetzt Low Level? Und wieso ist es schlecht das ich der 
Variable direkt den Wert aus dem EEPROM zuweiße? Wüsste jetzt nicht wie 
ich es sonst machen sollte.

Was meinst du genau mit gescheitem Namen? Ich mein ich weiß ja warum die 
Variable zb. ontime_co2_hour heißt oder ist damit gemeint das ich besser 
ein Array erstelle wie zb.

1

uint8_t co2ONTime[4];

Und dann dem Array 0 bis 4 die Adressen zuweiße?

Falk B. schrieb:
> Sieht du in den Massen an Schreibzugriffen selber noch durch

Falk B. schrieb:
> Denn sonst sieht man irgendwann nicht mehr durch.

Naja manchmal ist es schon ein bisschen speziell. Aber ich habe ein 
Excel Dokument wo ich Eintragen habe wie und wo welche Adresse und Wert 
abgespeichert ist und was das macht.

Falk B. schrieb:
> Schon mal was von einem struct gehört?

Gehört schon aber noch nie benutzt.

Falk B. schrieb:
> Allgemein sieht man in deinem Ansatz zum Menuaufbau tonnenweise
> Funktionsaufrufe zum Zeichnen.

Ich rufe die Menüs ja schon in der buttonpressed() Funktion auf die in 
der Menu Funktion vorhanden ist. Somit lade ich ja die Menüs schon vor. 
Wäre es besser wenn ich dort zb. ein Integer als Menü Index setze und 
ein Wechsel Boolean so das in der Menu geschaut wird ob gerade ein 
Wechsel erforderlich ist zb. vom Hauptmenü aufs RTC Menu und wenn das 
der Fall dann wechseln. Somit würde ich die Menüs ja unter ein anderer 
nicht mehr aufrufen sondern nur noch 1x Zentral von der main.c

Falk B. schrieb:
> Das ist Unsinn und macht im Extremfall nicht das, was du willst.

Ah gut zu wissen das nicht alles gewonnenes wissen richtig ist habe das 
mal so aufgeschnappt in einem Online Artikel über die AVR Programmierung 
... Deswegen habe ich das so gemacht. Bis jetzt hat es mich auch noch 
nicht im Stich gelassen.

Falk B. schrieb:
> Genau SO macht man das eben nicht!

Falk B. schrieb:
> Die Beispiele hier im Wiki
> machen das auch nicht!

Da war mal irgendwas warum ich das gemacht habe. Werde mir nochmal den 
Wiki Artikel durchlesen.

Lg

leo schrieb:
> Du hast die selben 3
> Zeilen Code x mal, nur mit anderem Text anstatt den Code genau 1 mal in
> einer Funktion zu haben, der du den unterschiedlichen Text uebergibst.

Hallo, ich glaube ich weiß jetzt wie du das meinst. Ich beziehe mich mal 
auf ein Code Schnippel aus der Co2Menu.c Datei Zeile 118-119 dort habe 
ich zwei Zeilen Code

1

ili9341_fillrect(87, 138, 120, 20, BLACK);

2

ili9341_combo(87, 140, WHITE, BLACK, 2, 3, 0, 0, "pH Stabil");

In Zeile 126-127 und 133-134 wiederholt sich der Code nur mit einem 
anderen Text. Ich habe mir jetzt folgende Funktion überlegt die halt das 
fillrect macht und den Text mittels PSTR übergibt:

1

void drawSelectedModus(const char *progmem_s) {

2

  ili9341_fillrect(87, 138, 120, 20, BLACK);

3

  ili9341_combo_flash(87, 140, WHITE, BLACK, 2, 3, 0, 0, progmem_s);  

4

}

Wenn ich die Zeilen die ich oben genannt habe durch die Funktion ersetze 
habe ich 46 Bytes Flash wieder frei.

Stefanus F. schrieb:
> Ich kann das auch gerne 100 mal schrieben, wenn es Dir hilft:

Nein. Aber ich glaube ich habe es jetzt verstanden. Ich habe mir den 
Link mal durchgelesen und mal mich erkundigt wie das mit dem RAM und 
Flash ungefähr funktioniert.

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Speicherzugriffe

Wenn ich das nun richtig verstanden habe belegt ein normaler String 
Flash und RAM. Wobei der String beim Start zusätzlich in den RAM kopiert 
wird. Das ist der Grund warum ich direkt drauf zugreifen kann. richtig?


Wenn ich jetzt den String mit PSTR oder PROGMEM anlege je nach dem, wird 
er erst gar nicht in den RAM kopiert. Er wird also nur im Flash anlegt. 
Wenn ich jetzt ein direkten Zugriffe drauf mache versucht das Programm 
die Adresse der Variable im RAM zu finden, wird es aber nicht da sie mit 
PSTR oder PROGMEM gar nicht erst ins RAM geladen wurde und ich bekomme 
irgendwas zurück.


Daher muss ich mit den Makros pgm_read_byte/word/... arbeiten damit das 
Programm nicht die Adresse des Strings aus dem RAM ließt sondern nach 
der Adresse im Flash.

Somit würde ich den doppelten Speicher belegen wenn ich ein String ohne 
PROGMEM anlege, das würde ja auch bedeuten das wenn ich einen normalen 
String anlege ohne PROGMEM das im RAM zwar eine Kopie liegt aber sie 
jedoch nur auf die Adresse des Strings im Flash verweist oder?

Lg

Felix N. schrieb:

> Somit würde ich den doppelten Speicher belegen wenn ich ein String ohne
> PROGMEM anlege, das würde ja auch bedeuten das wenn ich einen normalen
> String anlege ohne PROGMEM das im RAM zwar eine Kopie liegt aber sie
> jedoch nur auf die Adresse des Strings im Flash verweist oder?

Eine Kopie ist genau das: eine Kopie und kein Zeiger/Verweis. Ein Zeiger 
würde bei einem 16 Bit Adressraum nur 2 Byte brauchen, egal wie groß das 
Original ist. Eine Kopie braucht exakt so viel Platz wie das Original.

Das Problem bei AVR ist, dass Du einmal Adressen von 0...65535 fürs 
Flash hast und einmal Adressen von 0...65535 fürs RAM. Diese beiden 
Adressen sind nicht miteinander kompatibel, d.h. Du hast einmal eine wie 
strcpy für RAM-Adressen und einmal eine Spezialversion strcpy_P für 
Flash-Adressen. Bei ARM, MIPS und den meisten anderen Architekturen hast 
Du diese Unterscheidung nicht. Da hast Du nur einen Satz von Adressen 
von 0 bis 4G-1, und da ist alles drin: Flash, RAM, IO-Ports usw. Ist 
damit einfacher zu programmieren und ermöglicht es auch, Code aus dem 
RAM ablaufen zu lassen. Das ist auch etwas, was bei AVR grundsätzlich 
nicht geht.

fchk

Was Falk geschrieben hat ist richtig auch wenns nicht besonders 
diplomatisch war. Lass Dich nicht von diesen Helden mit den ESP- oder 
WIZ-Zeugs beeindrucken. Damit schaffts Du nur neue Baustellen.

Mein eigenes Projekt nutzt fast die gleiche Peripherie aber als 
FBH-Steuerung. Auch bei mir ist Speicher irgendwann knapp geworden. Habe 
dann auf den 2560 + 64k XMEM aufgerüstet - damit lebt es sich ganz 
entspannt. Das läuft 24/7 seit ein paar Jahren äußerst zuverlässig.

Felix N. schrieb:
> Das heißt wenn ich das richtig verstehe ich schreibe 1x die meine ganzen
> Strings auf die SD Karte und schreibe sie dann in den SPI Flash und dort
> bleiben sie ja bis ich sie wieder lösche.
>
> Muss ich dann nicht massig Zugriffe machen, um die Strings dort wieder
> raus zubekommen?

Naja, soo viel ist das nicht, kann man relativ einfach in eine Funktion 
packen. Aber soweit musst du gar nicht gehen, du hast noch VIEL Luft 
nach oben. Erstens durch eine gescheite Umstruktuerierung deines Codes 
(neudeutsch Refactoring) und 2. durch den großen Bruder mit 256kB Flash.

>Also ich habe das mal versucht umzusetzen, doch ist der Flash verbrauch
>nicht gesunken sondern um 0,2%(256Bytes) gestiegen.

Darf nicht sein.

> Möglicherweiße habe
>ich es auch falsch gemacht, habe den Quellcode von ili9341_init() als
>Datei angehängt.

Naja, schon mal besser, wenn gleich noch ausbaufähig. Vor allem schreibt 
man nicht eine supermegalange Zeile! Viel mehr als 100-120 Zeichen 
gehören nicht in eine Zeile. Ein Array darf problemlos über mehrere 
Zeilen gehen.
Ich hätte aber aber anders, gemacht, damit wird es kompakter. Kodiere 
die Befehle mit 16 Bit und nutze die oberen Bits zur Unterscheidung von 
Befehl und Daten. Das verschwendet zwar 7 Bit, macht das in Summe aber 
wieder wett (ein Maschinenbefehlt hat beim AVR auch 16 Bit). Siehe 
Anhang, ist aber nur beispielhaft, den Rest must du ergänzen.

>Aber erhöhe ich nicht zwangsweise dadurch den Flash Verbrauch? RAM habe
>ich ja 16K wovon ich nicht mal 50 % im Moment benutze oder habe ich da
>was falsch verstanden?

Ja hast du, immer noch.

Wenn man beim AVR "normale", konstante Strings benutzt, liegen die im 
Flash und werden vor dem Start von main() in den RAM kopiert. Mit denen 
arbeitet dann dein Programm. Die Strings im Flash werden danach nie 
wieder angesprochen.

Mit dem _P Funktionen etc. entfällt die Kopie in den RAM und die Strings 
werden DIREKT aus dem Flash gelesen und verarbeitet. Capice?

>Was heißt den jetzt Low Level?

Du kriechst im IT-Urschleim!

> Und wieso ist es schlecht das ich der
>Variable direkt den Wert aus dem EEPROM zuweiße?

Weil das Hacker und Amateurmurks ist und du ganz schnell nicht mehr 
durchsiehst. Warum wohl wurden selbst beim Assembler Namen für Variablen 
verwendet und keine Adressen? Weil der Mensch mit NAMEN deutlich besser 
klar kommt!

> Wüsste jetzt nicht wie
>ich es sonst machen sollte.

Richtig? Solche Sache packt man in ein struct.

1

typedef struct {

2

  uint16_t: max_temperature;

3

  uint16_t: min_temperature;

4

  long: Fish_counter

5

} my_setting_t;    // Datentyp als struct definieren

6

7

my_setting_t my_settings EEMEM; // Variable vom Typ my_setting_t im EEPROM anlegen.

8

9

eeprom_write_word(&my_settings.max_temperature, max);

10

min = eeprom_read_word(&my_settings.min_temperature);

Ist das nicht DEUTLICH lesbarer und vor allem selbsterklärend?

>Naja manchmal ist es schon ein bisschen speziell. Aber ich habe ein
>Excel Dokument wo ich Eintragen habe wie und wo welche Adresse und Wert
>abgespeichert ist und was das macht.

AUA! Genau SO macht man es NICHT! Denn dieser Job gehört dem COMPILER! 
Der verwaltet die Adressen! Du legst Variablen mit gescheiten Namen an, 
ggf. als Struct zusammengefaßt.

>Wäre es besser wenn ich dort zb. ein Integer als Menü Index setze und
>ein Wechsel Boolean so das in der Menu geschaut wird ob gerade ein
>Wechsel erforderlich ist zb. vom Hauptmenü aufs RTC Menu und wenn das
>der Fall dann wechseln.

JA!

> Somit würde ich die Menüs ja unter ein anderer
> nicht mehr aufrufen sondern nur noch 1x Zentral von der main.c

Das ist der Witz der Sache!

Hier der Anhang.

gdgddfgdfd schrieb:
> hi
>
> und so geht das durch den gesammten code weiter.
>
> ABER ...
> Alle haben mal angefangen und gelernt das jede Architektur  seine eigene
> Programmierweise hat...
> siehe AVR mit PROGMEM

Sicher, ist halt eine Besonderheit. Wenn man sie kennt ist es aber kein 
echtes Problem, nur ein wenig mehr Aufwand.

> und das er nunmal variablen > 8bit nicht so mag

UNSINN!!!

> Ich selbst arbeite momentan viel mit Cortex M7
> Da dieser Cache hat und immer 32byte aligned arbeitet muss man auch
> "komisch" programmieren.
> Ebenso der "ART" ist ein 128byte Cache für den Flashzugriff. Alle
> Funktionen >128bytes brauchen deutlich mehr Zeit.
> Ergo... alles zerhackstücken das man lieber viele viele kleine
> funktionen hat.  8bit ist hier eher kontraproduktiv weil trotzdem 32bit
> verbraucht werden... usw ...

Quark^3. Kein Mensch optimiert C-Funktionen, damit sie in den Cache der 
CPU passen. Das macht man, wenn überhaupt, in Assembler, und auch nur 
dort, wo es ULTIMATIV nötig ist.

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung

Die Grundlagen gelten ganz allgmein.

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Was

Man kann es ruhig auf die Spitze treiben. Alle ähnlichen Codesequenzen, 
die an 2 oder mehr Stellen auftreten, macht man zu einer Funktion, der 
nur die Unterschiede übergeben werden.
Es schaded auch nicht, wenn diese Funktionen nur aus 1 oder 2 Zeilen 
bestehen.

Der große Vorteil neben der Codeersparnis ist, man macht auch alle 
Fehler immer nur an einer Stelle, muß also nur eine Stelle korrigieren.

gdgddfgdfd schrieb:

> Wenn er mal mit Cortex M zu tun hat wird er der einfachheit halber auf
>

1

> const char *string = "test";

2

>

> zurückgreifen.

Oder auch für AVR

1

const auto s1 = "abc"_pgm;

schreiben. Damit sind gleiche Strings auch nur einmal im Flash, der 
Zugriff ist gekapselt, man kann kein _P mehr bei irgendeiner Funktion 
vergessen.

Daher der Ratschlag: bevor er die Plattform wechselt, was sicher bei der 
Auquariensteuerung völlig unnötig ist, erstmal mit dem Thema 
Softwareentwicklung intensiv befassen. Und das nicht auf dem µC, sondern 
in einer komfortableren Umgebung, etwa ein PC mit geeigneter IDE.

gdgddfgdfd schrieb:
> Falk B. schrieb:
>>> und das er nunmal variablen > 8bit nicht so mag
>>
>> UNSINN!!!
>
> Zugriffe auf 16/32bit sind also weiter in einem Takt möglich?
> Ich glaube nicht ...

War das die Frage? Ist das für einen Aquariumcontroller wichtig?

> Aber , wenn man in der summe etwas darauf achtet ist so ein AVR lange
> nicht am limit .. auch wenn hier oft solche threads erscheinen.

EBEN!

>> Quark^3. Kein Mensch optimiert C-Funktionen, damit sie in den Cache der
>> CPU passen. Das macht man, wenn überhaupt, in Assembler, und auch nur
>> dort, wo es ULTIMATIV nötig ist.
>
> Ich habe ein Projekt mit einem M7 der (nebenbei) mjpeg decodiert.
> Ohne diese Anpassung auf 32bit alianing oder kleinere Funktionen liegt
> die Bildrate bei QVGA bei ca 10-13fps , mit dieser Optimierung bei ca
> 22-25fps.

Eben DAS ist so eine Anwendung, wo sich so eine Optimierung lohnt. Das 
sollte man aber schon dazu sagen!

gdgddfgdfd schrieb:
> Aber nur durch fehler lernen wir , oder?

Viele nicht mal dadurch. Das geht schon bei der Groß/Kleinschreibung los 
. . .

Noch was.

Die One Wire Kommunikation ist NICHT solide, denn während der 
Übertragung eines Bits müssen die Interrupts gesperrt sein, damit das 
Timing wasserdicht ist! Außerdem braucht man auch hier für die 
Temperatur keine Fließkommazahlen. Außerdem fehlt die CRC-Prüfung, das 
kann bisweilen auch mal daneben gehen. Was macht deine Steuerung dann? 
So geht es sicher und besser.

Beitrag "Onewire + DS18x20 Library"

1

#include "MCP7940M.h"

2

#include "../Communication/usart.h"

3

4

const uint8_t daysInMonth [] PROGMEM = {31,28,31,30,31,30,31,31,30,31,30,31};

5

6

uint8_t  MCP7940_ADDRESS          =       0x6F;                       // Device address, fixed value      //

7

uint8_t  MCP7940_RTCSEC           =       0x00;                       // Section 1: timekeeping           //

8

uint8_t  MCP7940_RTCMIN           =       0x01;                       //                                  //

9

uint8_t  MCP7940_RTCHOUR          =       0x02;                       //                                  //

Auch das hier ist Unsinn. Hier werden echte Variablen angelegt, die 
echten RAM verbrauchen. Das braucht keiner, denn das sind alles 
Konstanten. In C nutzt man hier eher #define

1

#define  MCP7940_ADDRESS 0x6F // Device address

2

#define  MCP7940_RTCSEC  0x00 // Section 1: timekeeping

Falk B. schrieb:

> uint8_t  MCP7940_ADDRESS          =       0x6F;                       //
> Device address, fixed value      //
> uint8_t  MCP7940_RTCSEC           =       0x00;                       //
> Section 1: timekeeping           //
> uint8_t  MCP7940_RTCMIN           =       0x01;                       //
> //
> uint8_t  MCP7940_RTCHOUR          =       0x02;                       //
> //
> [/c]
>
> Auch das hier ist Unsinn. Hier werden echte Variablen angelegt, die
> echten RAM verbrauchen. Das braucht keiner, denn das sind alles
> Konstanten. In C nutzt man hier eher #define
>
>

1

> #define  MCP7940_ADDRESS 0x6F // Device address

2

> #define  MCP7940_RTCSEC  0x00 // Section 1: timekeeping

3

>

Oder static const uint8_t, wenn es typsicher sein soll.

fchk

Frank K. schrieb:
> Oder static const uint8_t, wenn es typsicher sein soll.
>
> fchk

Das wird dann aber in C auch eine echte Variabel mit RAM-Verbrauch, 
oder?

Frank K. schrieb:
> Falk B. schrieb:
>
>> uint8_t  MCP7940_ADDRESS          =       0x6F;                       //
>> Device address, fixed value      //
>> uint8_t  MCP7940_RTCSEC           =       0x00;                       //
>> Section 1: timekeeping           //
>> uint8_t  MCP7940_RTCMIN           =       0x01;                       //
>> //
>> uint8_t  MCP7940_RTCHOUR          =       0x02;                       //
>> //
>> [/c]
>>
>> Auch das hier ist Unsinn. Hier werden echte Variablen angelegt, die
>> echten RAM verbrauchen. Das braucht keiner, denn das sind alles
>> Konstanten. In C nutzt man hier eher #define
>>
>>

1

>> #define  MCP7940_ADDRESS 0x6F // Device address

2

>> #define  MCP7940_RTCSEC  0x00 // Section 1: timekeeping

3

>>

>
> Oder static const uint8_t, wenn es typsicher sein soll.

Mmh, und

1

MCP7940_RTCSEC * MCP7940_RTCMIN

ist ein sinnvoller Ausdruck?

Also, typsicher bedeutet etwas anderes!

Falk B. schrieb:
> Frank K. schrieb:
>> Oder static const uint8_t, wenn es typsicher sein soll.
>>
>> fchk
>
> Das wird dann aber in C auch eine echte Variabel mit RAM-Verbrauch,
> oder?

Das ist eine read-only Variable (constexpr gibt es nur in C++), die auch 
ein schlechter Compiler sicher gut wegoptimieren kann.

Falk B. schrieb:
> Die One Wire Kommunikation ist NICHT solide, denn während der
> Übertragung eines Bits müssen die Interrupts gesperrt sein, damit das
> Timing wasserdicht ist!

Das muss nicht Wasserdicht sein, da der AVR nicht im Aquarium ist ;-)

Hallo,

Arno schrieb:
> Ich möchte nochmal auf diese Frage hinweisen - ob mit -O0 oder -Os
> kompiliert wird, dürfte die Programmgröße massiv beeinflussen.

Habe mal unter AVR/GNU C Compiler -> Optimization nach geschaut dort 
steht drin: Optimization Level: Optimize(-O1).

Ich habe es mal testweise umstellt bei -O0 kann ich erst gar nicht 
kompilieren dort kommt der Fehler: "region `text' overflowed by 14018 
bytes"

Ja -O1 wird ja benutzt dort habe ich im Moment 98952 Bytes an Flash und 
6853 Bytes an SRAM. Mit -Os habe ich 89932 Bytes Flash und 6893 Bytes an 
SRAM.

Habe ich dadurch irgendwelche Nachteile wenn ich das auf -Os umstelle?

Arno schrieb:
> Genauso die Linker-Optionen überprüfen, ob zum Beispiel LTO aktiv ist.

Kann ich nicht finden. Weder als Checkbox noch in der Command Zeile.

Falk B. schrieb:
> gescheite Umstruktuerierung deines Codes

Ja da bin ich im Moment noch am Überlegen was mehr Sinn macht. Das 
Projekt neu Anlegen und den alten Code Schritt weiße übernehmen und 
dabei überarbeiten. Zb. Floats weg lassen ... oder im bestehenden Code 
überarbeiten.

Falk B. schrieb:
> Capice?

Frank K. schrieb:
> Eine Kopie ist genau das: eine Kopie und kein Zeiger/Verweis.

Stefanus F. schrieb:
> ja alles richtig.

Theor schrieb:
> Klar? Oder hast Du noch Fragen?

Habe es mittlerweile kapiert^^. Danke euch :)

Falk B. schrieb:
> Weil der Mensch mit NAMEN deutlich besser
> klar kommt!

Falk B. schrieb:
> Denn dieser Job gehört dem COMPILER!
> Der verwaltet die Adressen!

Moment mal. Das heißt ich definiere gar nicht die Adressen fürs EEPROM, 
sondern die werden dann Zufällig zugewiesen, oder wie muss ich das 
verstehen?

In deinem Struct Beispiel bezieht sich die 16 Bit 
Variable(min_temperature) ja nicht auf den gelesen Wert vom EE sondern 
auf die Adresse im EE wo der Wert liegt.

Oder muss ich die Variablen einmal mit einer Adresse definieren?

1

my_struct.irgendwas = eeprom_adresse;

Falk B. schrieb:
> Ist das nicht DEUTLICH lesbarer und vor allem selbsterklärend?

Ja auf jeden Fall. Aber eine Frage habe ich dazu noch du legt ja eine 
Variable von der Struktur im EEMEM an wobei sich EEMEM wahrscheinlich 
auf das Interne EEPROM des uC bezieht. Ich benutze ja ein externes 
EEPROM, reicht es dann wenn ich es nur mit

1

my_struct my_ee;

initialisiere?

Falk B. schrieb:
> Hier der Anhang.

Clever auf jeden Fall. Wäre ich aber im Leben nie drauf gekommen mit Bit 
Operatoren da zu arbeiten ...

Falk B. schrieb:
> Ist das für einen Aquariumcontroller wichtig?

Zeitkritisches habe ich eigentlich nix in meinem Projekt drin und wenn 
der pH Wert mal unter 6.80 sinken wird werden meine Fischis auch nicht 
davon sterben.

Das einzige wovor ich immer Angst hatte war das sich mein Controller 
aufhängt während gerade das Magnetventil für die Co2 Zufuhr geöffnet 
ist, konnte ich aber relativ einfach mit dem Watchdog Timer beheben. 
Zudem hat er sich bis jetzt auch noch nie aufgehängt.

gdgddfgdfd schrieb:
> Das ist als Anfänger schön wenn da was steht , ist aber
> oft auch totaler nonsins^^

Es hatte am Anfang wirklich mal ein Sinn gehabt, mein Controller hatte 
sich durch nicht ganz korrekte Verdrahtung und scheinbar Kapazitive 
Einkopplung der SCL und SCK Leitungen zu System Hängen geführt hat. Habe 
ich ein Start Up Bildschirm gemacht um zu sehen wo er sich aufhängt, es 
war auch mal eine Startzeit Messung drin aber das ist alles mittlerweile 
nicht mehr nötig.

Hatte die Texte damals dennoch drin gelassen, können aber raus. Muss die 
main eh mal aufräumen und ein paar Funkionen entfernen und auslagern.

gdgddfgdfd schrieb:
> auch Lesbarkeit:if(menuSelector == 2)
> ist nichtssagend.

Ja ich weiß menuSelector, menuPointer, menuInlinePointer ... mir war 
damals nix besseres eingefallen.

Falk B. schrieb:
> Außerdem fehlt die CRC-Prüfung, das
> kann bisweilen auch mal daneben gehen. Was macht deine Steuerung dann?

Die sollte weiterlaufen liefert mir nur dann eine Temperatur von 
-0.06°C. Den Link werde ich mir mal anschauen.

Falk B. schrieb:
> In C nutzt man hier eher #define

Ah ok. Ja die Lib kommt aus dem I-Net. Werde ich abändern. Schaue mir 
dann auch gleich mal die anderen Libs an ob es da noch sowas gibt.

Theor schrieb:
> Die Diskussion hier fokussiert sich

Theor schrieb:
> auf
> eine Überarbeitung des Codes und hat

Jor das wahr zwar eigentlich nicht mein Ziel. Aber der Richtung wechsel 
in die Code Optimierung finde gut. Bin gar nicht erst auf die Idee 
gekommen. Das der Flash wegen vielleicht falscher Programmierung voll 
ist.

Da habe ich am Ende mehr von als wenn ich mir jedesmal ein neuen uC 
kaufen mit mehr flash/ram etc.

Lg

Stefanus F. schrieb:
> Ich empfehle diese Optionen:
>
> FLAGS = -Wall -O1 -fshort-enums -ffunction-sections -fdata-sections
> CFLAGS = -std=c99

zusätzlich:

-mrelax -mcall-prologues

und natürlich -Os statt -O1.

Stefanus F. schrieb:
> -fshort-enums Die numerischen Werte von enums sind 8bit groß - Normal
> wären es 16bit

Das ist allerdings keine Optimieruns-Option, sonder wählt ein anderes 
ABI.

> -lm Bindet die Math Library ein, für Fließkommazahlen

Braucht man schon seit X Jahren nicht mehr.

Felix N. schrieb:
> Ja da bin ich im Moment noch am Überlegen was mehr Sinn macht. Das
> Projekt neu Anlegen und den alten Code Schritt weiße übernehmen und
> dabei überarbeiten.

Ja! neu anlegen und gründlich überarbeiten, da sind locker 30% code 
reduction drin, hinweise gab es hier doch reichlich und mal klartext - 
dein code ist sehr "bescheiden" so im sinne von level two auf einer 
scala von 1-10. mit 128k kannst du bei dem project lange bis ewig leben, 
wenn du sinnig programmierst.

und wenn noch nicht geschehen tausche auch die gcc version, gute 
erfahrung habe ich mit v8.3 bzgl. optimization.

und für die ferne zukunft würde ich vielleicht mal esp32 mit micropython 
andenken, python macht richtig spass braucht aber auch einige zeit bis 
man das halbwegs drauf hat und pythonkenntnisse kann man immer 
gebrauchen auf allen plattformen als schweizer-messer oder als die 
eierlegende wollmilchsau!


mt

Felix N. schrieb:

> Habe ich dadurch irgendwelche Nachteile wenn ich das auf -Os umstelle?

Nein.

> Falk B. schrieb:
>> Denn dieser Job gehört dem COMPILER!
>> Der verwaltet die Adressen!
>
> Moment mal. Das heißt ich definiere gar nicht die Adressen fürs EEPROM,

Ja.

> sondern die werden dann Zufällig zugewiesen,

Nicht ganz, aber im Normalfall ist die exakte Adresse einer Variable 
vollkommen egal. Das kann der Compiler zusammenbasteln wie er will. Es 
gibt Ausnahmen, logisch.

> oder wie muss ich das
> verstehen?

Bei Structs legt der Compiler die Daten exakt so in der Reihenfolge an, 
wie sie aufgeschrieben sind. Aber er darf bisweilen Lücken einfügen, 
wenn es die Architektur verlangt oder es Vorteile bringt.

> In deinem Struct Beispiel bezieht sich die 16 Bit
> Variable(min_temperature) ja nicht auf den gelesen Wert vom EE

Aber sicher!

> sondern
> auf die Adresse im EE wo der Wert liegt.
>
> Oder muss ich die Variablen einmal mit einer Adresse definieren?
> my_struct.irgendwas = eeprom_adresse;

NEIN!

Ok, hier gibt es ein Mißverständnis. Beim internen EEPROM übernimmt der 
Compiler die Adressverwaltung, genauso wie im RAM oder ROM (Flash). Bei 
externem, seriellen Speicher ist der Compiler nicht beteiligt, dort muss 
man alles "zu Fuß" organisieren. Aber auch dort ist man gut beraten, 
zumindest teilweise die Funktionen des Compilers zu nutzen. Eben indem 
man einen Struct definiert und die Daten struc(block) weise in den 
externen Speicher schreibt bzw. von dort liest.

> Falk B. schrieb:
>> Ist das nicht DEUTLICH lesbarer und vor allem selbsterklärend?
>
> Ja auf jeden Fall. Aber eine Frage habe ich dazu noch du legt ja eine
> Variable von der Struktur im EEMEM an wobei sich EEMEM wahrscheinlich
> auf das Interne EEPROM des uC bezieht. Ich benutze ja ein externes
> EEPROM, reicht es dann wenn ich es nur mitmy_struct my_ee;initialisiere?

Nein, das geht leider nicht, siehe oben. Aber auch dann arbeitet man 
nicht derartig mit absoluten Adressen.

> Falk B. schrieb:
>> Ist das für einen Aquariumcontroller wichtig?
>
> Zeitkritisches habe ich eigentlich nix in meinem Projekt drin und wenn
> der pH Wert mal unter 6.80 sinken wird werden meine Fischis auch nicht
> davon sterben.

Deine CPU wird so oder so tödlich gelangweilt sein, ganz egal wie 
ineffizient dein Programm ist.

> Jor das wahr zwar eigentlich nicht mein Ziel. Aber der Richtung wechsel
> in die Code Optimierung finde gut. Bin gar nicht erst auf die Idee
> gekommen. Das der Flash wegen vielleicht falscher Programmierung voll
> ist.

Vor allem. Wenn du sie meisten (alle?) konstanten Strings in den Flash 
verlagerst (PROGMEM und so), dann wird massiv RAM frei und du kanst 
problemlos mit dem großen Bruder 2561 (aka Arduino Mega) mit 256kB Flash 
und 8kB RAM arbeiten, ohne ins Schwitzen zu kommen.

Felix N. schrieb:
> Ja -O1 wird ja benutzt dort habe ich im Moment 98952 Bytes an Flash

und warum 4K für den Bootloader wo 512 Byte reichen?

Apollo M. schrieb:
> Ja! neu anlegen und gründlich überarbeiten

Ja glaubig auch. Werde ich auch machen.

Apollo M. schrieb:
> nd wenn noch nicht geschehen tausche auch die gcc version, gute
> erfahrung habe ich mit v8.3 bzgl. optimization.

Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht 
finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden:

http://blog.zakkemble.net/avr-gcc-builds/

Jedoch scheint da irgendwas faul zu sein. Beim Kompilieren meckerte er 
erst bei der Zusatz Option "unrecognized debug output level 
'c-sections'" habe dann -gc-sections entfernt dann konnte ich 
Kompilieren jedoch habe ich nun 0 Bytes Flash und 0 Bytes RAM Belegung. 
Yeah! Oder auch irgendwie nicht. Er lädt zumindest immer mein altes 
Programm hoch welches ich mit GCC 5.4.0 Kompiliert habe.

Habe nur die neuen Daten der Toolchain in den bestehen Ordner der 
Toolchain im Atmel Studio Ordner geschoben und halt 5.4.0(Ordner) 
gelöscht.

Falk B. schrieb:
> Aber sicher!

OK?

Falk B. schrieb:
> eeprom_write_word(&my_settings.max_temperature, max);

Da ich die interen EEPROM Funktion des AVRs nicht nutze habe ich mir mal 
kurz die Funktion angeschaut und der erste Parameter ist die Adresse im 
EEPROM der zweite Parameter der Wert.


Das heißt doch folglich dann wenn du als erstes die Variable aus der 
Struktur(max_temperature) übergibt als 1en Paramter das in dieser 
Variable(max_temperature) nicht Wert steht sondern nur die EEPROM 
Adresse die vom Kompiler vergeben wird steht. Und das der zweite 
Parameter(max) die Variable ist welchen den eigentlichen Wert enthält 
der ins EEPROM geschrieben werden soll. Oder nicht?

Falk B. schrieb:
> Ok, hier gibt es ein Mißverständnis. Beim internen EEPROM übernimmt der
> Compiler die Adressverwaltung, genauso wie im RAM oder ROM (Flash). Bei
> externem, seriellen Speicher ist der Compiler nicht beteiligt, dort muss
> man alles "zu Fuß" organisieren.

Sorry habe mit diesen Strukturen noch nie gearbeitet. Absolutes Neuland 
für mich.

Wenn ich das Interne EEPROM nutze brauch ich mir keine Gedanken machen 
um die Adressen im EEPROM. Nutze ich(wie jetzt) ein externes EEPROM muss 
ich diese ihm einmal Mitteilen. Würde das jetzt so machen:

1

typedef struct { //Struktur definieren

2

  uint8_t: karbonathaerte;

3

  uint8_t: benutzeDimmung;

4

  uint8_t: pHSoll;

5

  ...

6

} my_eepromAddress;

7

8

void setEEEPROMAddress(void) { //EEPROM Adressen einmal während des Startup laden

9

  my_eepromAddress.karbonathaerte = 0x01;

10

  my_eepromAddress.benutzeDimmung = 0x02;

11

  my_eepromAddress.phSoll    = 0x03;

12

  ...

13

}

Falk B. schrieb:
> Nein, das geht leider nicht

Muss ich dieses Struktur überhaupt initialisieren, ich meine du hast 
dort ja ein Datentyp im EEPROM anlegt. Kann ich dann direkt damit 
arbeiten sprich wie im meinem Beispiel oben?

Joachim B. schrieb:
> und warum 4K für den Bootloader wo 512 Byte reichen?

Der Controller liegt schon seit ein paar Jahren bei mir(so 2016) den 
habe ich damals fertig mit Bootloader bei unserem ehemaligen 
Elektronikshop um der Ecke gekauft, für glaubig 10 Eur. Dort sagte man 
mir es ist schon ein Bootloader drauf der würde ca. 4 Kb vom Flash in 
Anspruch nehmen. Aber gut zu wissen dann kann ich den neuen ja mal bei 
Gelegenheit drauf brennen.

Mfg

Felix N. schrieb:


> Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht
> finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden:

Warum nimmst du nicht einfach Atmelstudio? Dort ist alles fix und fertig 
drin. Dieses Rumgehacke mit Kommandozeile und Dutzenden Parametern ist 
gerade für Anfänger wie du schlicht Unsinn.

>> eeprom_write_word(&my_settings.max_temperature, max);
>
> Da ich die interen EEPROM Funktion des AVRs nicht nutze habe ich mir mal
> kurz die Funktion angeschaut und der erste Parameter ist die Adresse im
> EEPROM der zweite Parameter der Wert.

Ja.

> Das heißt doch folglich dann wenn du als erstes die Variable aus der
> Struktur(max_temperature) übergibt als 1en Paramter das in dieser
> Variable(max_temperature) nicht Wert steht sondern nur die EEPROM
> Adresse die vom Kompiler vergeben wird steht. Und das der zweite
> Parameter(max) die Variable ist welchen den eigentlichen Wert enthält
> der ins EEPROM geschrieben werden soll.

Ja sicher. Wo liegt das Problem?

> Wenn ich das Interne EEPROM nutze brauch ich mir keine Gedanken machen
> um die Adressen im EEPROM. Nutze ich(wie jetzt) ein externes EEPROM muss
> ich diese ihm einmal Mitteilen.

So einfach ist es nicht. Weig gesagt, bei externem EEPROM muss man 
vieles manuell machen. Man kann es nur dahingehend vereinfachen bzw. dem 
"Normalfall" angleichen, indem man z.B. beim Start einen Datenblock aus 
dem externen EEPROM in ein struct vom gleichen Typ in den RAM kopiert. 
Dann hat man alle Einstellungen im RAM und kann dort beliebige 
Schreib/Lesezugriffe machen. Irgendwann muss man dann aber die Daten vom 
RAM wieder in den EEPROM kopieren, damit sie dauerhaft erhalten bleiben.
Auch das macht man meist sinnvoll als Datenblock und nicht mit 
Einzeldaten.

 Würde das jetzt so machen:
> typedef struct { //Struktur definieren
>   uint8_t: karbonathaerte;
>   uint8_t: benutzeDimmung;
>   uint8_t: pHSoll;
>   ...
> } my_eepromAddress;

Das ist nicht ganz richtig. typedef definiert einen Datentyp, keine 
Variable. Und schon gar nicht eine Adresse! Solche Namen sind maximal 
irreführend! Die Variable muss dann im 2. Schritt normal definiert 
werden, wie in meinem Beispiel. Man kann zwar auch direkt eine Variable 
als struc anlegen, ohne einen Typ zu definieren, das ist aber meistens 
ungünstig. Näheres erklärt dir ein C-Buch.

> void setEEEPROMAddress(void) { //EEPROM Adressen einmal während des
> Startup laden

Falsch. Adressen werden nicht geladen. Gewöhn dir eine klare, saubere 
Sprache bzw. Beschreibung/Namensgebung an, sonst wurschtelst du nur rum.

Strukturierte Programmierung auf Mikrocontrollern

>   my_eepromAddress.karbonathaerte = 0x01;
>   my_eepromAddress.benutzeDimmung = 0x02;
>   my_eepromAddress.phSoll    = 0x03;

Was du meinst ist das Laden der EEPROM-Werte mit einem Startwert oder 
Standardwert. Das kann der Compiler selber.

struct my_settings EEMEM = {1, 2, 3};

Damit wird vom Compiler ein .eep File (Intel-HEX) erzeugt, daß ebenso 
wie der Flash einfach in den AVR programmiert wird. Damit hast du im 
internen EEPROM initialisierte Daten stehen. Beim externen EEPROM geht 
das freilich nicht. Da ist wieder Handarbeit angesagt.

Falk B. schrieb:
> struct my_settings EEMEM = {1, 2, 3};

Die bessere Schreibweise ist:

1

struct my_settings EEMEM = {

2

  .karbonathaerte = 0x01,

3

  .benutzeDimmung = 0x02,

4

  .phSoll         = 0x03,

5

};

Es müssen auch nicht alle Elemente initialisiert werden, die nicht 
aufgefürten werden mit 0 initialisiert.

svensson schrieb:
> Und wenn es wirklich zu knapp werden sollte, dann umsteigen auf eine Art
> "Mega256 als Nano", der sich auch in eigene Platinen per THT einlöten
> läßt:
> 
https://www.mikrocontroller-elektronik.de/mini-controllerboard-mit-atmel-atmega2560-und-usb/

Schönes Marketinggefasel!

>Leistungsstarker Controller ATMega2560 (einer der wohl leistungsfähigsten
> 8 Bit AVR-Controller überhaupt), 100 Pins am Gehäuse,

BlaBla. Der CPU-Kern ist bei allen AVRs praktisch gleich und damit 
gleich leistungsfähig. Nur die Speichergröße sowie IO-Module variieren

>256.000 Bytes Flash Speicher

Jaja, große Zahlen braucht das Land! Warum nicht gleich 2048000 Bit? 
Außerdem sind es 256KiB, was 262144 Bytes entspricht.

https://de.wikipedia.org/wiki/Binärpräfix

>8000 Byte RAM
>4000 Bytes EEPROM

Dito.

Felix N. schrieb:
> Nein ich benutze die GCC Version 5.4.0 die Version 8.3.0 kann ich nicht
> finden habe nur die AVR-GCC 9.2.0 gefunden zum Downloaden:
>
> http://blog.zakkemble.net/avr-gcc-builds/

... die gcc v8.3 findest du auch bei zakkemble, du nimmst den link der 
9.2 und ersetzt entsprechend auf 8.3.0.

ich benutze atmelstudio und kann bei mir via script mit einem klick 
zwischen den versioen 5.4-9.2 wechseln.

ABER! ... du musst immer die 5.4 avr_size.exe nehmen sonst wird dir 
bzgl. used code size müll angezeigt.

UND! ... zum debuggen eher auch die 5.4 nehmen, weil atmel studio sonst 
ein problem hat beim anzeigen mit den variables/symboles.


mt

temp schrieb:
> Auch wenn die ESPxxxx Controller massiv Flash und Ram haben und auch
> schnell sind, die bescheidenen Debugmöglichkeiten wären für mich ein
> NoGo für größere Projekte.

der esp32 lässt sich z.b. unter vsc einfach/vollständig debuggen, also 
kein problem, wenn man ahnung hat!