Kódméret csökkentés haladóknak

SzLacus

Az arduino tanfolyam kezdőknek szól, így szerintem a kódméret problémába csak idővel, (mikor már akkora fába vágják a fejszét) jutnak el a résztvevők. Nálam most jött el ez az idő. A 328-as flash-ében 30200 nál tartok a lehetséges 30720-ból, és még volna ötletem, mit is gyömöszöljek bele. Az előzményekhez tarozik, hogy LCD-re és soros portra küldözgetett üzenetek bőséggel vannak a kódban. Ki is futottam a SRAM-ból már régen, amikor rátaláltam a serial.print(F()) lehetőségre, ami sokat segített. Utána az LCD üzeneteket is bekényszerítettem a flashba, a progmem-el (örök hála csabeszq-nak a segítségért). Most viszont a flash van fogytán, annak ellenére, hogy az LCD üzeneteket a progmem-ből konkatenálom egy erre a célra létrehozott tömbbe, aminek tartalmát aztán az LCD-re küldöm. Az LCD-t, eddigi ismereteim szerint nem lehet direktben a progmem-ből etetni, de ez csak 2*16+1 bájt SRAM nyereséget hozna elvileg, és az most nem is segítene.
Azt olvastam, valahol a leckékben, hogy a flash 2 byte-os szervezésű. Akkor megtehetném, hogy a jelenlegi kb 350 byte-nyi LCD üzenetemet összepakolom word-ökbe, és így a fele helyen elférne. Nem elhanyagolandó nyereség, de vajon a kód egyéb részét is ilyen pocsékolással tárolja a rendszer? Mert akkor küzdhetek én, de az eredményemet a kód nagyon hatékonyan felfalja.
Van valakinek számomra is érthető útba igazítása a támában? Az arduino kód tárolása kihasználja a 2 byte-os flash szerkezetet? Vagy a 32k területen valójában 16k kód van?
Amúgy a word-be tuszkolásnál jobban járok, ha az egész üzenet-definíciós részt az EEPROM-ba átrakom, mert akkor a teljes terület felszabadul, az EEPROM meg amúgy is bájtos szervezésű, és jelen feladatnál még hely is van benne bőven. Más kérdés, hogy két lépcsőben kell majd a programomat új arduino panelbe oltani, az egyik progival fel kell töltenem az EEPROMBA a tartalmat, a másikkal pedig a flash-ba a futtatandó kódot. Vagy meg lehet úgy oldani, hogy az üzenet fájl tartalmát az eepromba író rész kerüljön a kódom elejére? Hogyan kell egy ilyen hivatkozást tenni? Már csak azért, mert a futtató környezetben nincs ott a fájl, amit az eeprom-ba kéne írni. Azt észre tudom venni, hogy már fel van töltve az eeprom, de ha nincs, akkor csak hibát tudok jelezni, a feltöltés nem lesz lehetséges futás közben.
További kérdésem, hogy hova rakja az arduino a köztes állományokat, amiből meg lehetne tudni, hogy hol pocsékolom az értékes erőforrást.
Azt tapasztalom ugyanis, hogy egy konkat hívás az 10 bájt, már pedig abból van nálam bőven. Egy-egy 16 karakteres üzenet akár 4-5 részből is állhat, ami 4-5 konkat hívást jelent. Ez 40-50 bájt, eg y16 bájtos kiírásért. Ez nem tűnik jó üzletnek. Szeretném tudni mi van abban a 10 bájtban.

Előre is köszönöm a segítségeket.

SzLacus

A részletesebb működés értését célzó segítség kérésemet fenntartva az alábbi tapasztalatokat osztom meg a közzel.
Jelenlegi tapasztalatom szerint nem érdemes a kiírandó szöveget darabokból össze ollózgatnom, mert a fix 16 hosszú szöveg összességében kevesebb helyet foglal az ollózási kód elhagyásával. A legdurvább nyereséget annak a rutinomnak az elhagyása hozta, ami a kész szöveg mögött a sort space-okkal töltötte fel, hogy az előző szöveg maradéka törlődjön a kijelzőről. Természetesen úgy írtam meg, hogy a rutin igazodjon a mindenkori kijelző szélességéhez, de túl nagy árat kell fizetni érte. Sokkal kevesebb erőforrás a fix széles egész soros üzeneteket eltárolni. Meglepődtem, de ha jól bele gondolok, meg még mélyebben megismerem a szerkezet működését, akkor meg is fogom érteni.
Az a példa történet jut eszembe, amikor az űrkutatási versenyben az amerikaiak, rengeteg pénzért kifejlesztettek olyan tollat, ami zéró gravitációban is működik. Az oroszok pedig grafit ceruzával jegyzeteltek.

