Ez a topik azoknak a kezdőknek illetve haladóknak szól, akik szeretnének megismerni és használni egy költségkímélő és hatékony PIC fejlesztési módszert, illetve hajlandóak tapasztalataikkal, ötleteikkel támogatni az e módszerhez tartozó szoftverek bővítését, javítgatását.

A mikrokontrollerekkel kapcsolatos oldalakat, fórumokat olvasgatva újra és újra elképeszt, hogy szinte sehol, vagy csak nyomokban bukkan föl az a "spanyolviaszk", amely számomra teljesen természetes, ám másoknak szinte évtizedek óta nem jut eszébe. Vagy ha mégis, akkor nem jut el a publikáció szintjéig, vagy ha igen, akkor is legtöbbször kikerül a figyelem központjából. Részben e jelenség megértése is az új topik nyitásának a célja, feltéve, hogy nem én vagyok teljesen vak és szélesre tárt ajtókon dörömbölök.

Tehát tömören, és e régi módszer történetéről most nem beszélve, a köldökzsinór módszer:

1. Kössük össze egy egyszerű, és olcsó(!) áramkörrel a PIC soros vonalait (RX,TX) a PC soros portjával (pl. COM1). Ez a ködökzsinór HW. Ennyi plussz kell, illetve olyan PIC amely rendelkezik soros porttal (USART, AUSART, EUSART).

2. Égessünk a PIC-be egy kis terjedelmű (kb. 1 KiW) mini "operációs rendszert", amelyet - utóbbi időkben - NAVEL-nak nevezek (navel=köldök) a más nevekkel való ütközés elkerülése céljából. Ehhez természetesen olyan PIC kell a fejlesztés folyamán, amelybe a NAVEL és a programunk is belefér. Kell még néhány bájt (kb. 1 tucat) RAM is.

3. A PC-n pedig futtassuk azt a programot (saját fejlesztés: NavelStr.exe; ahol a Navel String = köldökzsinór). Ez kommunikál a NAVEL-lel (kezdetben a soros vonal tesztelése a cél), és parancsokat küld számára, melyeket az értelmezi, és végrehajt egyszerű funkciókat, illetve visszaküld adatokat.

4. Tegyük ezeket az információkat, kódokat mindenki számára ingyenesen hozzáférhetővé, ahogy ez az utóbbi időkben egyre gyakoribb, és persze észzerű is.

Az igy kialakított rendszer fő feladata az, hogy monitorozni tudja a PIC összes memóriáját, és ha kívánjuk, akkor meg is változtathatjuk azok tartalmát. Ez utóbbi a programmemória esetén olyan PIC-et kíván amelyben megvan erre a lehetőség. Ezen felül lehetőségünk van arra is, hogy az I/O regisztereket bites felbontásban (bitek nevei szerint!) is megtekinthetjük, illetve a biteket megváltoztathatjuk, vagy pulzusokat adhatunk rá. Végül lehetőségünk van arra is, hogy megadott címről rutinokat, programrészeket indítsunk el, mely ha nem száll el, akkor visszatér a NAVEL-ba, és folytatható a monitorozás.

A NAVEL sok funkciót levehet a programozó válláról (mint a PC BIOS), inicializál, kezeli az interrupt-okat, felismeri a különböző RESET-eket. Modulárisan bővíthető, és mindíg van lehetőség az egyes beépült funkciók esetén is a saját programrésszel való bővítésére. Ja és ezek e bővítések NEM a NAVEL forrásnyelvi szintjén történnek!

A jelen pillanatban egy nem publikusnak készült, PIC16F877A-ra alapozott (és pár éve sebtiben összedobott) NAVEL-t igyekszem publikussá varázsolni, majd azt a 18F sorozatra is megvalósítani. Természetesen ezt csak akkor van értelme megtennem, ha lesz elég érdeklődés iránta.

Valami ehhez hasonlóval kisérletezett icserny kolléga az utóbbi időben. Flashforth a neve, ha jól emlékszem.

Ezt a modszert hivjak bootloadernek -- marmint hogy van egy szoftver amivel a sajat programodat feltoltheted anelkul, hogy kulon programozo kellene hozza.

