Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
- Andrzej Ekiert
May 6, 2012, 11:09 am

PrzedstawiC4%99 najpierw scenariusz oraz problem:
Mamy bibliotekC4%99 moduC5%82C3%B3w kodu C5%BArC3%B3dC5%82owego, k=
tC3%B3re sC4%85 uC5%BCywane w wielu =
projektach. KaC5%BCdy z moduC5%82C3%B3w ma swoje parametry konfigurac=
yjne, ktC3%B3rymi =
moC5%BCna go "dostroiC4%87" dla potrzeb konkretnej aplikacji i pC5%82=
ytki - np. moduC5%82 =
bC4%99dC4%85cy driverem do scalaka radiowego ma m.in. parametry okreC5%
9B%lajC4%85ce do =
jakich pinC3%B3w procesora scalak jest podpiC4%99ty, moduC5%82 bC4%99=
dC4%85cy driverem do =
pamiC4%99ci na I2C ma parametry mC3%B3wiC4%85ce ktC3%B3rym interfejs=
em I2C mikrokontrolera =
naleC5%BCy z tC4%85 pamiC4%99ciC4%85 rozmawiaC4%87, jaki jest rozmi=
ar pamiC4%99ci i ktC3%B3ry pin =
procesora to CS, itp.
Problem:
W kaC5%BCdym projekcie, ktC3%B3ry korzysta z danego moduC5%82u, ustaw=
iamy odpowiednio =
wszystkie parametry. NastC4%99pnie, z dowolnej przyczyny, w bibliotece =
=
zmieniamy zestaw parametrC3%B3w konfiguracyjnych oferowanych przez modu=
C5%82. W =
efekcie musimy poprawiC4%87 pliki konfiguracyjne w kaC5%BCdym z projek=
tC3%B3w, co przy =
rosnC4%85cej liczbie tych projektC3%B3w po chwili staje siC4%99 boleC5%
9B%nie pracochC5%82onne.
Szukam mC4%85drej metody radzenia sobie z tC4%85 niepotrzebnC4%85 pra=
cC4%85. Metody =
aplikowalnej do kodu w C i assemblerze (choC4%87 bardzo chC4%99tnie us=
C5%82yszC4%99, jeC5%9Bli =
w C++ da siC4%99 to zrobiC4%87 jakoC5%9B lepiej). WaC5%BCne, aby met=
oda nie powodowaC5%82a =
skutkC3%B3w run-time (np. zamiast ustalaC4%87 rozmiar pamiC4%99ci w k=
onfiguracji, mogC4%99 =
mieC4%87 zmiennC4%85 ustawianC4%85 w funkcji inicjalizujC4%85cej, do=
pinC3%B3w mogC4%99 mieC4%87 =
callbacki wC5%82C4%85cz/wyC5%82C4%85cz, teC5%BC ustawiane przez API=
, a do sprzC4%99towego moduC5%82u =
I2C mogC4%99 mieC4%87 dodatkowC4%85 warstwC4%99 abstrakcji, ale wszy=
stko to kosztuje =
pamiC4%99C4%87 lub cykle, a w przypadku niektC3%B3rych parametrC3%B3=
w jest praktycznie =
niewykonalne - poza tym tylko to przesuwa problem ze zmian konfiguracji,=
=
na zmianC4%99 API).
Jestem blisko rozpoczC4%99cia pisania programu, ktC3%B3ry bC4%99dzie =
mi zarzC4%85dzaC5%82 tC4%85 =
konfiguracjC4%85, tzn. za jednym klikiem porC3%B3wna konfiguracje wszy=
stkich =
zarzC4%85dzanych projektC3%B3w, pokaC5%BCe gdzie sC4%85 nieustawione=
parametry, gdzie sC4%85 =
ustawione juC5%BC nieistniejC4%85ce parametry, gdzie wartoC5%9BC4%87=
parametrC3%B3w rC3%B3C5%BCni siC4%99 =
od domyC5%9Blnej, a nastC4%99pnie umoC5%BCliwi wybranie akcji, ustawi=
enie wC5%82aC5%9Bciwych =
wartoC5%9Bci i uaktualni zarzC4%85dzane pliki konfiguracyjne. Ale troc=
hC4%99 mam =
nadziejC4%99, C5%BCe istnieje jakiC5%9B inteligentny sposC3%B3b, na =
ktC3%B3ry nie wpadC5%82em.
ae
Mamy bibliotekC4%99 moduC5%82C3%B3w kodu C5%BArC3%B3dC5%82owego, k=
tC3%B3re sC4%85 uC5%BCywane w wielu =
projektach. KaC5%BCdy z moduC5%82C3%B3w ma swoje parametry konfigurac=
yjne, ktC3%B3rymi =
moC5%BCna go "dostroiC4%87" dla potrzeb konkretnej aplikacji i pC5%82=
ytki - np. moduC5%82 =
bC4%99dC4%85cy driverem do scalaka radiowego ma m.in. parametry okreC5%
9B%lajC4%85ce do =
jakich pinC3%B3w procesora scalak jest podpiC4%99ty, moduC5%82 bC4%99=
dC4%85cy driverem do =
pamiC4%99ci na I2C ma parametry mC3%B3wiC4%85ce ktC3%B3rym interfejs=
em I2C mikrokontrolera =
naleC5%BCy z tC4%85 pamiC4%99ciC4%85 rozmawiaC4%87, jaki jest rozmi=
ar pamiC4%99ci i ktC3%B3ry pin =
procesora to CS, itp.
Problem:
W kaC5%BCdym projekcie, ktC3%B3ry korzysta z danego moduC5%82u, ustaw=
iamy odpowiednio =
wszystkie parametry. NastC4%99pnie, z dowolnej przyczyny, w bibliotece =
=
zmieniamy zestaw parametrC3%B3w konfiguracyjnych oferowanych przez modu=
C5%82. W =
efekcie musimy poprawiC4%87 pliki konfiguracyjne w kaC5%BCdym z projek=
tC3%B3w, co przy =
rosnC4%85cej liczbie tych projektC3%B3w po chwili staje siC4%99 boleC5%
9B%nie pracochC5%82onne.
Szukam mC4%85drej metody radzenia sobie z tC4%85 niepotrzebnC4%85 pra=
cC4%85. Metody =
aplikowalnej do kodu w C i assemblerze (choC4%87 bardzo chC4%99tnie us=
C5%82yszC4%99, jeC5%9Bli =
w C++ da siC4%99 to zrobiC4%87 jakoC5%9B lepiej). WaC5%BCne, aby met=
oda nie powodowaC5%82a =
skutkC3%B3w run-time (np. zamiast ustalaC4%87 rozmiar pamiC4%99ci w k=
onfiguracji, mogC4%99 =
mieC4%87 zmiennC4%85 ustawianC4%85 w funkcji inicjalizujC4%85cej, do=
pinC3%B3w mogC4%99 mieC4%87 =
callbacki wC5%82C4%85cz/wyC5%82C4%85cz, teC5%BC ustawiane przez API=
, a do sprzC4%99towego moduC5%82u =
I2C mogC4%99 mieC4%87 dodatkowC4%85 warstwC4%99 abstrakcji, ale wszy=
stko to kosztuje =
pamiC4%99C4%87 lub cykle, a w przypadku niektC3%B3rych parametrC3%B3=
w jest praktycznie =
niewykonalne - poza tym tylko to przesuwa problem ze zmian konfiguracji,=
=
na zmianC4%99 API).
Jestem blisko rozpoczC4%99cia pisania programu, ktC3%B3ry bC4%99dzie =
mi zarzC4%85dzaC5%82 tC4%85 =
konfiguracjC4%85, tzn. za jednym klikiem porC3%B3wna konfiguracje wszy=
stkich =
zarzC4%85dzanych projektC3%B3w, pokaC5%BCe gdzie sC4%85 nieustawione=
parametry, gdzie sC4%85 =
ustawione juC5%BC nieistniejC4%85ce parametry, gdzie wartoC5%9BC4%87=
parametrC3%B3w rC3%B3C5%BCni siC4%99 =
od domyC5%9Blnej, a nastC4%99pnie umoC5%BCliwi wybranie akcji, ustawi=
enie wC5%82aC5%9Bciwych =
wartoC5%9Bci i uaktualni zarzC4%85dzane pliki konfiguracyjne. Ale troc=
hC4%99 mam =
nadziejC4%99, C5%BCe istnieje jakiC5%9B inteligentny sposC3%B3b, na =
ktC3%B3ry nie wpadC5%82em.
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

