tAvrLib

Aktualna wersja: 1.0.1 (06.12.2009)

URL: tAvrLib.wasilczyk.pl

Autor: Tomasz Wasilczyk

• O projekcie
• Zasoby (download)
• TODO (lista zadań do realizacji)
• Changelog (co nowego)
• Najczęściej zadawane pytania
• Zdjęcia

O projekcie

Biblioteka tAvrLib jest zbiorem funkcji przeznaczonych dla mikrokontrolerów AVR, z nastawieniem na obsługę urządzeń peryferyjnych. Kod jest udostępniany na zasadach licencji GNU LGPL v3 (szczegóły w dokumentacji).

Aktualnie biblioteka tAvrLib obsługuje następujące peryferia:

• wyświetlacz alfanumeryczny HD44780:
  • praca w trybach 4bit i 8bit,
  • możliwość obsługi flagi zajętości,
  • możliwość dowolnego przypisania wyprowadzeń (tylko w trybie 4bit),
  • przystosowany do wszystkich rozmiarów wyświetlaczy (również 4x40, posiadającego dwie linie E),
  • możliwość związania ze standardowym wyjściem (można używać funkcji takich jak printf(), a w trybie obsługi flagi zajętości działa też przewijanie ekranu po napotkaniu końca ostatniego wiersza),
  • biblioteka zawiera też polski zestaw znaków (z obsługą kodowań UTF8, ISO8859-2 i CP1250),
• ekspander portów I₂C PCF8574.

Ponadto tAvrLib zawiera funkcje ogólnego przeznaczenia:

• magistrala TWI (I₂C): obsługa sprzętowa.

Założenia projektu:

• dostarczenie kodu możliwie dobrej jakości, udokumentowanego i uniwersalnego,
• nie powinna zachodzić potrzeba modyfikowania plików źródłowych przez użytkownika (wszelka konfiguracja następuje przed dołączeniem plików nagłówkowych biblioteki) – pozwala to zachować spójność kodu w różnych projektach,
• uzyskanie namiastki hermetyzacji – podział nazwenictwa funkcji prywatnych i publicznych (prywatne zaczynają się od podkreślenia),
• implementacja funkcji w bezpiecznych wersjach (np. pozwalających uniknąć błędu przepełnienia bufora).

Zasoby

• tAvrLib-1-0-1.tar.gz: kod źródłowy biblioteki, dokumentacja, przykładowe programy.
• Dokumentacja online: opis funkcji, przykłady użycia, schematy połączeń – polecam.

TODO

W kolejnych wersjach biblioteki planuję wprowadzenie następujących zmian:

• obsługa wyświetlaczy graficznych oraz interfejsów dotykowych.

Changelog

• 1.0.1 (06.12.2009): rozszerzenie możliwości sterowania HD44780 (obsługa standardowych sposobów kodowania polskich znaków – UTF8, ISO8859-2 i CP1250, interpretacja znaku NULL w funkcjach wyświetlających ciągi tekstowe, komunikacja w trybie 8bit i z odczytem flagi zajętości, dodanie możliwości przewijania ekranu, optymalizacja kodu i zwiększenie zgodności z dokumentacją sterownika).
• 1.0.0 (29.11.2009): pierwsza publiczna wersja biblioteki. Zawiera funkcje do obsługi wyświetlacza HD44780, ekspandera portów PCF8574 oraz TWI (I₂C).

Najczęściej zadawane pytania

Dlaczego jest tu tak dużo zbędnych funkcji? Czy taka biblioteka nie zajmie dużo więcej miejsca, niż rozwiązanie dedykowane?

Biblioteka ta została napisana w taki sposób, aby kompilator mógł sam, automatycznie usunąć zbędny kod. Dzięki temu w skompilowanym projekcie nieużywane funkcje nie powodują absolutnie żadnego narzutu pamięciowego.

Dołączanie kodu w plikach *.c do plików nagłówkowych jest nieprawidłowe / nieeleganckie, czy biblioteka zostanie poprawiona?

Jest to niestety pewien kompromis. Przygotowując założenia projektu rozważałem trzy rozwiązania:

