PlipBox a obsługa modułów ethernet

Okazuje się, że PlipBox z założenia miał działać nie tylko na module opartym o ENC28j60, lecz także innych. Obsługa wyboru modułu została zrobiona w sposób dość ciekawy, ale nie będę psuł niespodzianki. Przeanalizujmy sobie fragmenty kodu.

Załóżmy, że natknęliśmy się w kodzie na funkcję sprawdzania, czy przyszła do sieciówki nowa ramka Ethernet:

Ciekawe jak działa funkcja pio_has_recv() ? Spójrzmy na jej kod:

Okej, mamy wrapper. Co znajdziemy dalej?

I tu się zaczynaja spaghetti. Wczytywany jest wskaźnik na właściwą funkcję has_recv_f() , której adres został zapisany w ROMie pod adresem pd->has_recv_f . Struktura pd  jest podawana w argumencie, a jest to nic innego jak zmienna globalna cur_dev:

No dobra, ale gdzie jest wartość tej zmiennej? Cierpliwości:

Czyli sama jej zawartość również jest wczytywana z ROMu. Powoli zaczyna się klarować sens takiego działania:

Gdzie pio_dev_enc28j60  jest inicjalizowaną strukturą w ROMie zawierającą właściwie wskaźniki na funkcje. Czyli mamy tablicę wskaźników na struktury opisujące interfejs z danym urządzeniem peryferyjnym, wypchane po brzegi kolejnymi wskaźnikami na funkcję. Hura!

Co o tym myśleć?

Cały system miał na celu dodanie do firmware’u supportu dodatkowych modułów sieciowych. Wyszedł potworek, który wprowadza niepotrzebny narzut do prędkości działania kodu, zaśmieca ROM i skutecznie unieczytelnia kod.

Taką decyzję projektową można tłumaczyć chęcią pisania kodu multiplatformowego, ale przecież istnieje wiele innych rozwiązań – chociażby nieśmiertelne #ifdef , które inkludują odpowiedni kod w zależności od flag kompilacji. Oszczędzimy przy tym również cenne miejsce pamięci mikrokontrolera, bo we wsadzie będzie znajdować się tylko to, co niezbędne. Pojawi się wtedy jeden minus, bowiem na każdą konfigurację wsad AVRa trzeba zbudować oddzielnie. Pytanie – czy jest to aż tak straszne, zwłaszcza że sam autor zamieszcza różne wsady dla różnych wersji płytki bazowej z mikrokontrolerem?

Sam system wyboru modułu chyba jednak warto zapamiętać – może się przydać w jakichś przyszłych, bardziej rozbudowanych projektach. A tymczasem z kodu go wywaliłem – oprócz poprawy czytelności zyskałem na tym również ćwierć kilo flasha i 3 bajty RAMu – to ostatnie najcenniejsze przy obecnym zapełnieniu około 80%.

This entry was posted in AVR, PlipUltimate and tagged , , , , . Bookmark the permalink.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.