Operacios rendszer viszont akkor lesz valamibol, ha az eroforrasokat az kezeli a szoftvered helyett. Ha ezt megteszed akkor visznt az alkalmazasod mar nem a vason fog futni, hanem az operacios rendszeren, azaz kotodsz valamihez ami nem biztos, hogy celszeru. Ne felejtsd el, hogy a PIC az nem szamitogep, hanem mikrovezerlo szukos eroforrasokkal es a nem kivanatos overheadek csokkentese erdekeben mindenfele piszkos programozasi trukkokkel van sokszor egy-egy firmware tele tuzdelve...



Ahogy potyo emlitette ez hasonlo ahhoz a forth nyelvu rendszerhez amit icserny probalgatott.

Amugy PIC tanulasahoz -- es ez osszes funkciohoz -- sokkal elonyosebbnek tartom a szimulatorokat, amivel nincs meg ez a nyavalya. Sajnos azonban akik szoftveres oldalrol jonnek nem ismerik ezeket az eszkozoket es valahogy nem jut eszukbe, hogy egy hardvert le is lehet szimulalni... Mar tisztelet a kivetelnek.

Szoval valoszinuleg ezek miatt nem talalkoztal meg ezzel, hiszen nem jo kulcsszavakra keresgeltel a neten.

Én ezt egy jó játéknak tartom semmi többnek.

A legújabb 16bites PIC-ek(24F, dsPIC) esetében pedig fizikailag is korlátos a módszer, mert alig ezerszer módosítható a flash területük.

De mint mondtam, jó játék, érdekes feladat. Kezdőknek bizonyára tetszik is majd, ha elkészül egy ilyen felület. Az nem gond, hogy van már Flashforth, nem biztos, hogy ugyanarra készült.

Trudnaival egyetértek, szimulátor az ami megoldja a kezdeti lépéseket. A 24F, dsPIC-ek fejlesztésekor nem is nagyon van más módszer, mert hamar cserélhetjük a százlábút!

Az ötlet jó, a kívánalmak, célok és a megközelítések azonban sokfélék. Rokon ötlet az is, amikor a firmware egy buta interpretert tartalmaz, s a PC-n futó program mondja meg, hogy mit csináljon. Így működnek az USB Bit-whacker-re alapozott egyszerű adatgyűjtők, vagy a komolyabb cégek USB adatgyüjtő kártyái.

A FlashForth annyiban más, hogy futás közben a program is továbbfejleszthető, tehát nemcsak parancsvégrehajtó, hanem parancsdefiniáló funkciója is van. Ha csak parancsvégrehajtásra használjuk, akkor nincs gond, nem égetjük a programmemóriát. Új parancs definiálásakor azonban előjön a PIC24 flash endurance kérdése. Megjegyzem, a kis lábszámú (28-44) és némelyik nagyobb lábszámú (GA008, GA108, GB108) újraprogramozhatósági száma kitűnő (min 10 000 a teljes hőfoktartományra, ami azt jelenti, hogy szobahőmérsékleten akár egy nagságrenddel jobb is lehet). A FlashForth azonban feltételezi, hogy FORTH nyelven akarunk programozni, ami nem mindig áll fenn...

Van aztán Muvium projekt is, amelyikben Java programok kommunikálnak soros vonalon vagy TC-IP hálózatba kötött mikrovezérlőkkel (socket programozás). A szabadon letölthető szoftver csomagban PIC18F2620, 452, 4620, 8720 és 8722-re van beégethető "oprendszer" (a HPC Explorer kártya tehát jó hozzá).

Valószínűleg a "rövid" bevezetőm inkább célratörő volt és nem eléggé tájékoztató jellegű, és ezért szaladtak a hozzászólók gondolatai az enyémtől eltérő - bár nem túl rossz - irányba.

