Arduino "C", waarom werkt dit niet.

Je hoeft runtime niets te initialiseren.

Het array van pointers wordt door de compiler voor je aangemaakt (gevuld met de pointers naar de apart gedeclareerde strings) en is bij aanvang van het programma al reeds klaar voor gebruik.

[Bericht gewijzigd door Bobosje op (15%)]

Ik gebruik zelf altijd enum ipv #define om aan begrip of woord een waarde te geven. Volgens mij is enum een placeholder of tijdelijke constante variabele die enkel voor het compileren gebruikt word maar na het compileren zijn de enums vervangen door de getallen zelf. En #define is ook zoiets? Of zit daar toch verschil tussen

Op een AVR moeten strings die NIET PROGMEM gedeclareerd zijn naar RAM gecopieerd worden. Want de strings gedragen zich in C als pointers en pointers zijn in de AVR altijd naar "RAM". Program memory is wat anders, wordt op een andere manier geadresseerd.

Dan kan je een truuk verzinnen om "gewoon" te adresseren als het hoogste bitje van de pointer "0" is en "program-memory-manier" als het bitje 1 is. Klinkt leuk, maar dan is iedere pointer access ineens veel lastiger/meer code/langer.

Dus de compiler guys voor de AVR hebben er voor gekozen dat je gewone strings gewoon naar RAM worden gecopieerd. Vervolgens zijn er toevoegingen gemaakt om ze toch in program memory te kunnen laten staan en om die dan te accessen.

Dit alles is dus een "gedoe". veroorzaakt veel frusttratie en zo.

Mijn advies is eigenlijk om al die PROGMEM shit gewoon weg te halen, gewone pointers te gebruiken. Kost wat RAM maar dat moet tegenwoordig geen probleem zijn.

Mocht het wel een probleem worden, dan raad ik aan om gewoon naar een ARM processor over te stappen. Die kan je nauwelijks kleiner dan 16k RAM en 64k Flash kopen. Dus 8/2x groter dan je AVR.

@benleentje: 

 
typedef enum {MAIN_MENU, LEVEL_1_MENU, LEVEL_2_MENU, LEVEL_3_MENU, 
        LEVEL_1_SUBMENU, LEVEL_2_SUBMENU, LEVEL_2_SUBSUBMENU, 
        LEVEL_3_SUBMENU, LEVEL_3_SUBSUBMENU} menu_pos_t;

doet ongeveer hetzelfde als de defines van de TS in de openingspost.

Maar nu heeft het een type gekregen, dus kan de compiler net wat meer er mee.

Als je dan bijvoorbeeld 


   switch (menu_pos) {
     case MAIN_MENU: ... 
      ... 
   }

een van de opties vergeet, dan kan de compiler daarvoor waarschuwen. Maar een array indexeren... Ik denk dat dat een foutmelding geeft als je geen cast naar "int" doet.

Vroeger was er een aparte preprocessor die #defines uitwerkte en gewoon de getalletjes invulde. De compiler zag dan altijd "4" ipv "LEVEL_1_SUBMENU". Tegenwoordig zit het meer "verwoven". En dus die ENUM is een compiler-feature, niet preprocessor. Het lijkt heel erg op mekaar maar is het dus net niet.

(Ik heb ooit op een computer uit 1975 gewerkt. Ding had 264k bytes aan RAM. 1) Dan zat ie vol. 2) Ding draaide gewoon multi-user-unix in dat geheugen. 3) Had gewoon een C compiler, maar dus wel aparte preprocessor en compiler in aparte processen die zonodig achter mekaar konden draaien. 1975 is "jonge jaren" voor de taal C.)

Mocht het wel een probleem worden, dan raad ik aan om gewoon naar een ARM processor over te stappen.

Arduino is inmiddels ook overgestapt. Een Arduino UNO draait tegenwoordig op een RENESAS ARM R7FA4M1, met 256K flash en 32K ram. En geen 'gedoe' met PROGMEM.

Zie https://store.arduino.cc/products/uno-r4-minima

Mijn advies is eigenlijk om al die PROGMEM shit gewoon weg te halen, gewone pointers te gebruiken. Kost wat RAM maar dat moet tegenwoordig geen probleem zijn.

Op de ATMega328 heb ik maar 2K

Zoals gezegd alle strings apart (PROGMEM) declareren en een array van pointers naar de strings (PROGMEM) declareren of een 2-dimensionaal (PROGMEM) array declareren en accepteren dat je flash ruimte verkwist en in beide gevallen wat code overhead accepteren om de strings in het programma te kunnen gebruiken, het is niet anders bij AVR.

Hier staat hoe : https://www.nongnu.org/avr-libc/user-manual/pgmspace.html

Op zondag 23 maart 2025 21:25:58 schreef bprosman:
[...]
Op de ATMega328 heb ik maar 2K

Weet ik. En dat is tegenwoordig: "Jezelf martelen omdat je het leuk vind".

Prima als je het inderdaad leuk vind.

Maar goed. Zonder progmem declaraties gaat het bij beginnende programmeurs gewoon ook heel lang goed, maar dan gewoon "zonder gezeik". Pas na veel strings zit je RAM ineens vol en moet je gaan kijken wat je naar progmem kan verplaatsen. En omdat je op dat moment er direct mee bezig bent, kan je direct alle bugs er uit vissen omdat je weet dat het door het "verplaatsen naar progmem" moet komen dat het ineens niet meer werkt.

Ik stop sinds jaar en dag een 128kB flash ARM op een project van mij. Daar is na jarenlange ontwikkeling nu 28k van in gebruik. En toch durf ik niet de 64k versie te kopen.

Op zondag 23 maart 2025 22:59:04 schreef rew:
[...]Weet ik. En dat is tegenwoordig: "Jezelf martelen omdat je het leuk vind".

Prima als je het inderdaad leuk vind.

Het is en blijft inderdaad hobby, mijn uren zijn "gratis", de rest van de code is helemaal niet zo spannend (wat HC595 aansturing) en met "a little help of my friends" (die ik zeer waardeer) hier is het probleem waar ik tegenaan liep (SRAM die ineens vol liep) opgelost en meteen weer een hoop geleerd over "C" en "C" in combinatie met Arduino in het bijzonder. Ik ben bij lange na geen "Ervaren programmeur" maar de knutsels/code die ik maak doen wat ik wil en daar gaat het me om.

Van deze topic heb ik weer hoop c kennis opgefrist.

"Jezelf martelen omdat je het leuk vind". Dat is charme van hobby. De ene persoon vindt bv een legpuzzel verschikkelijk, de ander geniet ervan.

Een goede uitleg vond ik ook deze site:
https://www.gammon.com.au/progmem