RTOS
Rancz Lajos
csiga at fosch.com
Mon Sep 10 16:09:32 CEST 2007
Helló!
Fuzesi Arnold wrote:
> List file: Kiadja, kiadja, csak akinek két anyja van szamolja ki az...mikor
> esik be egy IT melyik n-edik szintu subrutin hivas közben.... :)
>
A szubrutinhívást össze tudja számolni memória szerint. Ehhez kell
hozzáadni az IT memória igényét.
> A PC-je az AVR-eknek alapvetően word-os nem? Igy m128-nal a teljes
> cimterulet subrutinhivaskor elfer a stack-en egy 16 bites cimkent, illetve
> ugraskor eleg egy 16 bites operandus. (csak a LPM, SPM utasitasnal kell a
> RMAPZ vagymi...legalabb is bootloader irasból ez rémlik)
> Gondolom ezert nincs EICALL, EIJMP... csak a mega256-nal.
>
> Többiek, aki intenzíven asm-ezik, hogyvanez?
>
Igazad van, az AVR Instruction Set szerint 128k-ig oké az alábbi részlet
pxPortInitialiseStack függvényből:
/* The first part of the stack is the hardware stack. Place the start
address of the task on the hardware stack. */
usAddress = ( unsigned portSHORT ) pxCode;
*pxTopOfStack = ( portSTACK_TYPE ) ( usAddress & ( unsigned
portSHORT ) 0x00ff );
pxTopOfStack--;
usAddress >>= 8;
*pxTopOfStack = ( portSTACK_TYPE ) ( usAddress & ( unsigned
portSHORT ) 0x00ff );
pxTopOfStack--;
128k felett már a hármas kiírás kell.
Üdv,
Lajos
>
> A.
> ----- Original Message -----
> From: "Rancz Lajos" <csiga at fosch.com>
> To: <elektro at tesla.hu>
> Sent: Monday, September 10, 2007 2:13 PM
> Subject: Re: RTOS
>
>
> Helló!
>
> Fuzesi Arnold wrote:
>
>> Jogos. Piszok nagy lenne az overhead... :)
>> Monitor resze (ha van) az OS-nek nem csinal stack kihasznaltsag elemzest?
>> Vízjelesdivel szépen megoldható lenne...
>> Piszok gyorsan elfogy így a ram, ha az ember nagyvonaluan osztogatja a
>> stack-et.
>>
>>
> Hát nem kell nagyvonalúan, csak körbe kell nézni az IAR által generált
> listafájlokban, hogy mi a hívási mélység, és mekkora a lokális változók
> mérete. Az kiadja a két stack méretét :-)
>
>> Kézzel jtag-al nézegetni meg kicsit fapados hogy melyik stack meddig lett
>> "összepocsékolva"... :)
>>
>>
> Hát monitor sajnos nincs benne, de bármikor megoldható elvileg ha az
> "idle" taszkva beleteszel egy figyelést
>
>> Mega2560 a data területet ugyan úgy 16 bitesen címzi mint a többi avr nem,
>> miben más a stack kezelés?
>> Nem értem...
>> Jahogy a return address stack...
>> Nezegetem, a mega2560-nak van plusszban EICALL, EIJMP utasitasa pl a
>> mega128-hoz kepest...hm.
>> Jahogy word-ösen értendők a címek...aham....ezert nem kell a m128-hoz.
>> Ha jol latom m128-nal akkor nem kell semmit molyolni, azzal menne egyből
>> az
>> OS. Jól látom?
>>
>>
> Sztem nem. Mivel a 128k az nem fér bele két bájtba, ezért sztem bele
> kell nyúlni a port.c-be, de csak két helyen.
>
>> Rendes kulturalt semaphore megoldasa van amúgy?
>> Deadlock stb eliminálásával meg minden? (várakozó taszk felhúzza amire
>> várakozik taszkot a sajat prioritására?)
>>
>>
> Ezt nem értem :-) A várakozó taszk elmegy aludni, addig amíg vár, addig
> a többi taszk fut, de mindenki a saját proiritásán, de a várakozó taszk
> processz idejét feloszlik a prioritások arányában a többi közt.
>
>> Interruptok is taszkként futnak? Gondolom igen, mert ha nem, akkor nem
>> beszelhetünk RTOS-ről...
>>
>>
> Nem, az interruptok interruptként futnak, nem taszkként. Sztem ez kicsit
> jobb megoldás mint külön taszkként. RT Linuxban (Xenomai) használtam
> IRQ-t taszkként, hát nem voltam tőle hasra esve. Pont a realtime jellege
> veszett el, az átlagos válaszidő 4-5 us volt(!!) de ez néha felment 4-5
> százra is :(
>
>> Vagy megkötés van az interruptok futásidejére és csókolom?
>>
>>
> Nincs megkötés, de ezt alapvetően nem így kell megoldani. Elvileg az
> interrupt arra való, hogy az adatokat begyűjtsd vagy vmi nagyon egyszerű
> logikát megoldj. Pl. egy ADC IT a digitalizált adatokat belenyomja egy
> queue-ba és egy realtime taszk pedig feldolgozza.
>
>> Pfú, sok a nyitott kérdés hogy egészében lássam.
>> Nnna, holnap, holnaputan belemélyedek rendesen. Addig befejezek vmit....
>>
>> A.
>>
>>
> Üdv,
> Lajos
>
> -----------------------------------------
> elektro[-flame|-etc]
>
> -----------------------------------------
> elektro[-flame|-etc]
>
More information about the Elektro
mailing list