On 06.05.2012 14:55, Andrzej Ekiert wrote:
> 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 właśnie rzeźbię powolutku coś takiego w C++, tylko zamiast callbacków
traits przekazywane do szablonów, żeby nie było żadnego narzutu w runtime.

Kompilator odwala całkiem niezłą robotę z funkcjami inline, np

HW::uart<0>::send_char(buf[i]);
zamienia na pojedynczy mov do rejestru.



--
Pozdrawiam
Michoo

do góry

W dniu 06.05.2012 15:44, Andrzej Ekiert pisze:
> Dnia 06-05-2012 o 15:23:06 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ę?
>>
>
> Tak.

No to dużo więcej już nie wymyślisz. Co najwyżej możesz w przypadku
dokładania nowych stałych/parametrów napisać:

#ifndef XYZ
#define XYZ 12345
#endif

Wtedy biblioteka ze starym programem nie będzie krzyczała, że nie ma
zdefiniowanych parametrów.

>
>> 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.
>
> Masz driver do RTC w bibliotece. Procesor ma 2 moduły sprzętowe I2C1 i
> I2C2. Musisz przekazać driverowi RTC informację, funkcje dotyczące
> którego modułu ma wywołać: odbierz_blok_danych_z_I2C1() czy
> odbierz_blok_danych_z_I2C2(). Albo to robisz na poziomie #define, albo
> definiując "driver" do I2C i przekazując modułowi I2C handle do tego
> drivera (jest narzut). Ja chcę na poziomie #define, ale pragnę sobie
> usprawnić zarządzanie takimi #define.

No to użyj tego define. I tak jak podałem wyżej możesz zrobić domyślną
definicję dla starych programów.

>>>> 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?
>
> Spieprzyć zawsze można. Poza tym moduł może być czymś bardziej złożonym.
> Np. implementacją protokołu sieciowego.

Takie rzeczy jak protokół to już dla mnie warstwa wyższa :-) i tu nie
mam obaw o współdzielenie.

do góry

Dnia 06-05-2012 o 15:49:54 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> On 2012-05-06 15:30, Andrzej Ekiert wrote:
>> Ale to mi w żaden sposób nie dotyka mojego problemu. Jeśli odwołam się w
>> "../lib/i2c/i2ccore.c" do nowego parametru konfiguracyjnego C_I2C_SHMOO,
>> to muszę go ręcznie zdefiniować w każdym i2cconfiguration.h w każdym
>> projekcie.
>
> #include "../lib/i2c/defaultconfiguration.h"
> #include "i2cconfiguration.h"
>
> To powinno zadzialać jak gdyby dziedziczenie parametrów.

Mam to dość podobnie zrobione. Samo dziedziczenie defaultu to nie jest
najlepszy pomysł, bo nowo dodany parametr może przejść niezauważony. Więc
albo dziedziczę całą konfigurację modułu, albo wszystkie parametry muszą
być w projekcie przedefiniowane.

> Możesz też uzyć #ifndef FOO, #define FOO DEFAULR_FOO.
>
> Ewentualnie, znacznie bezpieczniej, #ifndef FOO, #error "FOO not set"

To już w zasadzie mam wbudowane: zawsze kompiluję z -Wundef i zamiast
#ifdef do włączania opcji używam "#if C_FOOBAR == ENABLED". Mam wtedy
warning gdy coś nie jest ustawione.

>> Jeśli zmienię nazwę i trochę funkcje parametru C_I2C_FOO na
>> C_I2C_BAR, to znowu zmiana w każdym projekcie. Chodzi mi o sposób lub
>> narzędzie do automatyzacji takich zmian: wykrywanie niedodanych
>> definicji, eliminację przestarzałych definicji, itp.
>
> Najlepiej, gdybys tego nie robił w ogóle. takie narzędzie jest
> niebezpieczne. Wydaje mi się, że najbezpieczniej jest zdać się na
> kompilator. Czyli raz na jakiś czas budujesz wszystkie swoje żywe
> projekty w całości i poprawiasz tam gdzie padła kompilacja.