A FORTH nyelvet jól ismerem, a FlashForth-nak utána néztem, és tényleg van némi hasonlóság a megvalósításban, legalább is architektúrálisan, illetve a PIC memóriájával való manipuláció tekintetében. Mint egyfajta ötletet nagyon jónak tartom, bár az enyém alacsonyabb nyelvi (leginkább gépi) szinten dolgozik. Maga a FORTH úgy 20-25 éve nagyon népszerű volt, és sok reményt fűztek akkor hozzá (a neve is utal az akkor 3. generációs nyelvek után a 4.-nek vélt programozási módszerre. Ám a szoftvereseknek helyette jött az objektum orientáltság, illetve a vizuális fejlesztői környezetek elterjedése, és elfelejtődött, leginkább a 16 bites szemléletmódjának korlátai miatt, melyen amint látom újabban némileg tovább léptek). Bár a FORTH magas szintű nyelv, és azok küzül is az egyik leghatékonyabbak közül való, mégis egy-egy jól optimalizált C fordítás gyakran le tudja körözni. Ráadásul egy sajátos (veremorientált) gondolkodást igényel, és nem is igazán beágyazott rendszerekhez való. Tehát a FlashForth - ahogy máshol olvastam is - egy nagyon ügyes kis gyerekjáték, Lego, vagy "dugdosós panel", amivel el lehet ugyan kezdeni kisérletezni (és a FORTH lélektanba belemerülni), de a HW-eseknek ez már túl magas lehet, és pl. végső működő rendszert erre én nem alapoznék.

Azonban amit én vázoltam az egyáltalán nem FORTH, semmi közös nincs a NAVEL-lel kapcsolatban vele, ráadásul az terjedelmileg is mintha nagyobb lenne és kevésbé rugalmas is.

Bootloader:
A NAVEL nem bootloader. Ám - külön modulként - természetesen ilyen funkció is hozzácsatolható, amennyiben ez a fejlesztő számára szükségesnek tünik. Leginkább a PC felöl egy .HEX fájl megadása célszerű, amit a NavelStr átfordít Flash program memóriát módosító parancssorozatra (szintén külön modulként blokkos parancsok is lehetnek a NAVEL-ban, ha a sebességigény ezt indokolja).

Operációs rendszer:
Természetesen a NAVEL-t operációs rendszernek nevezni - a részemről - egy nagyvonalú, és megmosolyogni való kijelentés. Olyannyira nem az, mint pl. a PC alaplapok BIOS-a (leginkább persze a kb. 10 évvel ezelőttiekre gondolok). Aki anno használt Commodore64-et akkor az arra való MONITOR programhoz hasonlít legjobban a működése, noha itt a kód ketté van osztva egy PC felöli bonyolultabb, és a PIC felöli - aránylag egyszerű - részre. Ez a MONITOR elnevezés érdekes módon összecseng az általunk Commodore előtti időkből származó, és a NAVEL-hez nagyon hasonló megoldásunk nevével (bár kezdetben MIKOP-nak hívtuk). Talán az írója ismerte a HT680X magyar fejlesztésű rendszert. Ez Commodore-os MONITOR a későbbi gyártású Plus4-es gépükbe alapból belekerült, hiszen a gépi kódú programozáshoz szinte elengedhetetlen valamiféle debugger segédprogram. A fejleszők ebben a pre-PC korszakban még reménykedtek az új model sikerében. Ám jött az "IBM-PC", ahol az AFD (Advanced FullScreen Debugger) segítettt ugyanígy a bithámozóknak.

A PIC az nem számítógép:
Így voltunk mi is a mikrovezérő-mentes időkben a kezdeti mikroprocesszoros panelekkel (MC6800-as), ahol jó ha volt a panelon 3KiB EPROM és 1KiB RAM. Az ilyen panelokon használtuk a MIKOP-ot, mely számomra a NAVEL őse. Szűkös erőforrások voltak, és jómagam is "mindenféle piszkos programozási trükkökkel" tűzdeltem tele a mellette futó vezérlő programot. A MIKOP (később MONITOR) csak annyit segített a végleges működés esetén, hogy onnan hívtunk meg jónéhény előre megírt, és hasznos rutint. A panel beindításakor azonban szinte elképzelhetetlen volt meglenni nélküle, hiszen mindenféle kód irás nélkül rögtön működött. Az természetes azonban, hogy időkritikus feladatok esetén a végleges rendszernél a NAVEL-ből bizonyos részeket, vagy akár az egészet ki kell tiltani.

