W dniu 06.05.2012 14:55, Andrzej Ekiert pisze:
> Dnia 06-05-2012 o 14:19:08 Zbych <z...@o...pl> napisał(a):
>
>> A to już zwykłe makra, definy, funkcje inline, specjalizacje szablonów
>> nie wystarczą do ukrycia fizycznego położenia pinów?
>
> Wystarczą, ale dla każdego projektu trzeba te define'y inaczej ustawić -
> ta sama nazwa, inna wartość.

Zgadza się i zakładam, że rzeczy specyficzne dla projektu trzymasz w
osobnym pliku, który leży sobie w katalogu z projektem i jest przez
bibliotekę tylko includowany. Zgadza się?


>> Jeśli do wszystkich modułów I2C z różnych procesorów jesteś w stanie
>> opracować jeden interface to nie ma problemu. Dodajesz do projektu
>> plik ze swoją obsługą I2C od danego procka i już. Moduł radiowy
>> wykorzysta te funkcje, które dołączy linker. Zero narzutu.
>
> Przy wielu architekturach, to akurat nie mam wyjścia i muszę zrobić
> takiego HALa, ale narzut jest. W przypadku jednej architektury, to
> zamiast po prostu się odwołać do rejestru sprzętowego modułu, muszę
> przekazać mojemu driverowi do chipu jakąś strukturę drivera do modułu
> I2C, która będzie mieć np. callbacki do funkcji pośredniczących. Narzut
> jak diabli, choć czasem trzeba się na niego zgodzić (np. wspódzielony
> dostęp kilku "driverów" do jednego sprzętowego I2C).

Ja jak na razie na I2c wieszałem jakieś pamięci, RTC itp. badziewie. Do
jego obsługi wystarczały mi 3 funkcje typu wyślij blok danych, odbierz
blok danych, sprawdź gotowość. Współdzielenie zabezpieczałem mutexami.
Funkcje RTC czy obsługa pamięci wprost wołały te funkcje. W innym procku
dodawałem tylko inną bibliotekę do I2c. Interface zostawał ten sam. Zero
narzutu.

>> Ja raczej unikami używania tej samej kopii biblioteki do różnych
>> projektów. Dasz sobie głowę uciąć, że zmiana w bibliotece pod bieżący
>> projekt x nie spowoduje jakiś anomalii w projekcie x-10, który pisała
>> inna osoba?
>
> Staram się tak modularyzować kod i dawać takie API, żeby zmiany nie
> wywoływały efektów ubocznych. Oczywiście przetestować to zawsze trzeba i
> nie dam sobie uciąć nawet paznokcia.
>
>> Wolę zrobić kopię biblioteki z projektu x-1 i nanieść poprawki.
>
> Wykrywasz błąd albo robisz usprawnienie w x-1 i dopiero masz poprawianie
> wszędzie gdzie ta kopia jest. Brrr...

To jest niewątpliwie wada. Ale powiedzmy sobie szczerze, ile można
spieprzyć w kodzie obsługi I2C, uarta itp?
A teraz weź projekt sprzed kilku lat (bo klient chce drobną poprawkę) i
skompiluj go z nową biblioteką. Jaką masz gwarancję, że nie wyjdą jakieś
wredne bugi związane np. z zależnościami czasowymi?