Goto page Previous 1, 2, 3 Next
Sebastian BiaĹy
Guest
Sun May 06, 2012 2:42 pm
On 2012-05-06 16:10, Andrzej Ekiert wrote:
Quote:
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.
Quote:
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.
Andrzej Ekiert
Guest
Sun May 06, 2012 2:50 pm
Dnia 06-05-2012 o 16:42:22 Sebastian Biały <heby@poczta.onet.pl>
napisał(a):
Quote:
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.
Quote:
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
Michoo
Guest
Sun May 06, 2012 2:55 pm
On 06.05.2012 16:28, Zbych wrote:
Quote:
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
Andrzej Ekiert
Guest
Sun May 06, 2012 3:08 pm
Dnia 06-05-2012 o 15:54:48 Michoo <michoo_news@vp.pl> napisał(a):
Quote:
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
mk
Guest
Sun May 06, 2012 3:21 pm
W dniu 2012-05-06 16:10, Andrzej Ekiert pisze:
Quote:
Dnia 06-05-2012 o 15:49:54 Sebastian Biały <heby@poczta.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...
Quote:
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
Sebastian BiaĹy
Guest
Sun May 06, 2012 3:35 pm
On 2012-05-06 17:21, mk wrote:
Quote:
#include "../lib/i2c/defaultconfiguration.h"
#include "i2cconfiguration.h"
Chyba miało być odwrotnie...
Nie. plik lokalny dla projektu nadpisuje parametry domyślne.
marek
Guest
Sun May 06, 2012 3:41 pm
On 06.05.2012 14:19, Zbych wrote:
Quote:
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.
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
Andrzej Ekiert
Guest
Sun May 06, 2012 3:41 pm
Dnia 06-05-2012 o 17:21:11 mk <reverse_lp.pw@myzskm> napisał(a):
Quote:
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.
Skłaniam się ku pierwszej opcji: obligatoryjne określenie, nawet jeśli
zwykle będzie to przypisanie wartości domyślnej. Chcę jakoś sobie to
określanie usprawnić semi-automatyzując zadanie. Na razie mam tylko
autowykrywanie przez próbę kompilacji gdzie parametr nie jest
zdefiniowany. Chciałbym ułatwić sobie dodawanie tego parametru do plików
konfiguracyjnych, oraz mieć wykrywanie ustawienia parametrów, które stały
się "obsolete".
ae
mk
Guest
Sun May 06, 2012 4:18 pm
W dniu 2012-05-06 17:35, Sebastian Biały pisze:
Quote:
On 2012-05-06 17:21, mk wrote:
#include "../lib/i2c/defaultconfiguration.h"
#include "i2cconfiguration.h"
Chyba miało być odwrotnie...
Nie. plik lokalny dla projektu nadpisuje parametry domyślne.
Używając #undef???
IMO zdecydowanie lepsze jest jednak włączenie najpierw pliku z
konfiguracją użytkownika, a potem nagłówek z konfiguracją domyślną -- to
zresztą powszechna praktyka.
Plik nagłówkowy "defaultconfiguration.h" nie definiuje parametrów już
zdefiniowanych (#ifndef), a jedynie te które jeszcze nie zostały
zdefiniowane nadając im wartości domyślne (+ ewentualnie jakiś komunikat
przy pomocy #warning), obliczając je (np. na podstawie parametrów
podanych przez użytkownika) lub walnąć błędem (#error) jeśli parametr ma
być obligatoryjne określony przez użytkownika.
pzdr
mk
Zbych
Guest
Sun May 06, 2012 4:32 pm
W dniu 06.05.2012 16:55, Michoo pisze:
Quote:
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.
Póki rejestry UART są rozmieszczone identycznie względem bazowego, to w
zwykłym C napiszesz jedną obsługę do wszystkich UARTów bez żadnych
define'ów.
Quote:
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ć.
Chętnie zobaczę.
Sebastian BiaĹy
Guest
Sun May 06, 2012 5:00 pm
On 2012-05-06 18:18, mk wrote:
Quote:
Nie. plik lokalny dla projektu nadpisuje parametry domyślne.
Używając #undef???
Uzywając def.
Np. tak:
default-config: #define UART_STOP_BITS 1
project-config: #include "default.h", #define UART_STOP_BITS 2
Quote:
IMO zdecydowanie lepsze jest jednak włączenie najpierw pliku z
konfiguracją użytkownika, a potem nagłówek z konfiguracją domyślną -- to
zresztą powszechna praktyka.
Zdecydowana lepszośc tutaj dyskusyjna. Oba rozwiązania działają.
Quote:
Plik nagłówkowy "defaultconfiguration.h" nie definiuje parametrów już
zdefiniowanych (#ifndef), a jedynie te które jeszcze nie zostały
zdefiniowane nadając im wartości domyślne (+ ewentualnie jakiś komunikat
przy pomocy #warning), obliczając je (np. na podstawie parametrów
podanych przez użytkownika) lub walnąć błędem (#error) jeśli parametr ma
być obligatoryjne określony przez użytkownika.
W drugą stronę działa to tak samo (nie)skutecznie bez #ifndef, kwestia
implementacji.
IMO to nie konfiguracja powinna szukać bledów w #define i wyliczać
pośrednie parametry tylko implementacja. Więc detekcje źle ustawionych
parametrów robię w pliku c. To dlatego że to w pliku c wiadomo jaka
konfiguracja jest nielegalna, np. uart avr ie obsługuje 2 bitów stopu.
Gdyby te zależności miał wyliczać globalny plik default-config.h to
wiedza o uart avr wyciekła by z implementacji specyficznej dla hardware
do globalnej przestrzeni gdzie ją ciężko utrzymać.
W moim rozwiązaniu zależności są detektowane i obliczane w c drivera bo
nie ma innej możliwości. I dzieki temu plik default-config jest czysty o
specyficznej wiedzy o hardware. Nie zawsze, ale zazwyczaj. Innymi słowy
wszystko co dotyczy avr znajduje się w katalogu /avr/ i nie przecieka do
inych plików.
Przy czym żeby było jasno - oba podejścia są tak samo mizerne.
mk
Guest
Sun May 06, 2012 7:32 pm
W dniu 2012-05-06 19:00, Sebastian Biały pisze:
Quote:
On 2012-05-06 18:18, mk wrote:
Nie. plik lokalny dla projektu nadpisuje parametry domyślne.
Używając #undef???
Uzywając def.
Np. tak:
default-config: #define UART_STOP_BITS 1
project-config: #include "default.h", #define UART_STOP_BITS 2
Redefiniowanie makra nową wartością jest nielegalne!!!
Quote:
IMO zdecydowanie lepsze jest jednak włączenie najpierw pliku z
konfiguracją użytkownika, a potem nagłówek z konfiguracją domyślną -- to
zresztą powszechna praktyka.
Zdecydowana lepszośc tutaj dyskusyjna. Oba rozwiązania działają.
Jak gdzie (patrz wyżej).
Można by odwołać jak wspomniałem z użyciem #undef, ale użycie #undef
jest niezgodne np. z MISRA-C i w ogóle niepotrzebnie zaciemnia plik
konfiguracji użytkownika.
Quote:
Plik nagłówkowy "defaultconfiguration.h" nie definiuje parametrów już
zdefiniowanych (#ifndef), a jedynie te które jeszcze nie zostały
zdefiniowane nadając im wartości domyślne (+ ewentualnie jakiś komunikat
przy pomocy #warning), obliczając je (np. na podstawie parametrów
podanych przez użytkownika) lub walnąć błędem (#error) jeśli parametr ma
być obligatoryjne określony przez użytkownika.
W drugą stronę działa to tak samo (nie)skutecznie bez #ifndef, kwestia
implementacji.
Niezgodne ze standardem.
Quote:
IMO to nie konfiguracja powinna szukać bledów w #define i wyliczać
pośrednie parametry tylko implementacja.
To zależy i to już trochę inny temat... część rzeczy można i należy
sygnalizować już na wczesnym etapie rozpoznania konfiguracji użytkownika
np. zgodność wersji modułu bibliotecznego i jej użytkownika, czy wiele
innych parametrów o globalnym charakterze.
Rozmowa na temat czy "default.h" należy czy nie należy do implementacji
jest również czysto akademicka, tak jak i gdzie najlepiej określać
parametry default.
pzdr
mk
Sebastian BiaĹy
Guest
Sun May 06, 2012 8:05 pm
On 2012-05-06 21:32, mk wrote:
Quote:
Uzywając def.
Np. tak:
default-config: #define UART_STOP_BITS 1
project-config: #include "default.h", #define UART_STOP_BITS 2
Redefiniowanie makra nową wartością jest nielegalne!!!
Masz rację, jak zwykle pisze skrótami i nie wszystko podaje. Oczywiscie
że jest #undef ale tylko dlatego że nie da się zrobić wprost #define
ponownie (w gcc da się). Samo undef jest wyłacznie wytrychem a nie
sednem metody. Sendem metody jest ponowne zdefiniowanie symbolu
nadpisując default.
Jak napisałem - dla mnie nie ma znaczenia którą metodą inkludowania
wybierzesz - obydwie sa mizerne i sprwadzają się do tej samej sieczki w
define.
Quote:
jest niezgodne np. z MISRA-C i w ogóle niepotrzebnie zaciemnia plik
konfiguracji użytkownika.
Nie mam targetu na misra-c. Więc ich zalecenia nie są dla mnie kluczowe.
Czy zaciemnia - to już inna sprawa. W odwrotnej konfiguracji zaciemnia
#ifdef. Tak czy inaczej - to nie wygląda dobrze.
Prawde mowiąc korzystam znacznie częściej ze statycznego polimorfizmu.
#define to odprysk w kilku miejscach.
Mam taki nieskończony projekcik (który strasznie zaniedbałem, ale
obiecuje poprawę) na SF, możesz sobie zerknąć co mam na myśli:
http://sourceforge.net/projects/microheap/
Quote:
sygnalizować już na wczesnym etapie rozpoznania konfiguracji użytkownika
np. zgodność wersji modułu bibliotecznego i jej użytkownika, czy wiele
innych parametrów o globalnym charakterze.
W moim przypadku nie sposób w momencie inkludowania default wykryć czy
dopuszczalne jest mieć uart o 2 bitach stopu. Przy czym "nie sposób" w
sensie, że jakikolwiek sposób powoduje wyciek wiedzy o hardware do
miejsca o innym poziomie abstrakcji. Im niej zależności tym lepiej dla
projektu.
Quote:
Rozmowa na temat czy "default.h" należy czy nie należy do implementacji
jest również czysto akademicka, tak jak i gdzie najlepiej określać
parametry default.
Z tej akademickiej dyskusji wynikają dobre praktyki. Dla mnie on nie
jest akademicka, bo dzieki takiemu podejsciu nie mam burdelu w kodzie.
mk
Guest
Sun May 06, 2012 8:25 pm
W dniu 2012-05-06 17:41, Andrzej Ekiert pisze:
Quote:
Dnia 06-05-2012 o 17:21:11 mk <reverse_lp.pw@myzskm> napisał(a):
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.
Skłaniam się ku pierwszej opcji: obligatoryjne określenie, nawet jeśli
zwykle będzie to przypisanie wartości domyślnej. Chcę jakoś sobie to
określanie usprawnić semi-automatyzując zadanie. Na razie mam tylko
autowykrywanie przez próbę kompilacji gdzie parametr nie jest
zdefiniowany. Chciałbym ułatwić sobie dodawanie tego parametru do plików
konfiguracyjnych,
Nie rozumiem nadal dlaczego nie posługiwać się wartością domyślną
konfiguracji zdefiniowaną gdzieś w module bibliotecznym...
#ifndef ALPHA
#error ALPHA parameter must be defined in your configuration file.
#endif
lub
#ifndef ALPHA
#warning Using defalut value X of ALPHA parameter. Specify an explict
definition of ALPHA parameter in your configuration file to suppress
this warning.
#define ALPHA X
#endif
lub po cichu
#ifndef ALPHA
#define ALPHA X
#endif
Quote:
oraz mieć wykrywanie ustawienia parametrów, które
stały się "obsolete".
#ifdef ALPHA
#warning ALPHA parameter is obsolete configuration value. Use BRAVO instead.
#endif
Jeśli wzbraniasz się przed konceptem konfiguracji domyślnej wtedy po
prostu pozostaje jakaś automatyczna modyfikacja plików wielu projektów
-- zwykle z wykorzystaniem języków skryptowych, albo zaawansowanego edytora.
W sumie można sobie wyobrazić jakiś system zarządzania konfiguracjami
np. w postaci jakiejś bazy danych czy coś... Nie nie spotkałem się z
czymś takim.
pzdr
mk
Andrzej Ekiert
Guest
Sun May 06, 2012 9:02 pm
Dnia 06-05-2012 o 22:25:15 mk <reverse_lp.pw@myzskm> napisał(a):
Quote:
Nie rozumiem nadal dlaczego nie posługiwać się wartością domyślną
konfiguracji zdefiniowaną gdzieś w module bibliotecznym...
#ifndef ALPHA
#error ALPHA parameter must be defined in your configuration file.
#endif
To w zasadzie mam teraz, tyle że warning lub błąd wynikający z
niezdefiniowania ALPHA generuje się samoczynnie w miejscu jego użycia
(bezwzględnie tego pilnuję). Nie trzeba więc nawet takiego #ifndefa pisać.
Quote:
#ifndef ALPHA
#warning Using defalut value X of ALPHA parameter. Specify an explict
definition of ALPHA parameter in your configuration file to suppress
this warning.
#define ALPHA X
#endif
Można. Ale wciąż wymaga ręcznego dopisania #define ALPHA wszędzie, jeśli
się nie chce tych warningów. A to mnie właśnie boli, ze względu na
bezproduktywną pracochłonność.
Quote:
lub po cichu
#ifndef ALPHA
#define ALPHA X
#endif
Ryzykowne - otrzymujący mój kod mogą nie zauważyć nowych opcji, które np.
mogą okrajać dotychczasową funkcjonalność. Sam mogę zapomnieć ustawić w
jednym z projektów.
Quote:
#ifdef ALPHA
#warning ALPHA parameter is obsolete configuration value. Use BRAVO
instead.
#endif
Można, ale wymaga trzymania całej historii. Średnio mi się podoba taki
śmietniczek.
Quote:
W sumie można sobie wyobrazić jakiś system zarządzania konfiguracjami
np. w postaci jakiejś bazy danych czy coś... Nie nie spotkałem się z
czymś takim.
No właśnie sobie to wyobraziłem. Chyba będę pisał, bo niczego sensownego
nie znalazłem. Jeśli mi się uda skończyć, to opublikuję pod GPL.
ae
Goto page Previous 1, 2, 3 Next