Witam,
Chciałem spytać Was, nieco bardziej doświadczonych programistów o sposób programowania uC, gdy program główny jest dość skomplikowany i zależy od wielu sygnałów. Dla ustalenia uwagi załóżmy, że uC ma współpracować m.in. z modułem radiowym CC1100 (podłączonym przez SPI) oraz niekiedy z modułem Ethernet (podłączony do USART) Główne zadania programu to dostęp do medium radiowego (a'la CSMA/CA), analiza ramek radiowych (różnych-różnistych - zgłoszenia, wiadomości sygnalizacyjne, wiadomości tekstowe, głos) i reakcja na nie.
PODEJŚCIE 1. Do tej pory (w innych projektach) robiłem tak:
- Procedury obsługi przerwań możliwie najkrótsze (odczyt danych z peryferiów, zapis do bufora w pamięci, pobieżna analiza i ustawianie flag - np. FRAME_COMPLETE dla programu głównego).
- Program główny po stwierdzeniu flagi FRAME_COMPLETE wywoływał funkcję Analiza, która ustalała protokół, konkretne znaczenie ramki, ustalając kolejne flagi "wyższej warstwy" (np. RECIEVED_CTS), które to flagi brane były pod uwagę w głównym programie. Coś w stylu (pseudokod dla wysyłania ramki w a'la CSMA/CA):
[IRQ] ... Zapisuj bajty do bufora if (ostatni bajt) then FRAME_COMPLETE ... reti
[MAIN] ... if (FRAME_COMPLETE) then FrameType = Analiza(bufor);if (Stan == RTS_SENT and FrameType == CTS_RECIEVED and ChannelFree) then Send(data); Stan = DATA_SENT; else if (Stan == DATA_SENT and FrameType == ACK_RECIEVED and ChannelFree) then Stan = IDLE; i tu inne skomplikowane przejścia, zwłaszcza gdy np. wystąpią timeouty ...
[Analiza] ... if (cośtam) then FRAME_TYPE = CTS_RECIEVED; ...Zaletą jest fakt, że program główny zawsze może zareagować niemal na wszystko. Wady - komplikacja warunków (kilka nałożonych na siebie diagramów stanów: protokołów będzie kilka, typów ramek ok. 20-30) i ogólnie wymięknąłem rozpisując program główny.
PODEJŚCIE 2. Czy nie byłoby grzechem pisanie procedury nadawania ramki po prostu jako funkcji: [SendFrame] Send(RTS); WaitFor(CTS_RECIEVED); if (Timeout) then return ERROR; Send(data); WaitFor(ACK_RECIEVED); if (Timeout) then return ERROR; RETURN OK;
Zaletą jest klarowny oczekiwany przebieg programu i uproszczenie głównego programu. Problemem na pewno są funkcje WaitFor(*), podczas których program jest obojętny na wiele innych sygnałów (np. pojawienie się ramek innych typów, flagi ustawiane przez procedury innych przerwań np. USART). Moim zdaniem można rozważyć w ciele WaitFor sprawdzanie niektórych warunków(flag). Jakie macie sposoby na programowanie uC obsługujących protokoły, muszących brać pod uwagę wiele flag? Dziękuję za wszystkie odpowiedzi, wskazówki, uwagi. Mam nadzieję, że nie zamąciłem zbytnio.