Na to nic nie poradzisz. Skoro biblioteka zmienia swoje
parametry/interface to musisz dostosowaÄ do niej programy.
W c++ od biedy moĹźna zastosowaÄ parametry domyĹlne albo przeciÄ ĹźyÄ
funkcje. Wtedy stare programy mogÄ korzystaÄ ze starego interfejsu.

A to juĹź zwykĹe makra, definy, funkcje inline, specjalizacje szablonĂłw
nie wystarczÄ do ukrycia fizycznego poĹoĹźenia pinĂłw?

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.
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?
WolÄ zrobiÄ kopiÄ biblioteki z projektu x-1 i nanieĹÄ poprawki.

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂłw ko du ĹşrĂłdĹowego


WystarczC4%85, ale dla kaC5%BCdego projektu trzeba te define'y inaczej=
ustawiC4%87 - =
ta sama nazwa, inna wartoC5%9BC4%87.



82% radiowy wykorzysta te =

Przy wielu architekturach, to akurat nie mam wyjC5%9Bcia i muszC4%99 z=
robiC4%87 =
takiego HALa, ale narzut jest. W przypadku jednej architektury, to zamia=
st =
po prostu siC4%99 odwoC5%82aC4%87 do rejestru sprzC4%99towego moduC5%
82%u, muszC4%99 przekazaC4%87 =
mojemu driverowi do chipu jakC4%85C5%9B strukturC4%99 drivera do modu=
C5%82u I2C, ktC3%B3ra =
bC4%99dzie mieC4%87 np. callbacki do funkcji poC5%9BredniczC4%85cych=
. Narzut jak diabli, =
choC4%87 czasem trzeba siC4%99 na niego zgodziC4%87 (np. wspC3%B3dzi=
elony dostC4%99p kilku =
"driverC3%B3w" do jednego sprzC4%99towego I2C).