Az Arduino _pazarolja_ a kódot. SRAM-ban a változókat konzekvensen integerként tárolja, amikor char/byte is elég lenne. A Flash meg programkódilag elég necces.

Néhány tipp a kódcsökkentésre (teljes rendszerszinten):
http://code.google.com/p/arduino-lite/

Soros kezelés/setup() miatt:
http://blog.spitzenpfeil.org/wordpress/ ... ash-space/

Int/Float miatt:
http://www.instructables.com/id/Make-an ... h-smaller/

csabeszq

A flashbe a stringek nem 2-byte szervezésbe vannak berakva. Egy karakter egy byte.
Érdemes megnézni, hogy mi fogyaszt sok memóriát. Ehhez látni kellene a kódodat.

A Flash 1byte/2byte szervezése az nem a programkód alapján történik, hanem a chip belső sajátja. Ebbe nem tudsz belenyúlni.

kapu48

„A flashbe a stringek nem 2-byte szervezésbe vannak berakva. Egy karakter egy byte.”

Ez csak azzal a kikötéssel igaz, hogy minden Flash területfoglalásnak páros Címről kel kezdődnie.
(A Cím 0-s BITje = 0)
Ezért a fordító a páratlan foglalást kiegészíti + 1 BYTE lefoglalásával.
Ha a Stringed 2,4,6… karakter + a String végi 0.
Így ezek páratlan számú BYTE-k lesznek!

Vegyük a 2 karakter esetét:
Cím: B0000_0000 < 1 karakter
Cím: B0000_0001 < 2 karakter
Cím: B0000_0010 < 0 String vég
Cím: B0000_0011 < 0 Kimarad
Cím: B0000_0100 < Következő foglalás kezdete

1 BYTE foglalása esetén is 2 BYTES lesz lefoglalva.

SzLacus

Köszönöm a segítséget, haladok bár csak aprók a lépések. Vannak viszont érdekes tapasztalataim.
A "hova teszi az arduinio" kezdetű kérdésemre némi kutakodással megtaláltam a választ. A local temp-be. Találtam ott érdekes dolgokat, amiket nem tudom miként kerülnek oda. Az IPAdress, és a HID kezdetű állományok leptek meg a legjobban, de van ott sok más is amit én nem használok ebben a projektben. Egyik sem annyira hatalmas méret, de sok kicsi sokra megy. Azt jó lenne tudni, hogy ezeket az object fájlokat mivel tudom értelmesen megjeleníteni, illetve, hogy a darabok miként állnak össze egésszé.
Azt kikísérleteztem, hogy a szövegek összeállítását végző rutinjaim azok amik sok helyen vannak hívva, és sokat fogysztanak. Azt nem pontosan tudom, hogy miért, de ez a tapasztalat. A legdurvább az a rutin ami az össze ollózott szöveg végét kiegészíti space-okkal, hogy az előző szöveg maradéka ne maradjon a friss szöveg mögött. Ezt csak az okulás kedvéért ide hozom (elrettentő) példának. Az érthetőség kedvéért néhány premissza. A szovegLCDre 2*16-os terület, ahonnét a kijelzőre küldöm a szöveget. A teljesség kedvéért mögé rakom a kiküldő rutint is, ami a karakter cseréken túl arról is gondoskodik, hogy az első karakter nagy beűvel jelenjen meg a kijelzőn.

Kód: Egész kijelölése

void vegeKonkat(byte line){
//Végig megyek a szovegLCDre tömbön, és ha a vége előtt nullát találok, akkor onnan kezdve a végéig space-vel törlöm a sor végéig
boolean spaceToltes = false;
for (byte i = 0; i < colums; i++){
  if (!szovegLCDre[line][i] || spaceToltes){
    spaceToltes = true;
    szovegLCDre[line][i] = ' ';
  }
}
  return;
}  // void vegeKonkat VÉGE!!! 