Szimulátorok:
Nagyon helyes dolog a szimulátorok használata, hiszen nagyon sok kódrészletet be lehet rajta lőni. Gyakorlatilag egy fejlesztő számára a PIC esetében ez az egyik legfontosabb és leggyakrabban használt eszköz - már ha jól működik. Gondolom a mostaniakkal már nincs semmi baj, ám kb 15 évvel ezezlőtt a kezdeti PIC korszakban (akkor még nem volt Flash, pontosabban akkor jött ki a kisérleti 16F84), éppen a hibás szimulátor működés miatt hiúsult meg egy akkori álmom, ahol 512 szavas programból oldottam volna meg egy fényorgona vezérlést, 16 szintes szoftveres fázishasítással, mely az USART nélküli MIDI kommunkációba lett volna ügyesen beleágyazva. (Ilyen pici helyre én sem gondoltam NAVEL-t).
A NAVEL a szimulátorok után a részben belőtt programrészletekkel alkalmas a valós áramkör azonnali kipróbálására. Olyan esetekben is amikor a vezérelendő áramkör ott van a kezünkben, melyre nincs szimuláció, és ha csinálnánk is, akkor sem biztos, hogy úgy működik ahogy a leírásban van. (ez gyakori). És persze lehet NYÁK vagy forrasztási hiba is, nembeszélve a félretervezett, és buherációkkal helyben működővé pofozott HW részekről. Egyébként pedig PIC-hez ne jöjjenek nagyon jól képzett szoftveresek, akik fejből megírnak B-fa kezelésű rendező algoritmust, vagy kíválóan értenek a relációs adabázisokhoz, mert nekik gyakran egy bit beállítása is gondot okoz, és fogalmuk sincs arról, hogy mire jó pl. az AND, az OR vagy a XOR.

Igazad van, egy már működő panelen jó játéknak is fel lehet fogni.
Valamikor a röntgent is csak egy jó játéknak tartották.
A szoftveresek is jó játéknak tarthatják a szimulátort, talán azért nem becsülik meg.
Én is úgy vagyok sok dologgal, amit nem próbáltam ki, hogy csupán egy jó játék. De amint az ember ráérez az ízére...
De természetesen nem kötelező a használata, nem is kellhet mindíg, ízlés dolga is, meg akinek tengernyi ideje van a bemérésre...

A Flash memóriák lefáradása mindíg is gond volt. Emlékszem még az "inkább csak olvasható" memória elnevezésre, amikor kibírtak vagy 100 beírást. De ez technológiai probléma, és az évek múlásával egyre javul a helyzet, miközben a kapacitások meg egyre növekednek. Az első NAVEL-t PIC-re a 16F877-re csináltam, aminél szintén kb. 1000 égetés volt a korlát. De ez épp a NAVEL-nek köszönhetően nem volt komoly korlát, hisz vele csak itt-ott kellet néha egy-egy utasítást átírni, nem pedig az egész tokot újraégetni. Akkor nem igazán találkoztam olyan esettel, amikor a Flash lefáradása okozott volna problémát. Reméljük - ahogy a 877 után kijött a 877A - a 16 biteseknél is tovább enyhül ez az "áldatlan" helyzet.

Köszi a kiegészítést. Ezek mind nagyszerűek, és majd utánuk is nézek.
Az enyém teljesen HW közeli, és rugalmas. Egy HW-es talán jobban megérti.

Néhány részletesebb adat a NAVEL-ről:

(A lehetőségek nagy része - a lefordítás folyamán - külön beilleszthető, vagy teljesen kiiktatható. A lefordított NAVEL funkciói újabb fordítás nélkül(!) a felhasználói programból bővíthetők a RESET és IRQ vektorokhoz hasonló vektorok sokaságának átírásával!)

1. Beépített interrupt kezelés, beléptető és kiléptető kódokkal, benne:
- User-Before-Interrupt-Handler vektor
- User-After-Interrupt-Handler vektor
- TIMER0 interrupt lekezelés, működést jelző LED villogtatás, SW-es timer-ek
- Lekezeletlen interrupt figyelés interrupt-burst kizárással

2. Beépített RESET kezelés:
- POR, BOR, WDT-RESET, SLEEP/WAKE-UP felismerés, és hozzájuk vektorok
- DEBUG-RESET detektálás (erre a felh. program helyett a NAVEL indul)