BC%nych =



Staram siC4%99 tak modularyzowaC4%87 kod i dawaC4%87 takie API, C5%BC=
eby zmiany nie =
wywoC5%82ywaC5%82y efektC3%B3w ubocznych. OczywiC5%9Bcie przetestowa=
C4%87 to zawsze trzeba i =
nie dam sobie uciC4%85C4%87 nawet paznokcia.

Wykrywasz bC5%82C4%85d albo robisz usprawnienie w x-1 i dopiero masz p=
oprawianie =
wszC4%99dzie gdzie ta kopia jest. Brrr...
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

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Ä?

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.

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?

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂłw ko du ĹşrĂłdĹowego



Tak.




Masz driver do RTC w bibliotece. Procesor ma 2 moduC5%82y sprzC4%99tow=
e I2C1 i =
I2C2. Musisz przekazaC4%87 driverowi RTC informacjC4%99, funkcje dotyc=
zC4%85ce ktC3%B3rego =
moduC5%82u ma wywoC5%82aC4%87: odbierz_blok_danych_z_I2C1() czy =
odbierz_blok_danych_z_I2C2(). Albo to robisz na poziomie #define, albo =
definiujC4%85c "driver" do I2C i przekazujC4%85c moduC5%82owi I2C han=
dle do tego =
drivera (jest narzut). Ja chcC4%99 na poziomie #define, ale pragnC4%99=
sobie =
usprawniC4%87 zarzC4%85dzanie takimi #define.

9B%C487% poprawki.

BC%na =

SpieprzyC4%87 zawsze moC5%BCna. Poza tym moduC5%82 moC5%BCe byC4%87=
czymC5%9B bardziej zC5%82oC5%BConym. =
Np. implementacjC4%85 protokoC5%82u sieciowego.