• dołączanie zarówno do programu użytkownika, jak i kodu biblioteki tego samego pliku nagłówkowego (tak się robi zazwyczaj w projektach na PC),
• jak wyżej, ale wydzielając każdą funkcję z każdego modułu do osobnego pliku źródłowego (tak jest zrealizowana biblioteka avr-libc),
• dołączenie kodu funkcji razem z plikami nagłówkowymi.

Pierwsze dwa rozwiązania nie pozwalają jednak na konfigurację biblioteki za pomocą makr z zewnątrz. Proszę zwrócić uwagę, że dołączane pliki nagłówkowe są częścią biblioteki, a nie jej konfiguracji (i nie powinny być modyfikowane przez użytkownika). Na komputerach PC konfiguracja przebiega przez inicjowanie w pamięci RAM, której jednak na mikrokontrolerach brakuje. Drugie rozwiązanie, mimo że jest lepsze (pozwala w prosty sposób decydować, które fragmenty biblioteki dołączyć), jednak wymaga umieszczenia fragmentów konfigurowalnych w plikach nagłówkowych (np. w avr-libc, funkcja _delay_ms() z pliku util/delay.h). Takie rozwiązanie sprawdza się w przypadku biblioteki standardowej, jednak jeżeli przychodzi do obsługi peryferiów, konfigurowany kod zaczyna mieć znaczny udział w pliku nagłówkowym – możemy wtedy otrzymać kod przypominający trzecie rozwiązanie, jednak odznaczający się znacznym bałaganem (część funkcji będzie zaimplementowana w jednym pliku, część w drugim).

Dodanie podkreślenia na początku nazwy nie gwarantuje nam hermetyzacji, dlaczego nie użyjesz słowa kluczowego static lub atrybutu visibility?

Część nazwy oczywiście hermetyzacji nie gwarantuje – dostarcza jedynie informacji użytkownikowi. Ponadto takie funkcje nie zaśmiecają dokumentacji (ale oczywiście są opisane w kodzie źródłowym). Niestety użycie słowa static nie rozwiąże problemu, z powodu konstrukcji biblioteki (patrz pytanie o dołączanie plików źródłowych razem z nagłówkami).

Dlaczego konfiguracja nie jest zrealizowana przez edycję plików nagłówkowych? To jest wygodniejsze.

Pliki nagłówkowe są częścią biblioteki, a nie projektu użytkownika. Umieszczenie konfiguracji w kodzie źródłowym użytkownika pozwala na separację projektu od biblioteki – dzięki temu projekt nie jest obciążany implementacją biblioteki (która przy późniejszej jego analizie może być traktowana jako zamknięte pudełko), a biblioteka nie jest zanieczyszczana stałymi z programu (i może być wykorzystana bez modyfikacji w innym projekcie). Inną zaletą jest możliwość praktycznie bezproblemowej aktualizacji biblioteki (modulo kompatybilność między jej wersjami). Proszę też zauważyć, że avr-libc nie konfigurujemy we wspomniany w pytaniu sposób.

Uważam, że biblioteka X jest lepsza w większości zastosowań, ponieważ zużywa kilka bajtów pamięci / taktów procesora mniej. Czy nie lepiej z niej skorzystać?

Biblioteka tAvrLib nie powstała, aby konkurować na tym polu z innymi, implementującymi podobne funkcje (których jest zresztą dużo w Internecie). Jest to raczej odpowiedź na niedosyt kodu dobrej jakości (patrz założenia projektu). Przekłada się to bezpośrednio na koszty zarządzania projektem – w małych, amatorskich aplikacjach, typu "napisz i zapomnij" problem nie ma takiej wagi. Jednak gdy mówimy o dużych projektach, w których znacznie częściej się modyfikuje już napisany (często przez kogoś innego) kod, niż pisze nowy, podejście "pisania po swojemu" mogło by doprowadzić do wykładniczego wzrostu kosztów projektu względem jego rozmiarów.

Zdjęcia

(opóźnienie 100ms między wyrazami dodano celowo)