3. Soros vonal kezelés:
- Inicializálás, Receive és Transmit kezelés
- RS485-ös lehetőség
- Debug parancs felismerés, protokoll kezelés, gyors és rövid CRC számító algoritmus
- Debug parancsok értelmezése és végrehajtása

4. User és Debug mód megkülönböztetés:
- User módban a felhasználói program fut, a NAVEL bizonyos részeit használhatja.
- Debug módban a NAVEL parancsértelmező fut, bizonyos felhasználói részek is lefuthatnak.
- NAVEL-ből átválthatunk User módba
- Felhasználói program átléphet Debug módba
- RESET-kor választhatunk melyik mód induljon

Néhány adat a NavelStr.exe kezeléséről:

- Soros kommunikációt felélesztő teszt lehetőség
- RS485 kommunikációs mód is
- NAVEL változat és konfiguráció lekérdezés
- Memória böngésző ablakok: Flash, EEPROM, RAM külön; Lista ill. terminál mód
- Memóriatartalom megváltoztatás R/W, Read Only, Write Only módok
- I/O regiszterek interaktívan - bitek név szerint, bitváltoztatás, impulzus küldés
- Program indítás adott címről (kilépés visszatérő vektoron át)
- Disassemblált programmemória kijelzés
- Assembly-szerű programszó megadás
- Memóriatartomány fájlba mentése
- Elmentett memóriatartalom PIC-be küldése
- .HEX fájl betöltés

Hát rádiótávcsövet meg elentronspektrométert már vezéreltek vele, sőt, az USA Haditengerészetének rakétakísérleteihez a Lockheed Martin által kifejlesztett rakétakövető rendszer SMART antenna tömbjének firmware-ét a FORTH inc. fejlesztette. (SMART = S-band Mobile Array Telemetry)

Tanúlságként csak magamat tudom idézni a #443233-ból:

"Én is úgy vagyok sok dologgal, amit nem próbáltam ki, hogy csupán egy jó játék..."

Inkább tartsd játéknak, minthogy Trident rakétákat lövöldözz kipróbálás gyanánt!

Erről a NAVEL-ről tudnál mutatni valami egyszerű konkrét példát? Mert az eddigiek alapján még nem nem tudom elképzelni a működését, s #443236-ben leírtak egy kicsit ijesztően soknak tűnnek!

A Muviummal is az a bajom, túlságosan komplikáltnak tűnt, úgyhogy emiatt bele sem fogtam a kipróbálásába.

Jelenleg az úraélesztésén dolgozom otthon. Kb. 3 éve nem volt a kezemben PIC és már a saját rendszeremből sem émlékszem pontosan mindenre (Murphy: "Nincs annál idegenszerűbb dolog, amikor egy programozó a saját maga által megírt kódjait igyekszik 2 hét után megérteni...").

Mindenesetre pont arra törekszem, hogy ne legyen komplikált a használata. Akkor, amikor PIC-re megírtam, gyakorlatilag csak én használtam, és ezen utóbbi célt még nem sikerült maximálisan elérnem. Ezért nem szívesen publikálnám a pillanatnyi formájában. Másrészt vannak még benne töredékesen megvalósított funkciók is, amelyeket komplettíroznom is kell, egyes dolgokat meg - a tapasztalatok alapján - már másképp gondolok, és ezeken is változtatnom kell.
De az elképzelt használati módjáról előzetes ismertetéseket szívesen közlök:

Maga a NAVEL assembly-ben íródott. Forrásnyelvi szinten van meg, és ebből kell először magunknak egy testreszabott változatot némi munkával kialakítani. Eleve több változata van a 16F és 18F sorozat különböző utasításkészlete miatt. A változatokhoz .asm kiterjesztéssel van egy-egy mintafájl, amelyet át kell vennünk, és saját NAVEL fejlesztő könyvtárunkba másolni, majd módosítani a saját környezetünk, követelményeink szerint.