Gwarancji nie mam, choC4%87 moja ciC4%85gC5%82a dbaC5%82oC5%9BC4%87=
o to, by kawaC5%82ek kodu, w =
ktC3%B3rym zaleC5%BCnoC5%9Bci czasowe wystC4%99pujC4%85, nie mC3%B3=
gC5%82 byC4%87 zakC5%82C3%B3cony przez inne =
niezwiC4%85zane z nim moduC5%82y wykonywane rC3%B3wnolegle, daje mi s=
pore szanse. =
Generalnie uwaC5%BCam, C5%BCe zysk ze wspC3%B3C5%82dzielonych biblio=
tek znacznie =
przewyC5%BCsza koszty.
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego
W dniu 06.05.2012 15:44, Andrzej Ekiert pisze:

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.

No to uĹźyj tego define. I tak jak podaĹem wyĹźej moĹźesz zrobiÄ domyĹlnÄ
definicjÄ dla starych programĂłw.

zĹoĹźonym.

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

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.

No to uĹźyj tego define. I tak jak podaĹem wyĹźej moĹźesz zrobiÄ domyĹlnÄ
definicjÄ dla starych programĂłw.

zĹoĹźonym.

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

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

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
Pozdrawiam
Michoo

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

Ĺť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
Pozdrawiam
Michoo

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

KopiÄ? Od tego sÄ systemy kontroli wersji. Robimy brancha nowego i
dostosowujemy. Jak coĹ siÄ zmieni w gĹĂłwnej gaĹÄzi (np straszny bug
wykryty) to mergujemy samÄ zmianÄ. W gicie robi siÄ to piÄknie...
Takie problemy wystÄpujÄ podczas rozwoju kaĹźdego oprogramowania, warto
poczytaÄ o schematach/rozwiÄ zaniach przetestowanych w takim Ĺrodowisku.
http://nvie.com/posts/a-successful-git-branching-model /
Marek

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego
Ja osobiĹcie jestem na poczÄ
tku drogi - tj. jeszcze nie powstaĹy te
dziesiatki modulow do dziesiatek aplikacji, ale zaczynam juĹź dostrzegaÄ
problem, stÄ d moje zainteresowanie tÄ problematykÄ - tak, aby zawczasu
coĹ ustaliÄ i pisaÄ dalej w/g ustalonej, optymalnej metody.
Jednym z pomysĹĂłw jest wykorzystanie programĂłw do zarzÄ dzania wersjami
typu: SVN, GIT, Mercurial.
Innym pomysĹem, ktĂłry mnie zainteresowaĹ, jest wykorzystanie linkĂłw do
plikĂłw zamiast kopii plikĂłw (pod Linuxem) - w ten sposĂłb mamy tylko
jeden plik, widziany przez dowolnie wiele projektow i zmiana w nim
przenosi siÄ automatycznie na wszystkie projekty.
Najprosciej byĹoby nie zmieniaÄ parametrow konfiguracyjnych w bibliotece
;-)
A moĹźe zostawiÄ stare jako 'deprecated', a dodac do nich nowe?
dziesiatki modulow do dziesiatek aplikacji, ale zaczynam juĹź dostrzegaÄ
problem, stÄ d moje zainteresowanie tÄ problematykÄ - tak, aby zawczasu
coĹ ustaliÄ i pisaÄ dalej w/g ustalonej, optymalnej metody.
Jednym z pomysĹĂłw jest wykorzystanie programĂłw do zarzÄ dzania wersjami
typu: SVN, GIT, Mercurial.
Innym pomysĹem, ktĂłry mnie zainteresowaĹ, jest wykorzystanie linkĂłw do
plikĂłw zamiast kopii plikĂłw (pod Linuxem) - w ten sposĂłb mamy tylko
jeden plik, widziany przez dowolnie wiele projektow i zmiana w nim
przenosi siÄ automatycznie na wszystkie projekty.
Najprosciej byĹoby nie zmieniaÄ parametrow konfiguracyjnych w bibliotece
;-)
A moĹźe zostawiÄ stare jako 'deprecated', a dodac do nich nowe?
--
Jado
W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:
Jado
W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:
We've slightly trimmed the long signature. Click to see the full one.

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂłw ko du ĹşrĂłdĹowego
napisaC5%82(a):