Skłaniam się ku użyciu narzędzia, żeby zamiast otwierać 20 plików (a za
parę lat może 100?) i wszędzie robić 'paste' nowego parametru, móc kliknąć
"update". Oczywiście kompilacja potem i tak jest nieodzowna (nie mówiąc o
teście).

> Podobnie do tego pomysłu działa konfigurator opcji kompilacji linuxa
> (kernela).

Nawet zaglądałem mu w źródła, czy by się nie dało czegoś wykorzystać, ale
trochę mnie odrzuciło. Poza tym w menuconfig jednak niezbyt dobrze widać
nowe parametry, a usunięte po prostu po cichu znikają (jeśli się nic nie
zmieniło od ostatniego razu, jak kompilowałem kernel).

Miałem po prostu nadzieję, że kogoś już to uwierało i jakieś narzędzie
istnieje. No nic, napiszę sobie sam.

ae

do góry

W dniu 06.05.2012 16:10, Andrzej Ekiert pisze:

> Skłaniam się ku użyciu narzędzia, żeby zamiast otwierać 20 plików (a za
> parę lat może 100?) i wszędzie robić 'paste' nowego parametru, móc
> kliknąć "update". Oczywiście kompilacja potem i tak jest nieodzowna (nie
> mówiąc o teście).
>
>> Podobnie do tego pomysłu działa konfigurator opcji kompilacji linuxa
>> (kernela).
>
> Nawet zaglądałem mu w źródła, czy by się nie dało czegoś wykorzystać,
> ale trochę mnie odrzuciło. Poza tym w menuconfig jednak niezbyt dobrze
> widać nowe parametry, a usunięte po prostu po cichu znikają (jeśli się
> nic nie zmieniło od ostatniego razu, jak kompilowałem kernel).
>
> Miałem po prostu nadzieję, że kogoś już to uwierało i jakieś narzędzie
> istnieje. No nic, napiszę sobie sam.
>
> ae

Przy okazji tematu nasuwa się pytanie: "Jak długo należy utrzymywać
stare projekty w stanie zaktualizowanym" Czy po prostu nie umrą one
śmiercią naturalną i zatrzymają się na jakimś etapie ich rozwoju, a
łatwiej będzie stworzyć nowy projekt, na nowy procesor, w/g nowych
bibliotek, itp....

--
Jado

do góry

W dniu 06.05.2012 15:54, Michoo pisze:
> On 06.05.2012 14:55, Andrzej Ekiert wrote:
>> 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 właśnie rzeźbię powolutku coś takiego w C++, tylko zamiast callbacków
> traits przekazywane do szablonów, żeby nie było żadnego narzutu w runtime.
>
> Kompilator odwala całkiem niezłą robotę z funkcjami inline, np
>
> HW::uart<0>::send_char(buf[i]);
> zamienia na pojedynczy mov do rejestru.

A jakie będą tego zalety w stosunku do wersji z define?

do góry

On 2012-05-06 16:10, Andrzej Ekiert wrote:
> Skłaniam się ku użyciu narzędzia, żeby zamiast otwierać 20 plików (a za
> parę lat może 100?) i wszędzie robić 'paste' nowego parametru

Jesli to stare projekty to po prostu zamrażasz implementacje bibliotek i
ich nie rozwijasz. Ile równolegle utrzymujesz żywych projektów? Kilka?

Zamrozić biblitekę można też pisząc adapter do nowszej wersji. Niestety
to generuje czasem spory kod i potrafi też szlag trafić.

Ostatecznie po prostu porzucaj kod starych projektów poprzez usuwanie go
z repozytorium. Zawsze się możesz wycofać jak-by-co. W embedded to
jak-by-co nie występuje za czesto.

> Miałem po prostu nadzieję, że kogoś już to uwierało i jakieś narzędzie
> istnieje. No nic, napiszę sobie sam.

Zerknij jeszcze na konfigurator eCos.