void lcdKiiras(byte oszlop, byte sor, char szoveg[], byte hossz){
  lcd.setCursor(oszlop,sor);
  cursorPoi = oszlop;
  for(byte i = 0; i < hossz; i++){
  switch (szoveg[i]){
  case 'á':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(AA);
    }else{
      lcd.write(aa);
    }
  break;
  
  case 'Á':
    lcd.write(AA);
  break;
  
  case 'é':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(EE);
    }else{
      lcd.write(ee);
    }
  break;
  
  case 'É':
    lcd.write(EE);
  break;
  
  case 'í':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(II);
    }else{
      lcd.write(ii);
    }
  break;
  
  case 'Í':
    lcd.write(II);
  break;
  
  case 'ó':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(OO);
    }else{
      lcd.write(oo);
    }
  break;
  
  case 'Ó':
    lcd.write(OO);
  break;
  
  case 'ö':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(OE);
    }else{
      lcd.write(oe);
    }
  break;
  
  case 'Ö':
    lcd.write(OE);
  break;
  
  case 'ő':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(OEE);
    }else{
      lcd.write(oee);
    }
  break;
  
  case 'Ő':
    lcd.write(OEE);
  break;
  
  case 'ú':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(UU);
    }else{
      lcd.write(uu);
    }
  break;
  
  case 'Ú':
    lcd.write(UU);
  break;
  
  case 'ü':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(UE);
    }else{
      lcd.write(ue);
    }
  break;
  
  case 'Ü':
    lcd.write(UE);
  break;
  
  case 'ű':
    if(!cursorPoi)  // Ha sor elejére megy akkor nagy betűvel írom
    {
      lcd.write(UEE);
    }else{
      lcd.write(uee);
    }
  break;
  
  case 'Ű':
    lcd.write(UEE);
  break;
  
  default:
    if(!cursorPoi &&            // Ha sor elejére megy akkor nagy betűvel írom
      szoveg[i] >= 0x61 &&      // a-z közti karaktert kell kiírni
      szoveg[i] <= 0x7A)
    {
      lcd.write(szoveg[i] - 0x20);  // Akkor A-Z közti karaktert írok ki
    }else{
      lcd.write(szoveg[i]);
    }
    }    //  switch (szoveg[i]) VÉGE!!!!!
    cursorPoi++;
  }    //  for(byte i = 0; i < hossz; i++) VÉGE!!!!!
  return;
}  // lcdKiiras VÉGE!!!

Egy lcd.print utasítás 8 byte-al növeli a kódomat, saját kiírókám 10-el, ezt el tudom viselni az ékezetes betűkért cserébe. A vége ennél sokkal durvább, de minden, ami 16 karakter megjelenítésére többet használ 16 karakternél, azt soknak érzem. Ezért most szétbombázom az egész szöveg kőldő részt, és az eddigi szavak, szórészletek össze ollózgatása helyett a teljes soros eltárolást valósítom meg. Ahol pedig változó szerepel a szövegben, ott visszaléptek, és felülírom a változóval az előzőleg kikőldött szövegben a változó helyét. Aztán majd meglátom, hogy van-e még ennél is jobb megoldás, ha megint kifogy alólam a terület.

Köszönöm, most már értem a helyfoglalást a flash-ban. Azok az egy-egy bájtok áldozatul esnek, ez van, megint csak nem ezen fog múlni, hogy beférek, vagy nem. Amit itt "elvesztek", annál még sokkal többre lenne szükségem. A kódom "pazarékol".
Arra is jó volna rájönnöm, hogy hogyan lehet makrót definiálni. Mert ha csak pár ismétlődő sort kéne használnom, és az rövidebb mint ha függvényként hivom, akkor érdemes volna azt használnom. Szóval van még mit tanulni. Például azt is tudni szeretném, hogyan lehet több fájlba szérrakni a kódomat, mert ez a több mint 3000 sor ez eléggé követhetetlen kezd lenni. Például a definiciós részt szívesen látnám egy önálló fájlban, amit aztán includolnék. A saját rutinok is jól kimehetnének fájlba, sokat javítana az átláthatóságon. Ettől persze nem volna rövidebb a programom, csak szebb.
Ami linket Robi küldött, az elsőre nálamnál haladóbbnak való, már ami a felesleges könyvtárak befordításának kigyomlálását illeti, de ha nem lesz más út akkor azt is meg fogom próbálni. Most még megpróbálom a komfort zónámon belül.