85%dzania wersjami =

AleC5%BC ja to wszystko mam pod Mercurialem, tyle C5%BCe to tego probl=
emu akurat =
nie rozwiC4%85zuje.



Chodzi o to, C5%BCe dla kaC5%BCdego projektu mam te same parametry ust=
awione w =
inny sposC3%B3b. WiC4%99c teC5%BC nie rozwiC4%85zuje problemu.


No rzeczywiC5%9Bcie :-)
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

Zapropnuje sposĂłb trywialny, byÄ moĹźe akurat bÄdzie w sam raz:
*** i2cdriver.c ***
#include "i2cconfiguration.h"
#include "../lib/i2c/i2ccore.c"
#include "../lib/i2c/i2chardware.c"
*** i2cdriver.h ***
#include "i2cconfiguration.h"
#include "../lib/i2c/i2cinterface.h"
Plik i2cconfiguration.h jest czÄsciÄ konkretnego projektu, podobnie jak
i2cdriver.c.
I tyle. W i2cconfiguratiion stado #define per projekt. W plikach lib/i2c
(h i c) od groma #ifdef na kaĹźdy wariant.
Powinno byÄ najmniej intruzywne i najĹatwiejsze w utrzymaniu przez
programistÄ C. Ĺťadnych zmian w bibliotece. Wada: kompilujesz wszystko za
pierwszym razem. ALE. Dzieki make potem kompilujesz tylko zmiany, wiÄc
narzut jest jednorazowy.

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂłw ko du ĹşrĂłdĹowego
napisaC5%82(a):



Ale to mi w C5%BCaden sposC3%B3b nie dotyka mojego problemu. JeC5%9Bl=
i odwoC5%82am siC4%99 w =
"../lib/i2c/i2ccore.c" do nowego parametru konfiguracyjnego C_I2C_SHMOO,=
=
to muszC4%99 go rC4%99cznie zdefiniowaC4%87 w kaC5%BCdym i2cconfigur=
ation.h w kaC5%BCdym =
projekcie. JeC5%9Bli zmieniC4%99 nazwC4%99 i trochC4%99 funkcje para=
metru C_I2C_FOO na =
C_I2C_BAR, to znowu zmiana w kaC5%BCdym projekcie. Chodzi mi o sposC3%B3=
b lub =
narzC4%99dzie do automatyzacji takich zmian: wykrywanie niedodanych def=
inicji, =
eliminacjC4%99 przestarzaC5%82ych definicji, itp.
Samo definiowanie konfiguracji per-projekt i jej #include w plikach =
biblioteki to mam rozwiC4%85zane w miarC4%99 elegancko. Boli mnie tylk=
o potrzeba =
rC4%99cznego czyszczenia konfiguracji per-projekt w wypadku zmian w opc=
jach =
oferowanych przez bibliotekC4%99.
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

#include "../lib/i2c/defaultconfiguration.h"
#include "i2cconfiguration.h"
To powinno zadzialaÄ jak gdyby dziedziczenie parametrĂłw. MoĹźesz teĹź uzyÄ
#ifndef FOO, #define FOO DEFAULR_FOO.
Ewentualnie, znacznie bezpieczniej, #ifndef FOO, #error "FOO not set"

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.
Podobnie do tego pomysĹu dziaĹa konfigurator opcji kompilacji linuxa
(kernela). MoĹźesz sobie wyobraziÄ Ĺźe tak jest ich duĹźo i Ĺźe pojawia siÄ
niedostrzegana wczeĹniej warstwa - zaleĹźnoĹci. W dodatku sÄ ustalane
rÄcznie. Np. sterownik do foobar moĹźna kompilowac tylko wtedy gdy jest
scsi itp. Takie zaleznoĹci sÄ cieĹźkie w utrzymaniu bo nie wynikajÄ
wprost z kodu tylko z jakieĹ metawiedzy poza.