IMHO zamieniasz siekierkę na kijek. Now narzedzie nie usunie problemów
starego. Dlaje będziesz walczył z poprawianiem kodu, z zastanawianiem
się jaki podać parametr w miejsce dwoch poprzednich itp. Zawsze będzie
ywmagana ingerencja w kod. Tak czy inaczej.

do góry

Dnia 06-05-2012 o 16:42:22 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> Jesli to stare projekty to po prostu zamrażasz implementacje bibliotek i
> ich nie rozwijasz. Ile równolegle utrzymujesz żywych projektów? Kilka?

Mam trochę specyficzną sytuację: np. do projektu referencyjnego modemu PLC
mam kilka programów demo, oprogramowanie własnych urządzeń, kilka
programów pod różnych klientów oraz aplikacje testowe. W sumie kilkanaście
programów do konfigurowania w ramach jednego żywego projektu. Wszystko
musi być ciągle gotowe do wypuszczenia kodu na zewnątrz.

>> Miałem po prostu nadzieję, że kogoś już to uwierało i jakieś narzędzie
>> istnieje. No nic, napiszę sobie sam.
>
> Zerknij jeszcze na konfigurator eCos.
>

Kiedyś go nawet używałem. Faktycznie, zobaczę.

ae

do góry

On 06.05.2012 16:28, Zbych wrote:
> W dniu 06.05.2012 15:54, Michoo pisze:
>> HW::uart<0>::send_char(buf[i]);
>> zamienia na pojedynczy mov do rejestru.
>
> A jakie będą tego zalety w stosunku do wersji z define?
Że nie muszę kopiować kodu dla uart 1. No i środowisko mi ładniej
koloruje funkcje wpisane jako funkcje a nie jako połamane define.

Btw - jak będę miał dość czasu, żeby posprzątać kod to wrzucę go na
jakieś sourceforge i każdy będzie mógł ocenić.


--
Pozdrawiam
Michoo

do góry

Dnia 06-05-2012 o 15:54:48 Michoo <m...@v...pl> napisał(a):

> Ja właśnie rzeźbię powolutku coś takiego w C++, tylko zamiast callbacków
> traits przekazywane do szablonów, żeby nie było żadnego narzutu w
> runtime.
>

Możliwość robienia czegoś takiego mnie mocno przekonuje do C++.

ae

do góry

W dniu 2012-05-06 16:10, Andrzej Ekiert pisze:
> Dnia 06-05-2012 o 15:49:54 Sebastian Biały <h...@p...onet.pl>
> napisał(a):
>
>> On 2012-05-06 15:30, Andrzej Ekiert wrote:
>>> Ale to mi w żaden sposób nie dotyka mojego problemu. Jeśli odwołam się w
>>> "../lib/i2c/i2ccore.c" do nowego parametru konfiguracyjnego C_I2C_SHMOO,
>>> to muszę go ręcznie zdefiniować w każdym i2cconfiguration.h w każdym
>>> projekcie.
>>
>> #include "../lib/i2c/defaultconfiguration.h"
>> #include "i2cconfiguration.h"

Chyba miało być odwrotnie...

>>
>> To powinno zadzialać jak gdyby dziedziczenie parametrów.
>
> Mam to dość podobnie zrobione. Samo dziedziczenie defaultu to nie jest
> najlepszy pomysł, bo nowo dodany parametr może przejść niezauważony.
> Więc albo dziedziczę całą konfigurację modułu, albo wszystkie parametry
> muszą być w projekcie przedefiniowane.

Ciągle nie rozumiem na czym polega Twój problem...
Skoro pojawia się nowy parametr modułu bibliotecznego, to mamy dwie
opcje: albo musi on być obligatoryjne określony przez użytkownika
biblioteki (wtedy zdajemy się na kompilator i błąd klasy undefined),
albo nowy parametr ma jakąś wartość domyślną (stałą lub jakoś
ewaluowaną) i użytkownik ewentualnie może przedefiniować ten parametr.

Czy coś ponad to?

pzdr
mk

do góry