Fejlesztés során nálam ami a szempont: a kész(nek) tűnő kóda chipből max 3/4-ét foglalhatja el. Mert később jönnek a funkciók, hogy mit kell még tudni. A Cipőskanál-fejlesztések erőforrásigénye meg megy a végtelenbe...

Nem lehet áttérni a Mega alappanelre?
Flash: 32k -> 256k
SRAM: 2k -> 8k

csabeszq

Ha nincs 1000 darab 1 byte-os stringed, akkor nem komoly probléma az egész.

Ahol tudsz eredményt elérni:
- nem használsz lebegőpontos számokat (float/double)
- a legkisebb adattípusokat használod (uint8 uint16 uint32)
Próbáld ki, hogy egy for ciklusba uint32-t raksz és mit eredményez.
- függvényhívások számát minimalizálod

Ami a switch-case-t illeti: nálam az idióta fordító uint16-ot generált. Mégsem javaslom, hogy írd át if/else-re mert olvashatatlan lesz a kód.

Szemmel láthatólag meghívsz vagy 20 lcd.write-ot. Ez foglal helyet, próbáld kevesebb hívással elindézni (pointer).

csabeszq

Az egész switch-case-t át lehetne rakni egy táblázatba.

SzLacus

Egyenlőre megfutamodásnak érzem a 2560 irányt, de nem vetem el. Bár a tervem nanora épül.
Lebegőpontosom nincs, függvényhivás viszont dögivel van. Mondjuk minden kiküldött karakter egy-egy lcdwrite hivás. Menjek inkább az lcdprint felé és akkor váltsak lcdwrite-ra, ha spec karatert kell kiírnom? De hogyan tudom egyszrűen elvágni a szövegemet a spec karakternél, ahol a printről át kell váltanom write-ra, aztán vissza. Vagy kilököm a szöveget printtel, aztán felülírom write-al a szemetet a magyar karakterekkel. Olyan gyors lesz, hogy nem lehet majd észrevenni?

Az LCD kezelés a lassú. A tényleges írás. A belső alakítgatás gyors.
A kódon sokat nem tudsz faragni, sajnos.

Off: nálam a Bascom-AVR a programnyelv inkább, itt a kód kisebb (kb fele lefordítva).

SzLacus

Igen az LCD.nek kiküldött dologban több helyen láttam mindenféle kötelező várakozási időket. Én arra gondoltam, hogy vajon a két egymást követő kiírásban észrevehető-e az emberi szem számára, hogy az elsőben a magyar karakterek helyén krix-krax van, aztán a átváltanak szép ékezetes magyarra. Kipróbálom mindenképpen, csak gondoltam más már megküzdött ezzel a problémával. Csak szeret más is korrekt magyar szövegeket látni a kijelzőn.
De közben több oldal ág elhalni látszik, például hogyan lehet az arduino lefordított állományait olvaskatóan megjeleníteni. Mondjuk például studióban.

kapu48

AVR Studioban, nagyon egyszerű!

Betöltöd a *.hex fájlt.
Kéri, hogy mi az AVR típusa (ezt kel tudnod!) Be jelölöd neki.
Elmented amit felkinál!

Megjelenik a Disassembler ablakban a visszafordított kód.

És Felül a debug gombokkal szimulálhatod a program futását!
Akár lépésenként is.
Közben az Procesor és I/O Viev ablakokban beírhatod az épen szimulálni kívánt értékeket is.

Sok sikert!

SzLacus

Köszi, ez nem tűnik bonyodalmasnak, de ha a hex-ből megy visszafelé, akkor gondolom elvesztem a változóim, a függvényhívásaim, és minden egyéb számomra ismerős kapaszkodó nevét. Így elég nehéz lesz megtalálnom, hogy az általam leírt kódrészletből pontosan mit is készített a fordító. Az objektben még gondolom benne van minden, abból, vagy a kettő kombinációjából (hex és obj) nem lehet kiindulni. Akkor láthatnám hol pocsékolok, hol nem dolgozom jól a fordító keze alá.

TavIR-AVR oldal