Fórum témák
» Több friss téma |
Fórum » PIC FreeRTOS Hogyanok...
Üdv mindenkinek !
Elég régóta foglalkoztatnak a PIC mikrovezérlőkhöz kifejlesztett valós idejű operációs rendszerekkel kapcsolatos kérdések (RTOS). Aki most esetleg nem tudja, hogy miről beszélek az gondoljon bele, hogy pl a routerek nagy részében is valamilyen RTOS végzi a dolgát ezért olyan megbízhatóak. Viszont ezekben álltalában Uc linux vagy hasonló ketyeg. Elég szimpatikus a Pumpkin cég által kifejlesztett rendszer, de sajna ezt nem sikerült működésre bírnom. Találtam egy másikat ez teljesen ingyenes, ha jól olvastam akkor még fizetős projektekhez is ingyen használható és ami nem mellékes a 3 db demóprojekt működik is. Ez a rendszer MPLAB C18 alá van portolva. A kérdésem az, hogy mire kell odafigyelni egy ilyen rendszernél, merthogy elég sok paramétert lehet/kell konfigolni a megbízható működéshez. Konkrét kérdés pl.: hogy hogyan tudom meghatározni, hogy egy TASK végrehajtására mennyi időt szánhat a kernel. A freeRTOS honlapja: www.freertos.org Remélem van aki már komolyabban benne van a témában és ki tudjuk úgy vesézni ezt a kérdést, hogy mindenre találjunk választ. Egyébként is szerintem a mikroelektronikában egyre inkább előtérbe kerülnek az RTOS rendszerek.
Hát nézegettem én is, de még mindíg azt mondom, hogy a PIC mikrovezérlőket nem erre találták ki!
Én csináltam egy rendszert, amihez saját magam írtam egy rendszert, de ez sajnos nem nevezhető oprendszernek, mivel egy másik projekthez való felhasználásához igencsak át kellene írni.
Sajnos nem lehet mindent megoldani a sima programozással, amikor "szépen soronként kell végrehajtani a programot" ez nem válik be, amikor az ember már a pic határait feszegeti. Mondhatjuk, hogy térjen át ARM-ra akinek kevés a pic, de ugyebár az teljesen más, sokmindent ujra kellene tanulni, és nem kevés pénzbe kerülne, de ami fontosabb, hogy szinte sohasincs egy projektnél arra idő, hogy egy uj mikrovezérlőnek a lelkivilágával ismerkedjünk. Ezért lenne egy ilyen RTOS az arany középút, de viszont ez külső segítség nélkül nemigen elsajátíthaató, vagy csak iszonyatos befektetett energiával és idővel, ráadásul sokszor mások tapasztalata segít a legtöbbet.
Valamikor tavaly novemberben megjelent a 32 bites PIC család. Na azt már erre találták ki.
Sziasztok!
Engem is érdekel a RTOS, de sajna még csak nagyon érintőlegesen foglalkoztam vele. Vitatkoznék azzal, hogy a PIC-et nem erre találták ki. Igen! A 8 bites családnál valóban túlzás lenne az alkalmazása, de például a 16 biteseknél a 40 MPIS-es teljesítmény már megengedi a használatát. Mindamellett meg tudja könnyíteni az ember munkáját, ha egy ismertebb dologba kezd bele. Gondolva pl. az ARM processzorokra: a felépítés stabil, de bonyolult, viszont ha egy Linux fut rajta, akkor máris sokkal könnyebb kezelhetőbb lesz a programozása, minimális számítási teljesítmény rááldozása mellett. Sziasztok!
Szerintem a 18-as családtól felfelé van értelme a dolognak.
Itt a nagyobbakhoz pl könnyedén lehet külső ramot építeni, de kérdés, hogy hogy tudja, ill. tudja e egyáltalán kezelni a rendszer. 32 bites pic ? És most akkor rendeljek egy gurigával (160 db), mert a chipcad nál 0 a raktárkészlet? Idézet: „de például a 16 biteseknél a 40 MPIS-es teljesítmény már megengedi a használatát” Erre idéznék egyik tanáromtól: "két termék közül nem az a jobb, amelyik magasabb órajelen fut, hanem az, amelyik alacsonyabb órajelen tudja ugyanazt". Amit nem lehet megcsinálni RTOS nélkül, azt nem lehet azzal sem. Ez nem indok a használatára.
Potyo - Potyo!
Minek OFF-olni? A hozzászólássommal arra akartam rávilágítani, hogy a 8 bites PIC család elegendő teljesítményt nyújt kisebb/közepes feladatokhoz, de egy komplexebb, nagy volumenű dologhoz valószínűleg kevés a 10 MIPS, de főleg az, hogy mindegyik megszakítás (tekintsünk el a prioritásoktól) egy címre ugrik. Emiatt célszerű egy 16 bites kontrollert választani, meg amiatt is, hogy a RTOS egy bizonyos utasításszámot (és memóriát) elhasznál a működéséhez (ez ált. fix). Minél kisebb a számítási teljesítmény, annál észrevehetőbb a működés szempontjából, hogy a háttérben egy RTOS működik. Ezért írtam, hogy a 16 bites PIC-eknél nem jelent már akkora teljesítményvesztést a használata. Tény viszont, hogy rengeteg dolgot meg lehet csinálni RTOS használata nélkül is. Én is rácsodálkoztam amikor nézegettem az apróhirdetéseket, és láttam, hogy valakik (a www.pidsbc.fw.hu-n) megcsináltak egy PIC2550-nel egy komplett programozható PID szabályzót. És szó sem volt RTOS-ről, pedig elég komplexnek látszik! De mindössze azt akartam mondani, hogy lerövidíti a fejlesztési időt, ha az ember egy RTOS-t használ. Egységesebb a programozás menete. Talán kevesebb "regiszterszintű" művelet kell (de ennyire még nem mélyedtem bele), magasabb szintre emeli a programozást. Na, de nekem is sikerült OFF-olni egy kicsit, elnézést érte. Sziasztok! Idézet: „megcsináltak egy PIC2550-nel egy komplett programozható PID szabályzót.” Ez újdonság? több, mint10éve használunk olyan PID-es szabályzókat, amikben előszőr 16F877 volt! Nem is értem miért gondoltad, hogy ehhez oprendszer kéne??
Üdv !
Való igaz, mint szinte minden rtos nál leírják, hogy mi a minimális uC igénye, és azt is, hogy a taskoknak és alkalmazásoknak csak a memória szab határt. Meg szerintem az órajel is. Nem is mondtam, hogy nem lehet rtos élkül megoldani, csak kérdés a befektetett energia. Mint írtam én is megoldottam anélkül a feladatot, de lehet, hogy azzal könyebb lett volna ? Annyiból jobb persze, hogyha bármit módosítani kell egyből tudom, hogy hová kell belenyulni a kódban. A pic2550-el lehet hogy RTOS nélkül csinált pid szabályozót, de tuti, hogy ott figyel benne egy státuszgép (már csak az USB miatt is), ami ugyebár az RTOS elődje. Szerintem ez amúgy sem kíván RTOS rendszert mivel azt csinálja amire kitalálták PID szabályzás és kész. Viszont pl. nálam amit meg kellett oldani. SD kártyára adatrögzítés FAT fájlrendszerben, kiolvasás BlueTooth-on keresztül vagy gprs kapcsolaton keresztül. SMS -el vezérelhető feladatok, melyeket a felhasználó szabadon konfigolhat. Időkritikus jelek analóg, ill. digitális feldolgozása. Pozíciómeghatározás és távolságszámítás Geoid számítással. Röviden ennyi. Na ezt oldja meg valaki Státuszgép vagy RTOS nélkül, úgy, hogy nem veszhet el jel. Biztos, hogy meglehet de sok időt emésztene fel, hogy mindíg számolgassa, hogy vajon az a fügvény lefut e időben, vagy összeborul az egész.
Üdv!
QNX realtime kernellel foglalkozott már valaki, mi a véleményetek erről, nagyon dicsérik, nálunk mostanában lesz talán bevezetve a cégnél DSP/SMC kapcsán. QNX-ből is a neutrinoval szemezgetek.
Üdv megint! Látom nagyon pangotok, de azért irok ide:o)
ezen a linken talalhato 2 konyv erdekelne, hogy valakinek megvan-e esetleg, es eltudna-e nekem kuldeni?  nagyonagyonnagyon halas lennek .o) QNX könyvek
Végülis megvette a cég ezt a két könyvet, meg az IDE fejlesztő környezetet + magát a real time op. rsz-t, ha valakit érdekel annak tudok adni cuccokat
Bár én a mai napig szkeptikus vagyok a kontrolleres operációs rendszerekkel, azért érdekelnének azok a cuccok
Igen, tulajdonképpen engem is.
djszapi! Még is milyen cuccok vannak és milyen formátumban és méretben?
A real-time operációs rendszerek (RTOS) lényege az, hogy egy eseményvezérelt és többfeladatos környezetben ütemezze a feladatok futását, kezelje a rendszer erőforrásait, s jól definiált rendszerhívások segítségével segítse a feladatok közötti üzenetváltásokat, szinkronizálási vagy kizárási feladatokat.
Feladattól és a körülményektől függően ez lehet egyszerű vagy bonyolult rendszer. Eugen Huttony VELOOS (Very Low Overhead Operating System) rendszere például egy roppant egyszerű, assembler nyelven írt program, melynek rendszermagja kb. 200 programutasítást és 20 bájtnyi adatmemóriát igényel. Egyszerű mintapéldái 12F675 és 16F690 mikrovezérlőkön futnak. Szintén használható a PIC mikrovezérlőkhöz a Hi-Tech Salvo RTOS, melynek Lite változata ingyenesen használható. A PIC 12/14/16/17 mikrovezérlőkhöz való változat a HiTech PICC C fordítójával használható. Linkek: http://www.htsoft.com/downloads/demos.php http://www.pumpkininc.com/
Na igen.
Pontosan a SALVOT szerettem volna használni, de azt az egyet nem sikerült működésre bírni. A processzor típusok és libraryk összefüggése nem egyértelmű és a manual is 1000 éves mplab-hoz van.  Idézet: „A processzor típusok és libraryk összefüggése nem egyértelmű” Jól eldugták az infot, az biztos! Erről a címről lehet letölteni a leírásokat. A Salvo 3.2.3 User Manual-on kívül kell a megfelelő fordítóhoz tartozó Salvo Compiler Rererence Manual is. Ez utóbbiban magyarázzák el, hogy mit jelent pl. az spf42Cab.lib elnevezés. Ebből a 42C utal a PIC típusára, s van hozzá egy szép táblázat is. (Nem tudom, mi a teendő, ha az illető PIC nem szerepel a táblázatban? Lehet, hogy a "legközelebbi rokon" választása működik?) A név végén az 'a' és 'b' jelölés pedig az RTOS konfigurációra és változatra vonatkozik. A kipróbálásig még nem jutottam, mert a Hitech PICC Lite fordítóm Linux alá van telepítve, a Salvo exe installálója meg Windows alá települt. Erről ennyit...
PIC18F vezérlők és Microchip C18 fordító esetén kicsit más a helyzet:
például a sfc18sna.lib név mit jelent? s : Salvo f : freeware library c18 : Microchip C18 fordító a név eleje tehát fix. A név végi három karakter: 1. Memória model s: small (<=64 kB programmemória) l: large (>64 kB programmemória esetén) A large model értelemszerűen minden modellre jó, de fölösleges pazarlás, ha a program mérete nem haladja meg a 64 kilobájtot (32 kiloszó). 2. Objektumok címzése f: far - a mutatók 16 bitesek n: near a mutatók 8 bitesek 3. Konfiguráció m: csak multitasking e: multitasking és események kezelése d: multitasking és késleltetések kezelése a: multitasking, késleltetés és események t: multitasking, késleltetés, események, task várakozás timout-tal A 't' tehát egy tutti-frutti library, a többiből ilyen-olyan szolgáltatás hiányzik.
Sikerült lefordítani és lefuttatni az első demót (ex1) syse változatban, azaz MPLAB és Microchip C18 fordító felhasználásával.
1.Először a salvo-lite-pic-3.2.3.exe telepítőt kell lefuttatni (c:\salvo könyvtárba telepítettem). Ebben 2003-as őskövületek vannak, ezzel a mostani C18 fordító és az MPLINK nem kompatibilis. Éppen ezért: 2. Le kell cserélni a c:\salvo\lib\mcc18 könytárban levő őskövületeket a salvo-lite-pic-3.2.3-d.zip állományban található (2006-os dátumú) lib-ekre. 3. Ezek után megnyitható a c:\salvo\ex\ex1\syse könyvtárban található ex1lite projekt, és több-kevesebb kínlódással lefordul. Project/Build Options/Projects menüpontban Include search path-nak a c:\salvo\inc mellett a c:\salvo\ex\ex1\syse is kellett. Lib search path-nak csak az MCC18\lib-et kellett megadni. A linker állományt is keresni fogja, ezt az MCC18\lkr könyvtárban mutattam meg neki, hogy hol van. Szimulátorral futtatva a B port alsó felének matatása figyelhető meg, lásd a mellékelt ábrán.
De ha már C18 akkor PICOS18 az legalább újabb.
Azt néztem a salvo-nál, hogy a legujabb verzióban is azok az őskövületek vannak, magyarul lényegileg nem fejlődik a stuff. Igazábol a problémák ott kezdődnek, hogy alapfogalmak ismerete hiányzik. pl.: Mi az a SCHEDULER Vagy mi az az YELD és társai. Mert amíg ezeket nem tudom, addig csak sötétben tapogatózok és lehet, hogy tudatlanságom váratlan hibákba torkollik, amiket nem tudok kezelni. A tömény angol leírásból meg nem nagyon derülki egyértelműen (nekem), ezen funkciók jelentései. A legtöbb leírás úgy fogalmaz, mintha ezen fogalmakat már az általános iskolában megtanították volna és mindenkinél alaptudás lenne egy kernel funkcióinak ismerete 
Nem volt még időm/kedvem elmerülni a Salvo részleteiben, így nem tudok mindenre kimerítően válaszolni. Mindesetre a scheduler az a része a rendszernek, amelyik a feladatok (tasks) kapcsolgatását végzi. Erről most elég annyit tudni, hogy a főprogramnak végtelen ciklusban az OSSched() függvényt kell hívogatnia.
A Salvo nem preemptív, hanem kooperatív típusú, ami azt jelenti, hogy a felüyelőprogram nem fogja megszakítani a feladatok futását, hanem azoknak önként és dalolva kell visszaadniuk a vezérlést. Tehát kb. ugyanolyan logikával kell a feladatokat megírni, mint az interrupt rutinokat.... Az OS_Yield() (ha jól értem) egy olyan lehetőség, amellyel a taskok vissza tudják adni a vezérlést. Kicsit tehát olyan XP előtti windowsos multitasking feelingje van: bármelyik program együtt tud futni a homokórával, amelyik megakadályozza, hogy újabb programok elinduljanak. 
Hát akkor ilyen kooperatív cuccot én is írtam már, egy riasztó/nyomkövető szerűségbe, ahol a rutinokat nem szakítja meg semmi, hanem visszaadja avezérlést magától.
Ezt is egy megszakításszál vezérelte és a main ban végtelen ciklusban futott a tskokat meghívó rutin.  Magyarul akkor ez olyan win3.1 szintű (ott is, ha egy task befagyott akkor minden befagyott )Hát akkor inkább írok státuszgépet és azt legalább átlátom, hogy mikor mit csinál.
Ugyebár megint kijelentkezett a fórumból....
A végéről lemaradt ez: Van egy e-könyvem (angol) ami kivesézi a-z ig ezeket a multitaskos cuccokat lépésről lépésre, de hát ugye angol... Idézet: „Hát akkor inkább írok státuszgépet és azt legalább átlátom, hogy mikor mit csinál.” Ezt mondom én is. Felesleges eröltetni ezeket az OS-eket kontrollerekre. Rendesen meg kell írni a programokat, akkor nem kell OS. Ez nem számítógép, amira bárki bármikor bármit felrakhat, futtathat...
[szatirikus fel-offtopic]
Latom, hogy tobben lekicsinyeltek a 8 bites processzorokat oprendszer kapcsan. Nalunk a cegnel bankkartya elfogado terminalokban volt sokaig Z80, hard realtime (fix 10msec idoszeletek) oprendszerrel, multiprocess environmenttel, 32kB lapozott memoriaval, az ossz mem 1.5 MB battery backupolt SRAM volt. Ja es assemblyben programozgattuk... Az eletciklusa vege fele persze mar megjelent a C atirata is az egesznek az assemblyben programozni tudo emberkek szamanak csokkenese miatt. Az eredmeny a programok meretenek megugrasa es sebesseguk drasztikus csokkenese lett. Emiatt tert at a ceg ARM7/9 -re, C-re es C++-ra, Flash/SDRAM kombinaciora. Jol el lett komplikalva es most sem tud tobbet, mint a regi Z80 asm-es rendszer Na jo, van ethernet/gprs csatlakozasi lehetoseg es az RSA kriptografiat nem HW koprocesszor, hanem az ARM nyomja izombol, mas kerdes, hogy amikor meg a Z80 futott, a HW koprocink magasabb RSA kulcshosszon lenyomta a 32 bites altalanos processzorokkal kriptografalo konkurrenciat... Szoval agyuval verebre, es most mar C++ programozok is tudnak kodot bonyolitani (hulyesegeket irni) a platformra.[/szatirikus fel-offtopic]
Nem az a lényeg, hogy ki írja meg, hanem az, hogy minimális erőfeszítéssel kész legyen, és jól működjön.
A "gyári" RTOS lényege az, hogy bizonyos dolgok (az ütemező, a taskváltásokkal járó adminisztráció, a taskok közötti kommunikáció és szinkronizáció) márkészen vannak, ki vannak dolgozva. Ha ezek illeszkednek a feladatohoz, akkor könnyen és gyorsan haladsz a fejlesztéssel. Ha viszont lépten-nyomon korlátokba ütközöl, akkor vagy mást kell keresni, vagy megírod magad. Nálam is van kéznél egy-két angol nyelvű E-book. Ilyen pl. a Real-time concepts for embedded systems, ez általánosságokban beszél. De a Designing Embedded Systems with PIC Microcontrollers - P.rinciples and applications c.könyv 19. fejezete kifejezetten a Salvo-ról szól. Idézet: „De ha már C18 akkor PICOS18 az legalább újabb.” A honlapjukon a NEWS rovatban bő kétéves a legfrisebb hír. Ez nem sok jóval kecsegtet. A legfrissebb bétaverziós kiadás az MPLAB 7.62/C18 v3.12 verziót emlegeti. Ennél nagyobb bajnak látom azt, hogy ezt kizárólag a PIC18-ra fejlesztik (vagy csak fejlesztették?). Ha "kinövi" az ember, akkor kereshet mást a 16 vagy 32 bites MCU-hoz. Összehasonlításul: pl. a Micrium uC/OS-II támogatja a PIC18, dsPIC30, PIC24, dsPIC33 és a PIC32 MCU-t is. Igaz, hogy nem ingyenes, igaz, hogy a PIC18-hoz letölthető verzió 2002-es(sic!!!!) dátumú (tehát a PIC18-as gyakorlatilag már nem támogatott...).
Nézegettem néhány RTOS demót, s megnéztem, hogy melyik mennyi memóriát fogyaszt. Bár a számok direktben nem összehasonlíthatók, némi tanulságot leszűrhetünk belőle.
Salvo Lite, a már korábban említett ex1/syse mintaprogramja egy 18F MCU-ra fordítva MPLAB+C18. Ez egy minimális program, csak időzítés, késleltetés, eseményjelző-kezelés és portbitek bilegtetése van benne. Programmemória: 1354 utasítás (2709 bájt) RAM: 314 bájt Ne kérdezzétek, hogy az 1354 szó miért 2709 bájt! Nyilván a 13-as nemhasznált...  -------------------------------- uC/OS-II Ez ugyan fizetős, de letölthető "for education and peaceful research...". Van Explorer 16-ra portolt demo programja (PIC24/dsPIC33), ezt próbáltam ki. Programmemória: 17167 szó (ez háromszor ennyi bájt!) RAM: 6658 bájt Mindezekért kapunk egy látványos Knight Rideres futófényt, kiírásokat az LCD-re, s a PC-vel is kommunikálna a soros porton (van hozzá egy demo alkalmazás). Sajna, nincs soros portom... Szóval ez egy jóval komplikáltabb demo, de maga az RTOS is bonyolultabb, és komolyabb, mint a Salvo. --------------------------- ThreadX ez is fizetős, s a letölthető demó csak bináris könyvtár, hasonlóan a Salvo Litéhez. Állítólag nagyon elterjedt, de nem a Microchip vezérlőin. Mintegy mellékesen van port a PIC24, dsPIC33 és PIC32-höz. Ennek a demója is elég minimális: 8 task fut benne (bár itt szálakról beszélnek task helyett), s a taskok közötti kommunikáción és szinkronizáláson csak számlálókat növelgetnek. (Jut eszembe: a letölthető bináris demóverzió max. 10 task futását engedélyezi...) PIC24HJ256GP610-re fordítva: Programméret: 6824 szó (20472 bájt) RAM: 1686 bájt. Hát mit mondjak? A demóprogram nyújtotta csekély élvezeti érték elég sokba került... Ettől eltekintve, a Micrium uC/OS-II-höz hasonlóan ez is komoly rendszernek látszik.
Hát 1354*2=2708
Mert 16 bites a hex file nem ? |
Bejelentkezés
Hirdetés |