Tego nie unikniesz w przypadku ogĂłlnym. Jesli i2cdriver_init przyjmie 2
parametry a nie jeden to i tak musisz zmieniÄ *wszystkie* projekty.
Wielu programistĂłw C wpada tutaj na genialny pomysĹ uzycia makr albo
domyslnych parametrĂłw, ale do Ĺlepa uliczka. Tak czy inaczej refaktoring
bibliteki generuje zmiany po stronie klientĂłw.
Jesli masz klienta martwego, ale mimo to chcesz utrzymaÄ kompilacjÄ, to
czasami wystarczy kod forkowaÄ, czyli #include
"../lib/i2c/v2/i2ccode.c". Nie jest to eleganckie, ale w przypadku
embedded pozwala projekt zamroziÄ. Problemem jest backportowanie poprawek.
Ten sposob jest uzywany teĹź na linuxie, wystarczy zobaczyÄ katalog /lib
Ĺźeby zauwaĹźyÄ wiele rĂłznych wersji bibliotek. GĹĂłwnie dla supportu
starych klientĂłw.

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂłw ko du ĹşrĂłdĹowego
napisaC5%82(a):

Mam to doC5%9BC4%87 podobnie zrobione. Samo dziedziczenie defaultu to =
nie jest =
najlepszy pomysC5%82, bo nowo dodany parametr moC5%BCe przejC5%9BC4%87=
niezauwaC5%BCony. WiC4%99c =
albo dziedziczC4%99 caC5%82C4%85 konfiguracjC4%99 moduC5%82u, albo =
wszystkie parametry muszC4%85 =
byC4%87 w projekcie przedefiniowane.

To juC5%BC w zasadzie mam wbudowane: zawsze kompilujC4%99 z -Wundef i =
zamiast =
#ifdef do wC5%82C4%85czania opcji uC5%BCywam "#if C_FOOBAR 3D%3D ENA=
BLED". Mam wtedy =
warning gdy coC5%9B nie jest ustawione.

B3%b lub


87% siC4%99 na =


SkC5%82aniam siC4%99 ku uC5%BCyciu narzC4%99dzia, C5%BCeby zamiast =
otwieraC4%87 20 plikC3%B3w (a za =
parC4%99 lat moC5%BCe 100?) i wszC4%99dzie robiC4%87 'paste' nowego =
parametru, mC3%B3c kliknC4%85C4%87 =
"update". OczywiC5%9Bcie kompilacja potem i tak jest nieodzowna (nie mC3%
B3%wiC4%85c o =
teC5%9Bcie).


Nawet zaglC4%85daC5%82em mu w C5%BArC3%B3dC5%82a, czy by siC4%99 n=
ie daC5%82o czegoC5%9B wykorzystaC4%87, ale =
trochC4%99 mnie odrzuciC5%82o. Poza tym w menuconfig jednak niezbyt do=
brze widaC4%87 =
nowe parametry, a usuniC4%99te po prostu po cichu znikajC4%85 (jeC5%9B=
li siC4%99 nic nie =
zmieniC5%82o od ostatniego razu, jak kompilowaC5%82em kernel).
MiaC5%82em po prostu nadziejC4%99, C5%BCe kogoC5%9B juC5%BC to uwie=
raC5%82o i jakieC5%9B narzC4%99dzie =
istnieje. No nic, napiszC4%99 sobie sam.
ae

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego
W dniu 06.05.2012 16:10, Andrzej Ekiert pisze:

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....

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
Jado

Re: [OT] ZarzÄ
dzanie konfiguracjÄ
moduĹĂł w kodu ĹşrĂłdĹowego

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.

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.
Site Timeline
- » 8-bit DAC VGA
- — Next thread in » Electronics (Polish)
-
- » 78S05 - dla Identyfikatora
- — Previous thread in » Electronics (Polish)
-
- » Ładowarka everactive nc-1000 plus
- — Newest thread in » Electronics (Polish)
-
- » ntfs
- — Last Updated thread in » Electronics (Polish)
-
- » Atmel 328 ext. interupts
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Atmel 328 ext. interupts
- — The site's Last Updated Thread. Posted in » Embedded Programming
-