Itt kell ismételten megjegyeznem, hogy a rendszerünk beindítását, tesztelését segítő NAVEL és a tényleges működtető felhasználói programunk valójában két külön projektnek tekintendő! A NAVEL-t nagyon kis számú alkalommal fordítjuk újra, és égetjük be. Mindíg a PIC-ben van, és csak finomhangolása esetén, vagy ha a terjedelmi okok bővebb vagy szűkebb változatot kívánnak, akkor nyúlunk hozzá.

A .asm fájlban assembly #define direktívákon keresztül paraméterezzük a NAVEL-ünket. Erre több okból is szükségünk van. Először is, mivel maga az .asm fájl a saját mappánkban van, meg kell adnunk az eredeti NAVEL modulok (.inc kiterjesztésű fájlok) útvonalát. A másik amivel foglalkoznunk kell a PIC órajel frekvenciája. Mivel a NAVEL általában felhasználja a TIMER0-át, illetve a soros kommunikáció miatt a Baud Rate beállítása is elkerülhetetlen, az órajel pontos értékének (és az azokból származó inicializáló konstansoknak) ismertnek kell lennie. Harmadik dologként - amennyiben használni szeretnénk ezt a fontos lehetőséget - a DEBUG/LED lábat kell megadnunk. Ezeken felül sok beállításra, paraméterezésre van még módunk, ám azok nem mindíg szükségesek, és fokozatosan érdemes velük megismerkedni. Inkább néhány szót a DEBUG/LED-ről:

Egy már működő rendszeren is nagyon hasznos, ha fenntartunk egy lábat a PIC helyes működésének jelzésére. Ez a LED a normális esetben valamilyen ütemben egy jól felismerhető villogási sorozatot ad, mely legtöbbször megnyugtat, hogy a PIC-cel nincs baj. A NAVEL vagy a felhasználói program is felismerhet bizonyos hibákat, melyeket ezen a LED-en - más villogási mintával - jelezhet. Ez a villogtatás egy egyszerű algoritmussal a megszakítást kezelő NAVEL programrészbe van integrálva, és a mintát egy bájton adhatjuk meg. A LED azt is jelezheti (javasolt!), hogy a felhasználói program (User mód), vagy a NAVEL parancsértelmezője (Debug mód) fut-e éppen. Erre a lábra a föld felé még egy nyomógombot is rakhatunk. Ezzel lehetőséget adhatunk a feljesztőprogram futása alatt arra, hogy átváltsunk Debug módra. Ez persze csak akkor történhet meg, ha érvényre kerül egy megszakítás (pl. a TIMER0, ha nem szállt el teljesen a program). A megszakításkezelő, amikor a láb magas szintű (a LED sötét), egy időre inputra vált és megnézi nics-e lehúzva a földre, mert akkor vészhelyzet van, és debug-olni szeretnénk. Szintén vizsgálva lesz ez e láb RESET után, mert ha úgy van a rendszer beállítva, hogy RESET-re a felhasználói program induljon el, akkor azt a RESET alatti földre húzással felülbírálhatjuk. Ezektől függetlenül pl. azt is megadhatjuk, hogy a WDT_RESET-re is Debug módba menjen át.

Még megemlíteném, hogy az egyes üzemmódokat, illetve beállításokat gyakran nem a RAM-ban tároljuk (a RAM elszálláskor nagyon sérülékeny és védtelen), hanem a NAVEL-ban, egyes programsorok átírásával. Ezeket én biztonsági elemeknek (biztonsági flegek, biztonsági értékek, biztonsági kapcsolók) nevezek, melyek legtöbbször RETLW utasítások (flag, érték) vagy egy GOTO kódja (kapcsoló), és a NAVEL-ban jól definiált helyekre vannak csoportosítva. Ez a technika is biztosítja, hogy a NAVEL rugalmas marad úrafordítások nélkül is.

Ha a fenti paraméterezésekkel végeztünk, akkor a fordítás és beégetés után a HW-es köldökzsinórt a PC COM1-jére (v. COMx), illetve a PIC megfelelő lábaira (RX,TX,GND) csatlakoztatjuk. Tápot adunk, és már figyelhetjük a LED villogását. A PC-n elindítjuk a NavelStr.exe programot, és máris kezdhetjük a kommunikációt.

A másik oldalról, azaz a NavelStr.exe használatáról majd egy külön hozzászólásomban értekezem.