Optimalizált PIC égetés a WPB_F18-al.

Kiváltó ok:

Nagyon zavart, mikor egy nagyobb Flash területű PIC-et fejlesztettem, és a program kezdett ezer bájt fölé duzzadni, hogy az égetés egyre több időt rabolt el. Nehéz volt megemészteni, mikor csak egy-két programszó változtatása miatt perceket kellett várakozni, mire a program kiért.

Első gondolat:

A problémára látszólag nincsen megoldás, mert gyorsabban égetni a PIC által felkínált sebességnél nem lehet, ezért nem is ez irányba gondolkodtam tovább.

Lehetséges megoldás:

Arra gondoltam, hogy ha a PIC forrás fejlesztésekor felosztanám a program területet részekre(ORG-okkal) és az égető program képes lenne összehasonlítani a beégetett és a beégetendő adatokat, akkor a felosztott területeken történt változás esetén a változás pontjától kezdené csak írni a memóriát és azt is csak a következő ORG-ig(de minimum 64bájtig(lásd később)), a többi érintetlen részt nem írná újra, azokon átfutna. Ha feltelne két ORG közötti rész, akkor vagy egy újabb részen kéne folytatni az utolsó ORG-rész után(kihagyva az előző résznek teret), vagy beszúrni helyet, ezzel lejjebb csúsztatni az egész programot, és ilyen esetekben egyszer bevállalni a hosszabb égetést.

A megoldás egyetlen hátránya, hogy a felosztást nekünk kell kezelni, ami némi plusz odafigyelést és előre tervezést kíván, viszont a fejlesztés jelentősen felgyorsulhat, nem beszélve, hogy szerencsés esetben a memória élettartamát(törlés-írás ciklus) is ki lehetne nyújtani, mert egy jól megírt részt már nem kell módosítgatni, az nem lesz felülírva feleslegesen, szemben azzal, ahogy ezt teszik az égetők általában. Az meg kizárható, hogy egy területtel annyit molyolnánk, hogy meghaladnánk a határértéket(100ezer ciklus kb.)

Lehetőségek a felosztásra:

A Flash memóriát blokkonként lehet törölni-módosítani, ahol legkisebb megkezdett, azaz törölt és ebből fakadóan felülírandó blokk mérete 64 bájt. A kezdő cím tetszőleges, de onnan a 64bájt törölve lesz. Ebből nem az következik, hogy mi 64 bájtos szakaszokra kellene bontsuk a programunkat. Nekem ami bevált az 250-500 bájt méretű blokk volt. Egy blokkot soha nem írtam tele, hogy a későbbi módosításoknak teret hagyjak. Ha több rész készen volt, akkor összevontam őket, hogy a felesleges hely felszabaduljon. Ha szükséges volt későbbi módosítása egy összevont résznek, akkor ismét felosztottam.

Így jelentősen rövidültek a programégetési idők a korábbiakhoz képest.

Égetőprogram elvi működése:

A program megkeresi az első eltérést a beégetendő és PIC memóriában tárolt adatok között. Ha tudjuk, hogy az előző írás tartalma van a PIC-ben(amit elmentettünk a Verify pufferbe az íráskor), akkor nem olvassa be a PIC-et feleslegesen, hanem ehhez hasonlítja a beégetendő FőPuffer tartalmát, és csak az eltérő 64 bájtos blokkot írja felül. Ha a Verify puffer üres, akkor azt nekünk előbb fel kell tölteni a PIC kiolvasásával.

2006. április 19. watt