Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[Programowanie] Zarządzanie wieloma plikami projektu(ów)

Jado_one 25 Apr 2012 14:47 1756 19
Altium Designer Computer Controls
  • #1
    Jado_one
    Level 22  
    Witam,

    Przydałby się programik (lub skrypt), który umożliwiałby aktualizację (jednoczesną) procedur (bibliotek) w kilku projektach jednocześnie (nawet na różne procesory).

    Przykładowo zacząłem pisać daną bibliotekę w jednym projekcie, potem przeportowałem cały kod na inny procek, a tam dodałem nową funkcjonalność do biblioteki. Fajnie byłoby, żebym mógł wysłać tą nową funkcjonalność do starego projektu jednym naciśnięciem klawisza, zamiast przenosić żmudnie wszystkie nowe procedury na zasadzie copy/paste.
    Czy coś takiego jest możliwe?

    Przyglądałem się SVN, ale wygląda dość skomplikowanie - przynajmniej na początku...
    Czy są jakieś inne alternatywy?

    A może po prostu spróbować współdzielenia bibliotek?

    Szczerze mówiąc nie mam w tym względzie doświadczenia (jeszcze) :-)
  • Altium Designer Computer Controls
  • #2
    gaskoin
    Level 38  
    Można też to rozwiązać w sposób nieco magiczny :) zamiast plików użyć skrótów do nich. Polecam jednak gita (można robić lokalnie zmiany, po czym wszystkie na raz wrzucić na serwer), albo svna (tylko commit na server).
  • Altium Designer Computer Controls
  • #3
    mickpr
    Level 39  
    Możesz spróbować tak, jak to zrobione jest w ARM-ach (CMSIS).
    Warstwa sprzętu jest zależna od rodzaju konkretnego procesora ARM (LPCxxx, STM32xxx), a reszta jest taka sama dla całej rodziny procesorów (ARM Cortex).
    Możesz zdefiniować CPU i elementy sprzętowe i zrobić kompilacje warunkową.
    Najlepiej rzeczy niezależne trzymać w oddzielnym katalogu.
    Spójrz na CMSIS - może Ci się spodoba ten sposób. Jest prosty - ale działa.
  • #4
    tmf
    Moderator of Microcontroller designs
    Jado_one: Jeśli chodzi o biblioteki to najprościej jest zmienić sposób myślenia, to i problem zniknie. Skoro masz bibliotekę, potem ją rozszerzasz to nie kopiuj jej do nowego projektu - projekt ma używać przecież gotowego pliku lib i o źródłach biblioteki ma nie mieć pojęcia. Wtedy wszystkie zmiany robisz w jednym miejscu, możesz sobie je ślicznie wersjonować gitem lub svnem, a twoje finalne programy będą używać wyłącznie libów i nagłówków. Wtedy cała biblioteka jest w jednym miejscu i problemu nie ma. Dla skomplikowanych bibliotek warto dodać skrypty testowe dla automatycznego wykrywania regresji - google code coś takiego oferuje.
  • #5
    Jado_one
    Level 22  
    No własnie czuję, że czas na zmianę myślenia - jakby ponad konkretnym procesorem czy rodziną.
    Niektóre elementy programu są całkowicie niezależne od sprzętu - są w warstwie logicznej.
    Inne znowu zajmują się obsługą sprzętową jakiegoś konkretnego peryferium - np. wyświetlacza graficznego, scalaka, itp, itd....i w zasadzie jego obsługa poza czysto sprzętową częścią obsługującą np. I2C, w dalszej części jest taka sama (przesłanie bajtów inicjalizacyjnych, czy odczyt rejestrów spod konkretnych adresów, itp - niezależnie od procesora to pozostanie takie samo dla danego scalaka).

    Do tej pory to czy tamto - lepiej lub gorzej - wychodziło mi mimo woli podczas pisania programu, teraz może warto zrobić to planowo :-)
  • #6
    tmf
    Moderator of Microcontroller designs
    Zdecydowanie warto. W innym wątku Tymon wspominał o HAL - warto o tym pomyśleć. Nawet w ograniczonym zakresie. Wtedy np. takie I2C udostępniasz jako zestaw gotowych funkcji wyższego poziomu, a realizację sprzętową zostawiasz bibliotece. Kolejna biblioteka, która korzysta z I2C będzie zależna od nagłówków, a nie konkretnej implementacji sprzętowej - ta będzie zupełnie przeźroczysta. Oczywiście zawsze jest coś za coś - tu głównie proglemem jest konieczność dobrego przemyślenia interfejsu biblioteki, żeby co chwilę nie mieszać w nagłówkach, co czyni kolejne wersje biblioteki niekompatybilnymi.
  • #7
    Jado_one
    Level 22  
    Na pewno muszę się liczyć z pewnym narzutem programowo/czasowym na warstwę pośredniczącą.
    Pamiętam, że swojego czasu napisałem programik obsługujący HD44780 przez I2C (via PCF8574) i była tam procedurka sprawdzająca bity zajętości kontrolera I2C, a reszta procedur zajmująca się już wysyłaniem konkretnych danych do HD44780 korzystała z pośrednictwa tej procedurki, żeby sprawdzić "czy można wysyłać".
    Potem doszedłem do wniosku, że za dużo czasu marnuję na pośrednictwo i wprowadziłem sprawdzanie bitów zajętości bezpośrednio w w/w procedurkach - w ramach odchudzania kodu :-)
    No, ale z punktu widzenia przenoszalności kodu to bład - bo teraz chcąc przenieść ów kod na inny procek z innymi bitami od obsługi I2C, muszę zmieniać sprawdzanie flag w kilkunastu miejscach, zamiast w jednej procedurce sprawdzającej...

    Tak więc idea HAL powinna gdzieś tam w głowie utkwić i "lampka" zapalać się w odpowiednich momentach podczas pisania kodu ;-)
  • #8
    tmf
    Moderator of Microcontroller designs
    Narzuty są, ale niekoniecznie w tak prostych przykładach. Wystarczyło ową funkcję sprawdzającą zadeklarować jako static inline w pliku nagłówkowym i automatycznie byłaby umieszczana w kodzie wywołującym bez żadnych narzutów czasowych, a ciągle miałbyś jedną prostą bibliotekę. Z drugiej strony - czasami wygoda korzystania jest ważniejsza niż strata paru bajtów:) Teraz nawet małe procki mają więcej pamięci niż potrzeba i strata kilku bajtów nie boli. Narzut czasowy też nie zawsze jest istotny - np. takie I2C jest tak wolne, że strata nawet 10% czasu procesora właściwie na niczym się nie odbija.
  • #9
    Jado_one
    Level 22  
    No własnie - niektóre rzeczy można też zastąpić makrami - np. odwołania do pinów.
    W samej procedurze wywołujemy makro, a w pliku z makrami w razie czego podmieniamy definicje makra na odp. dla danego procka....
    Już częściowo to stosuję, ale trzeba będzie bardziej z definicji :-)
  • #10
    tmf
    Moderator of Microcontroller designs
    Przy czym przestrzegam cię przed makrami, to pozornie fajne jest ale pozbawiasz się kontroli typów i co gorsze, przekazywanie parametrów do makra wygląda inaczej niż do funkcji, co może prowadzić do błędów. Generalnie to co dają makra uzyskasz bezpiecznie poprzez definiowanie funkcji static inline w nagłówku.
  • #11
    Jado_one
    Level 22  
    gaskoin wrote:
    Można też to rozwiązać w sposób nieco magiczny :) zamiast plików użyć skrótów do nich. Polecam jednak gita (można robić lokalnie zmiany, po czym wszystkie na raz wrzucić na serwer), albo svna (tylko commit na server).

    No i wybrałem sposób "magiczny" :-)
    Plus kilka skryptow backupowych, robiących "snapshot" aktualnego stanu plikow źródłowych do pliku .tar.gz o nazwie w/g aktualnej daty, godziny, minuty.
    Svn na moim starym kompie za bardzo mi się zamulał w momencie commit z kilku plikow (i tak dobrze, że edytor ma wbudowaną obsluge svn i nie trzeba robic tego z konsoli). Może jak kiedyś zmienię kompa to do tego wrócę.
    Układ z linkami symbolicznymi ma tą zaletę, że można łączyć ten sam plik .c z różnymi plikami .h, w różnych projektach - dla kazdego procesora włączymy więc sobie pasujące do niego pliki nagłówkowe z definicjami rejestrów, przerwań, itp...

    No - zobaczymy jak sie to sprawdzi w praktyce :)
  • #12
    gaskoin
    Level 38  
    Spróbuj jednak w środowisku założyć dodatkowy projekt z samą biblioteką i tylko ją linkować w projektach końcowych. Nie wiem jakiego środowiska używasz, ale w elipsie i jego pochodnych jest możliwa równoległa budowa kilku projektów (pod warunkiem, że zaszły jakieś zmiany).

    Albo skorzystać z gita/svna.

    Taka magiczna sztuczka tylko w ostateczności.
  • #14
    Jado_one
    Level 22  
    No nie używam eclipsa i pochodnych - komp się zamulał za bardzo :-)
    Używam Geany.
    Zdaje się, że idę w każdym przypadku niestandardową ścieżką...hmmm...

    Ale linki do plików (a nawet linki do linków) to w linuxie normalka :-)
    To tak jak wskażnik do pliku ;-)
  • #15
    tymon_x
    Level 30  
    A jak przeniesiesz coś i stracisz referencję do pliku ? Albo będziesz to samo chciał zrobić pod Windows ? Nie wiem po co skrypty do backup, jak np. Mercurial pamięta wszystkie zmiany i zawsze do nich możesz wrócić. Każdą zmianę możesz opisać, żeby wiedzieć czego dotyczyła. W dodatku jak postawisz Sobie jakiś server, to ktoś lub Ty robi clone i ściąga Sobie projekt/biblioteki na dysk i wprowadza użyteczne zmiany. Powinieneś jednak z tym pokminić, bo teraz to przekombinowałeś dosłownie.

    Ja ma tak, że mam oddzielne katalogi pod określone rdzenie (ARM, MicroBlaze, AVR, ...). Jeśli wykonałem zmianę ogólnej biblioteki to robię update w projekcie i tyle. Kod od określonego uC/uP trzymam pod wyżej wymienionymi katalogami i update jest prowadzony między nimi (jak STM32 w katalogu ARM). I tyle, a nie zabawa z linkami i skryptami, brrr....

    Chyba najlepszym przykładem takiego projektu, będzie... sam Linux. Masz oddzielony kod pod arch oraz ogólne biblioteki warstwy wyżej. Całość natomiast jest zarządzana pod Git.

    Pod Linux linki to ostateczność, między innymi do bibliotek. Jakoś ls -al nie wskazuje mi, żeby ktoś nagminnie tego stosował.
  • #16
    Jado_one
    Level 22  
    tymon_x wrote:
    A jak przeniesiesz coś i stracisz referencję do pliku ? Albo będziesz to samo chciał zrobić pod Windows ?

    To program się nie skompiluje i bede wiedział, że coś jest nie tak. Do Windowsa raczej nie przewiduje powrotu ;-)

    tymon_x wrote:
    Nie wiem po co skrypty do backup, jak np. Mercurial pamięta wszystkie zmiany i zawsze do nich możesz wrócić. Każdą zmianę możesz opisać, żeby wiedzieć czego dotyczyła. W dodatku jak postawisz Sobie jakiś server, to ktoś lub Ty robi clone i ściąga Sobie projekt/biblioteki na dysk i wprowadza użyteczne zmiany. Powinieneś jednak z tym pokminić, bo teraz to przekombinowałeś dosłownie.

    Skrypt to już mam od dawna napisany, więc to nie był żaden problem - zresztą bardzo prosty w obsłudze :-)
    Wystarczy umieścic w katalogu nadrzędnym i sam pakuje jeden z katalogów podrzędnych, a wrzuca do drugiego. Ale mniejsza o to.

    Nie mówię, że nie podoba mi się program typu svn czy podobny - ale póki co - trochę za wolno działał (15-20s wstrzymania IDE na czas upgradu plików).
    Może to jeszcze kwestia konfiguracji - np. wyrzucenie niepotrzebnego upgradu plików typu .lss, .map, .sym, .lst - ktore po każdej kompilacji się zmieniają.

    tymon_x wrote:

    Ja ma tak, że mam oddzielne katalogi pod określone rdzenie (ARM, MicroBlaze, AVR, ...). Jeśli wykonałem zmianę ogólnej biblioteki to robię update w projekcie i tyle. Kod od określonego uC/uP trzymam pod wyżej wymienionymi katalogami i update jest prowadzony między nimi (jak STM32 w katalogu ARM). I tyle, a nie zabawa z linkami i skryptami, brrr....

    No bez przesady - ile trwa zrobienie linku symbolicznego do pliku?

    tymon_x wrote:

    Pod Linux linki to ostateczność, między innymi do bibliotek. Jakoś ls -al nie wskazuje mi, żeby ktoś nagminnie tego stosował.

    Oj - wystarczy wejść do /usr/lib i zobaczyć ile tam jest linków ..... Prawie co drugi...

    To wszystko wina kolegi Gaskoin - poddał mi pomysł, który mi się spodobał, a teraz się z niego wycofuje ;-)

    Możliwości jest wiele - na pewno stosowanie sposobu innego niz powszechnie przyjęte ma ten minus, że w momencie gdy chciałoby się zastosować jakąś prace grupową, czy inną współpracę, to te sposoby będą niekompatybilne.

    Z drugiej strony - jedno nie wyklucza drugiego - mogę mieć zarówno linki/skrypty jak i svn czy inne ustrojstwo.

    W każdym razie na pewno przyjrzę się jeszcze temu Mercurial/Git - może mi lepiej podpasują.
  • #17
    tymon_x
    Level 30  
    Jado_one wrote:
    Oj - wystarczy wejść do /usr/lib i zobaczyć ile tam jest linków ..... Prawie co drugi...

    Tak, tylko że to są biblioteki *.so. Teraz wejdź /usr/include czy do źródeł, i praktycznie nikt tak nie robi, że wiązać to linkami. Wiedziałem po prostu, że powołasz się na ten folder...

    SVN odradzam, lepiej użyć czegoś z filozofią rozproszoną jak Git/Mercurial niż scentralizowaną. Idealnie do tego się nadają. Dlatego ekipa Linus Torvalds opracowała Git. Hg jest dużo szybszy, jego jedną z cech jest It is fast and powerful. Wszytko to co robisz, żeby modyfikować biblioteki (linki, skrypty, backup) i wiele więcej masz dostępne pod dosłownie jedną komendą.

    Ale jak Ci tam wygodnie,...

    Jado_one wrote:
    To wszystko wina kolegi Gaskoin - poddał mi pomysł, który mi się spodobał, a teraz się z niego wycofuje

    gaskoin wrote:
    Można też to rozwiązać w sposób nieco magiczny zamiast plików użyć skrótów do nich. Polecam jednak gita (można robić lokalnie zmiany, po czym wszystkie na raz wrzucić na serwer), albo svna (tylko commit na server).

    Niom...

    Jado_one wrote:
    To program się nie skompiluje i bede wiedział, że coś jest nie tak. Do Windowsa raczej nie przewiduje powrotu

    Ale dużo osób z niego korzysta. Jakbym w pracy tak kombinował z dowiązaniami, to by mnie żywcem z masakrowali. Chcesz multi-liba pod różne architektury, a ograniczasz się do jednego OS ?
  • #18
    Jado_one
    Level 22  
    tymon_x wrote:

    SVN odradzam, lepiej użyć czegoś z filozofią rozproszoną jak Git/Mercurial niż scentralizowaną. Idealnie do tego się nadają. Dlatego ekipa Linus Torvalds opracowała Git. Hg jest dużo szybszy, jego jedną z cech jest It is fast and powerful. Wszytko to co robisz, żeby modyfikować biblioteki (linki, skrypty, backup) i wiele więcej masz dostępne pod dosłownie jedną komendą.

    Zainstalowałem HG :-) Teraz trzeba będzie trochę poczytać i sprawdzić jak się sprawuje.

    tymon_x wrote:

    Ale dużo osób z niego korzysta. Jakbym w pracy tak kombinował z dowiązaniami, to by mnie żywcem z masakrowali. Chcesz multi-liba pod różne architektury, a ograniczasz się do jednego OS ?

    W pracy to sie dostosowuje do tego co tam jest - jak mi każa na windowsie, to będę na windowsie. A z drugiej strony jakbym to ja był pracodawcą i zatrudniał ludzi, to musieliby się dostosować do tego co ja wymagam - taka rzeczywistość.

    BTW: jak jest z korzystaniem w firmach z oprogramowania pod Linuxa? Nikt nie korzysta? Mam na mysli programy dla elektroników.
  • #19
    tymon_x
    Level 30  
    Jado_one wrote:
    W pracy to sie dostosowuje do tego co tam jest - jak mi każa na windowsie, to będę na windowsie. A z drugiej strony jakbym to ja był pracodawcą i zatrudniał ludzi, to musieliby się dostosować do tego co ja wymagam - taka rzeczywistość.

    BTW: jak jest z korzystaniem w firmach z oprogramowania pod Linuxa? Nikt nie korzysta? Mam na mysli programy dla elektroników.

    Taki narzut od strony pracodawcy jest mi obcy (przynajmniej ja nigdy czegoś takiego nie uświadczyłem). Raczej, jeśli narzędzie pod dany projekt są dostępne tylko pod Windows, to siłą rzeczy korzystasz z tego systemu. Chyba lepiej korzystać z OS, na którym wydajniej będziesz pracować. Nawet tyczy się to różnych dystrybucji. Sam mam podzieloną partycję na Windows 7 i dwa OS Linux. I tylko w ostateczności siedzę na tym pierwszym.

    Tam gdzie pracowałem, to był zawsze mix. Jeśli chodzi o programowanie, czy ktoś siedzi na Mac/Windows/Linux zależy już od własnych preferencji. Gorzej wyspecjalizowanymi programami jak Altium. Ale na przykład do projektowania ASIC masz dostępne pod Linux oraz Windows (Synopsys). Do FPGA też są dostępne narzędzia na oba systemy.

    Więc zależy jakie programy, dla jakich elektroników i w jakiej firmie. Małe biuro będzie używało KiCad (Linux), a duża Altium (Windows) do PCB. Inna darmowego GCC+IDE, a druga komercyjnego pakietu Keil.

    Ale część jest wspólna jak *.c oraz *.h. Więc robisz według mnie niepotrzebny narzut (skrypty, linki), hg działa tak samo dobrze pod Windows oraz Linux.
  • #20
    Jado_one
    Level 22  
    No niezły jest ten Mercurial - tak czy inaczej warto poznać.
    Znalazłem niezły materiał o nim w sieci: http://hgbook.red-bean.com/read/

    Trochę czasu musi upłynąć zanim się go dobrze pozna - opcji sporo, o pomyłkę łatwo :-)
    Zainstalowałem nakładkę graficzną: Gwsmhg - ale tak czy inaczej dobre rozumienie komend jest wskazane.