eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingprintf i wielozadaniowosc (MicroC/OS-II) › Re: printf i wielozadaniowosc (MicroC/OS-II)
  • Data: 2009-09-29 16:47:34
    Temat: Re: printf i wielozadaniowosc (MicroC/OS-II)
    Od: "Pszemol" <P...@P...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    "Zbych" <z...@o...pl> wrote in message news:h9tc37$135h$1@news.mm.pl...
    > Pszemol pisze:
    >
    >> gdy wątek o wyższym priorytecie nie ma nic do roboty i czeka na
    >> zdarzenie.
    > [...]
    >> Otóż co widzę, to że na wyjściu generowanym przez tą funkcję fprintf
    >> (strumień znaków RS232, "plikiem" dla fprintf jest port szeregowy)
    >> widzę że wątek o niższym priorytecie wchodzi z butami w linię tekstu
    >> wątka o wyższym priorytecie
    > [...]
    >> Czy ktoś mógłby mi to wytłumaczyć?
    >
    > Żeby to dobrze wytłumaczyć to trzeba zobaczyć jak to jest
    > zaimplementowane. Szklana kula mówi tylko, że wątek o wyższym priorytecie
    > oddaje czas innym wątkom, bo czeka na zwolnienie miejsca w buforze
    > nadawczym RSa. Przy czym nie masz żadnej gwarancji, że po zwolnieniu
    > miejsca pierwszy do RSa dobierze się wątek o najwyższym priorytecie. Żeby
    > wiedzieć co się dzieje to trzeba by na osobnym kanale wyrzucać kiedy i
    > jakie wątki są uruchamiane.

    To jest oczywista oczywistość, że wątek o priorytecie 1 czeka na port
    RS i oddaje sterowanie :-) Mnie interesuje jak to się dzieje, że w czasie
    gdy task 1 oddał sterowanie task 4 lub 7 był wstanie trzy razy wysłać
    linię znaków do RS'a trzema osobnymi wywołaniami fprintfa...

    Tu masz przykład:

    "Barrier 0: s:14 M: c5aa5Barrier 4: handling legacy sensor readings
    (time:1607)
    Barr 4: Decrement counter (26) for legacy sensor (time:1607)
    Barrier task 4, 'unknown' - wait one dev delay increment... (time:1608)
    , M: 28521, M: 8b227, M: eddfc, M: 50b03, M: b365c, M: 223b1, M: 66cf0"

    To wyżej to był efekt 4 osobnych wywołan funkcji fprintf:

    task1 (barrier 0) zrobił najpierw to:

    fprn(probe_out, "Barrier %d: s:%02ld M:%6lx, M:%6lx, M:%6lx, M:%6lx,
    M:%6lx, M:%6lx, M:%6lx\r\n",

    i w trakcie gdy utknął w tej linii czekając na RSa task 5 (barrier 4) zrobił
    to:

    fprn(barr_out, "Barrier %d: handling legacy sensor readings
    (time:%ld)\r\n",

    potem to w zupełnie innym miejscu kodu:

    fprn(barr_out, "Barr %d: Decrement counter (%ld) for probe #%d
    (time:%ld)\r\n",

    i za moment to:

    fprn(barr_out, "Barrier task %d, '%s' - wait one dev delay
    increment... (time:%ld)\r\n",

    w czasie gdy task 1 wisiał sobie i czekał na zwolnienie RSa...


    Tak czy inaczej muszę przerobić to aby zostało to w kodzie na dłużej.
    Chyba zrobię nowy task o najniższym priorytecie który zajmie się
    odbiorem tekstów od tasków roboczych o wyższych priorytetach
    i wstawianiem tych tekstów do portu szeregowego...

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: