Kicsit bõvebben a mostani megbicsaklásról:
(ezt) A uC-t átprogramozni többféleképpen is lehet. Párhuzamos égetõvel, ahogy az EPROM-okat is, ehhez az égetõbe kell helyezni. Ez itt nálunk szóba sem jöhet. Van In-Circuit programozási lehetõség is benne, ez tképpen egy SPI busz, tehát 3 láb (plusz a RESET lába) kell hozzá. És van az In-Application mód, tehát saját magát is tudja átírni, programból.
De azért van egy --elég nagy-- különbség a harmadik esetben. Egyrészt "csak" a program, ill. az EEPROM területet lehet így átírni. Másrészt vannak a uC-ben ún. "fuse" bitek is (meg egyéb is, de az most nem érdekes), amit így nem lehet elérni. Ebbõl a legfontosabb, hogy itt kell beállítani, hogy belsõ oszcillátorról, vagy külsõ kvarcról járjon-e.
Ez azért nem olyan nagy restrikció, de ezért van az, hogy elõre el kell dönteni, milyen oszcillátorral mûködjön.
A tervezési fázisban elég sok idõt eltöltöttem vele, hogy milyen módon is legyen illesztve a helyére. Az ideális az lett volna, ha csak egyszerûen ráhelyezhetõ lett volna, átkötések nélkül. Sajnos, ez nem megy, az EP-ben alkalmazott 373-as IC-nek elég "buta" lábkiosztása van. Azóta már 573-as IC is létezik, annak szépen egymás mellett vannak a lábai.
A másik ok, amiért próbáltam ígyis, úgyis forgatni/eltolni az IC-t a helyén, hogy az In-Curcuit programozáshoz szükséges lábai olyan helyre essenek, amit majd az EP-bõl könnyedén lehet vezérelni. (Tényleg 6-féle verzió létezik nálam papíron
)
A végeredmény persze kompromisszum lett. Az In-Circuit programozásról sajnos le kellett mondanom, fontosabb szempont volt az egyszerûbb beépítés.
Így tehát maradt az In-Application mód, tehát SW-bõl átírni a programot.
Ezzel azért van egy kis bibi, a (upgrade) program nyilván nem írhatja át saját magát. Ez az egyik oka, hogy azt a programterületet miért nem engedem felülírni.
De van egy másik, sokkal fontosabb oka is.
A uC minden, az EP-re csatlakozó lába kétirányú. Azt, hogy éppen bemenetként, vagy kimenetként viselkedik-e, csak a futó program határozza meg. A kimeneti fokozata pedig erõs, sokkal erõsebb, mint a sok évvel azelõtti technológia.
4 láb az EP adatbuszára csatlakozik, egy pedig a DAVE WR0 lábára. Ezeknek tehát kötelezõ bemenetként mûködnie. Ha bármilyen okból is kimenet lenne, az bizony nagy bajt okozhatna az EP-ben.
Emiatt nagyon fontos, hogy a uC programja megfelelõen mûködjön. Erre több biztonsági dolgot is beépítettem:
- a WR0-ra mûködõ IT rutin elsõ dolga, hogy az ominózus lábakat bemenetnek konfigurálja
- a boot loader protokollja elég macerás, véletlenszerûen nem állítható elõ olyan sorozat, amivel átírható lenne a program (legalábbis remélem). Plusz:
- a "fõ" programot induláskor CRC-vel ellenõrzöm. Ez persze nem zárja ki, hogy "legálisan" feltöltött program bármi galádságot elkövessen, de
- fut egy watchdog folyamatosan, max. 125 msec-enként szintén bemenetre állítja a lábakat.
- az IT rutin(ok) és watchdog programterületet nem engedem átírni.
És ez az elsõdleges oka annak is, hogy a forráskódot még nem tettem publikussá.
Ezek tehát az elõzmények. Eddig úgy is tûnt, elégséges, amit elkövettem.
Egyetlen (ismert) probléma van csak, ha az --elvileg fix-- programrész (IT rutinok, wathcdog, startup, boot loader) megsérül. Erre sok esély nincs, be is vállaltam.
Mégis elõfordult. (Hja, Murphy fáradhatatlan
)
Mi ezzel a gond? Az egyik, hogy nem mûködik. A rosszabb, hogy nem is lehet helyrehozni In-Application módszerrel (ha a boot loader rész sérült). A harmadik, és legsúlyosabb, hogy a biztonsági intézkedések az EP HW védelmében megszûntek.
Most ott tartunk tehát, hogy
mégiscsak szükség lenne az In-Circuit programozásra, azzal helyrehozható minden.
Ez egy kissé macerás, de talán mégiscsak összejön. Már dolgozom rajta... (És közben folyamatosan tipródok, hogy nem kéne-e mégiscsak nagyobb/drágább, de korrektebb HW-t gyártani inkább.
)
Addig is türelmet kérek, és elnézést, hogy így elhúzódik a projekt. De mindennél fontosabb szempontnak tartom a biztonságot.
Amíg az veszélyben van, addig nem adom ki a kezembõl. Legalábbis így gondolom. Ha csak meg nem gyõztök az ellenkezõjérõl...
