W dniu 2012-05-12 12:19, Jacek Domański pisze:
> W dniu 12.05.2012 11:24, Michał Lankosz pisze:
>> W dniu 2012-05-12 11:02, Jacek Domański pisze:
>>> W dniu 12.05.2012 09:18, Michał Lankosz pisze:
>>>> W dniu 2012-05-11 23:00, Jacek Domański pisze:
>>>>> Moja koncepcja wykorzystania maszyn stanów jest inna niż w Quantum,
>>>>
>>>> A coś bliżej?
>>>>
>>>> Michał
>>>>
>>> Oni wymyślili koncepcję, że w programie istnieje coś w rodzaju obiektów
>>> opisanych ich wszystkimi możliwymi stanami (tzw. event driven
>>> programming). I od tej strony wyszli.
>>> Mnie natomiast interesowało wykorzystanie maszyn stanów do podziału
>>> czasu pracy procesora - coś w rodzaju pracy równoległej, współbieżnej.
>>> Moje maszyny zatrzymują się w stanach oczekiwania np. na dostęp do
>>> peryferium czy skończenia transmisji, a w tym czasie wykonywane są inne
>>> równoległe zadania. Jeżeli dostęp się zwolni czy dane się wyślą, maszyna
>>> przechodzi do następnych stanów lub kończy swój bieg, jeśli już wszytko
>>> zostało wykonane (wchodzi w stan 0).
>>>
>>
>> Dziękuję za odpowiedź. Zastanowiło mnie tylko, czy taka zmiana sposobu
>> 'zaprojektowania' programu nie wprowadza więcej zamieszania niż
>> 'tradycyjny' RTOS. Czy ta maszyna stanów nie będzie się na bardzo
>> rozrastać i komplikować przy niezbyt skomplikowanych projektach.
>>
>> Michał
> Moim zdaniem jest to rzeczywiście bardziej skomplikowane - autor Quantum
> wprowadził własne narzędzia do generowania kodu w C, żeby ułatwić proces
> pisania i ogarnięcia tematu :-)
> Ja póki co testuję tą koncepcję, ale nie jestem przekonany, że jest ona
> lepsza niż RTOS.
> To się okaże.
> Na pewno trzeba zmienić sposób myśłenia o programie, co nie jest łatwe -
> zwłaszcza na początku :-)
>

Być może przyjdzie mi się temu bliżej przyglądnąć. Dziękuję za informację.

Michał