logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

5 powodów, dla których warto budować własne środowisko do kodowania w C/C++

ghost666 20 Kwi 2023 03:24 3339 54
  • 5 powodów, dla których warto budować własne środowisko do kodowania w C/C++
    Kiedyś programiści tworzyli cały swój kod od podstaw. Było to trudne, czasochłonne i niezbyt przyjemne dla osób pracujących z systemami embedded. Deweloperzy systemów wbudowanych walczyli o zmianę, a w reakcji na to dostawcy mikrokontrolerów generowali środowiska do kompilacji czy platformy abstrakcji sprzętowej dla niskopoziomowego kodu startowego i środowiska kompilacji. Programiści byli zadowoleni, gdyż dzięki temu mogli szybciej pisać kod dla swoich aplikacji. Chociaż udostępnienie wstępnie skonfigurowanego środowiska kompilacji jest pomocne, istnieje pięć czynników, dla których zespoły programistów powinny rozważyć zbudowanie własnego, dla pisania oprogramowania w C/C++, zamiast wykorzystywać to zapewniane przez dostawcę mikrokontrolerów.

    Powód nr 1 — zrozumienie podstaw aplikacji

    Wiele podmiotów przed chwilą wskazanych wykonało świetną robotę, tworząc platformy programistyczne, których osoby zainteresowane mogą używać do opracowywania swoich produktów wbudowanych. W końcu ich klienci odnoszą korzyści, jeśli producent przeprowadzi za nich wszystkie prace zwykle realizowane w każdym produkcie. Mowa tu o pisaniu skryptów linkera, przygotowaniu kodu startowego, linkerze dla standardowych bibliotek czy inicjowaniu mikrokontrolera. Klient może zignorować ten standardowy kod i skoncentrować się na szybszym stworzeniu logiki aplikacji. Dzięki czemu produkt prędzej wejdzie na rynek i ogólnie sprzeda się więcej mikrokontrolerów.

    Problemem, którego wielu mogło być już świadkiem, jest to, że programiści często ignorują ten kod niskiego poziomu. Tudzież tracą go z oczu, przez co nie wiedzą, jak działa ich środowisko kompilacji, a nawet te jego elementy, które są krytycznie powiązane z ich projektem! Być może nawet gorzej — kod, napisany przez dostawcę mikrokontrolerów, został opracowany jako ogólny, który jest uniwersalnym rozwiązaniem, co oznacza, że może on nie współpracować idealnie z żadną konkretną aplikacją — jak coś jest do wszystkiego, to jest do niczego...

    Budowanie środowiska kompilacji, w którym tworzy się konsolidatory, kod startowy, konfiguruje część wykonawczą C/C++ i generuje pliki makefile, zapewnia zrozumienie podstaw aplikacji i całości. Wiadomo wtedy, które sekcje tam są i dlaczego je wykorzystano. Dzięki temu deweloper lepiej zdaje sobie sprawę, jakiego zestawu i flag C/C++ używa do konstruowania swojej aplikacji i dlaczego. W rzeczywistości można dowiedzieć się więcej nawet o środowisku wykonawczym C/C++ i o tym, jak może ono wpływać na rozmiar generowanego kodu i wydajność jego wykonywania. Jeśli po prostu skorzysta się z tego, co dostarcza producent bez przeglądania, można przegapić istotne szczegóły.

    Powód nr 2 — optymalizacja kodu

    Domyślnie wiele środowisk kompilacji udostępnianych programistom może być przygotowanych do programowania wbudowanego, ale często są one konfigurowane jako rozwiązanie ogólne i uniwersalne. Założenie takie ma na celu zaspokojenie potrzeb 'przeciętnego dewelopera' lub 'typowej firmy'. Niestety, rezultatem może nierzadko być kod przepełniony niepotrzebnymi funkcjami bibliotecznymi, a nawet zbyt skomplikowany do odczytania. Na przykład — wystarczy spojrzeć na dużą część takowego abstrakcji sprzętowej, choć też na inne, dostarczanego przez dostawcę. Będzie on zawierać standardowe wywołania systemowe z biblioteki C, takie jak printf, _exit, _kill, _read, _write itp. Użycie minimalnej implementacji tych wywołań może z łatwością dodać ponad 10 kilobajtów przestrzeni kodu. Być może nie jest to wielki problem dla wielu zespołów pracujących nad najnowocześniejszymi procesorami 32-bitowymi, ale dla reszty branży systemów wbudowanych może to oznaczać różnicę pomiędzy powodzeniem projektu a porażką. (Często ma miejsce sytuacja, gdzie tworząc koncept bazowy z kodu platformy, który mruga tylko diodą LED, stwierdza się, że kompiluje się do ponad 60 kilobajtów!)

    Inni programiści zajmujący się optymalizacją nieraz pomijają pewne sztuczki wydajnościowe, które domyślnie nie działają w ich predefiniowanym systemie kompilacji. Na przykład, jeśli pracuję z częścią ze specjalną pamięcią RAM typu no-wait, można skonfigurować kod startowy, aby umieścić w niej wektory przerwań, aby uzyskać bardziej efektywne, deterministyczne zachowanie w czasie ich wykonywania. Niestety kod dostarczany przez dostawcę często tego nie robi. Jeśli nie zbudujemy lub nie zbadamy dokładnie swojego środowiska, marnujemy cykle zegara i prawdopodobnie wydłużamy period reakcji systemu na przerwanie.

    Powód nr 3 — łatwiejsza integracja z procesami Agile i DevOps

    Korzystanie z metodyk zwinnych (Agile) i ujęć DevOps to współcześnie niezbędny proces przy produkcji oprogramowania, który staje się również popularny w wielu zespołach zajmujących się aplikacjami wbudowanymi. Zwinne metodologie zyskujące uznanie w społeczności systemów wbudowanych dotyczą między innymi ujęcia takiego jak programowanie sterowane testami (TDD). DevOpsing obejmuje znacznie więcej niż tylko ciągłą integrację i wdrażanie (CI/CD), ale na tym skupia się większość zespołów, użytkujących te narzędzia.

    Korzystając ze środowiska dostarczonego przez producenta mikrokontrolera, spożytkowanie procesów TDD czy CI/CD może być bardziej kłopotliwe i złożone. Dzieje się tak dlatego, że nie biorą one pod uwagę takich ujęć, które wiążą się z wykonaniem pewnych dodatkowych kroków, aby dostarczyć produkt zgodnie ze zwinną metodologią, tylko to, czego po prostu potrzeba, aby ich procesor zwyczajnie działał. Rezultatem może być środowisko kompilacji, które nie współgra dobrze z innymi procesami i potrzebami. Zespoły nierzadko zmagają się z obejściem tego problemu. A czasem nawet wykorzystują dwa różne środowiska, aby wszystkie te procesy i narzędzia dobrze do siebie pasowały.

    Powód nr 4 — elastyczność

    Niekiedy zdarza się, że całość, która już została zbudowana, była trudna do dostosowania do zmieniających się wymagań. Czasami w systemie kompilacji jest tak wiele małych haczyków, że usprawnienie go zajęłoby dwa razy więcej czasu niż zaczynanie od zera. Na przykład można chcieć wyłączyć bibliotekę, ale okazuje się, że powoduje to kilkadziesiąt błędów kompilacji, które zmuszają do rozwiązania sporej liczby zależności, co wymaga wielu godzin pracy.

    Jednym z podejść, które wydaje się bardzo pomocne, jest wykorzystanie elastyczności IDE. Często można stwierdzić, że różni programiści mają odmienne preferencje co do spożytkowania IDE i edytorów tekstu, których chcą używać. Na przykład ktoś może polubić Sublime Text, druga osoba pisze w Visual Studio Code lub stawia na jeszcze inne IDE dostarczone przez dostawcę mikrokontrolera. Deweloperzy nieraz żartują i kłócą się, próbując uzyskać preferowane narzędzie jako wybór całego zespołu. Jeśli skonstruujemy swoje środowisko od podstaw, każdy może korzystać z cenionego przez siebie narzędzia, które może pomóc poprawić wydajność programistów.

    Powód nr 5 — zbuduj dostosowanie systemu

    Dla wielu deweloperów najważniejszym powodem przygotowywania własnego środowiska do kodowania C/C++ jest możliwość dokonywania adaptacji. Jak wspomniano wcześniej, nie ma nigdy dwóch takich samych projektów. Istnieją pewne podobieństwa między poszczególnymi, ale zawsze można radykalnie zoptymalizować rozmiar kodu i/lub jego wydajność, dostosowując system kompilacji. Czasami nie uda się od razu zrozumieć, jakie modyfikacje są potrzebne, dopóki nie zacznie się stawiać środowiska od zera. Wielu z nas proces taki może otworzyć oczy na zyski z danego przeobrażenia.

    Istnieje wiele dostosowań do rozważenia, takich jak:

    * Środowisko skonfigurowane z kontenerami Dockerowymi;
    * Flagi dla assemblera;
    * Flagi dla C/C++;
    * Integracje wybranych bibliotek;
    * Sposób obsługi kodu startowego mikrokontrolera;
    * Integracja dedykowanej tabeli wektorów;
    * Integracja z procesami TDD;
    * Integracja z procesami ciągłej integracji czy ciągłego wdrożenia (CI/CD);
    * Analiza kodu;
    * Itd.

    Możliwość dostosowania środowiska C/C++ i systemu kompilacji może znacząco wpłynąć na powodzenie projektu.

    Podsumowanie

    Tworzenie niestandardowego systemu do kompilacji dla aplikacji wbudowanej ma wiele zalet. Powyżej wymieniono kilka z nich, które, miejmy nadzieję, wzbudziły zainteresowanie czytających programistów systemów wbudowanych. Z początku podjęcie takiego przedsięwzięcia może wydawać się skomplikowane i obarczone potencjalnymi, własnymi problemami. Na szczęście proces ten jest znacznie mniej zawiły, niż mogłoby się wydawać. Niestandardowy system kompilacji można stworzyć i wdrożyć dla prawie każdego wbudowanego procesora w mniej niż tydzień. Co więcej, omawiana całość jest wysoce dedykowanym, dobrze zoptymalizowanym ujęciem, które może pomóc w przygotowaniu podstaw dla naszej aplikacji i zbudowaniu procesów mogących wspierać produkty przez lata.

    Źródło: https://www.embedded.com/5-reasons-to-build-your-own-c-c-environment/

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • #2 20548106
    DJ.TRoX
    Poziom 18  
    Tworzenie embedded jest nierozerwanie połączone ze edycją makefila, żonglowaniem sekcjami i setką innych rzeczy o których istnieniu chyba nie wie nikt inny. Każdy kto popełnił choć jeden bootloader wie o o czym mowa. To co mnie osobiście boli, to to że każda platforma jest inna i po każdej przesiadce sporo czasu mi zajmuje ponowna "asymilacja". Wydaje mi się, że mało kto ma tyle czasu, żeby poświęcać go na czynności o których pisze autor. Po drugie, kto ma tyle szczęścia, żeby pracować wyłącznie z jedną rodziną procesorów, żeby tej pracy nie wykonywać ponownie.
  • #3 20548166
    Urgon
    Poziom 38  
    AVE...

    Może w przypadku profesjonalistów lub przy bardzo zaawansowanych projektach używających czegoś w rodzaju RPi. W końcu do takich osób jest skierowany ten artykuł. Jako programista-amator nigdy nie musiałem ruszać makefile, ani budować środowiska od zera, bo mam gotowe IDE od producenta układów. Po to właśnie producenci przygotowują te środowiska. Na dobrą sprawę to nie widzę zbyt wielu sytuacji, by nawet profesjonalista musiał budować swoje środowisko od zera i zagłębiać się w tajniki zaawansowanych ustawień i innych szczegółów, które zwykłe IDE samo ustawi. Jeśli sytuacja tego nie wymaga, to nie ma sensu się tym zajmować i tracić czas na mało istotne detale, gdy czeka pisanie właściwego kodu...
  • #4 20548264
    khoam
    Poziom 42  
    DJ.TRoX napisał:
    To co mnie osobiście boli, to to że każda platforma jest inna i po każdej przesiadce sporo czasu mi zajmuje ponowna "asymilacja". Wydaje mi się, że mało kto ma tyle czasu, żeby poświęcać go na czynności o których pisze autor.

    W większych firmach są osoby odpowiedzialne za przygotowywanie oraz aktualizacje toolchain i ustawień IDE dla określonego embedded tak, żeby "świeży" programista nie musiał się już skupiać na konfiguracji środowiska i powielać tych samych czynności.
  • #5 20548413
    JacekCz
    Poziom 42  
    Ta głęboka wiara typowego C-programisty "ja Zoś Samoś" zrobię lepiej, niż to co jest na rynku.
    Po nabraniu doświadczenia, po kontakcie w innymi ekosystemami się rezygnuje z tej religii - albo W WIĘKSZEJ FIRMIE się zostaje kimś niszowym jak pisze @khoam
  • #6 20548549
    Mlody_Zdolny
    Poziom 30  
    Urgon napisał:
    Na dobrą sprawę to nie widzę zbyt wielu sytuacji, by nawet profesjonalista musiał budować swoje środowisko od zera i zagłębiać się w tajniki zaawansowanych ustawień i innych szczegółów, które zwykłe IDE samo ustawi.

    Wystarczy, że projekt jest wersjonowany, jest testowany i pracuje nad nim kilka osób albo nawet kilka teamów.
    Wtedy pojawia się nagle masa problemów typu: co kompilować? jak kompilować? co testować? gdzie kompilować?
    Z pomocą samego IDE tego się nie ogarnie, wkracza Continous Integration z różnymi środowiskami na każdym etapie produkcji oprogramowania, np. Test, dev, preprod, prod, itd.
  • #7 20548600
    Urgon
    Poziom 38  
    AVE...

    Oczywiście, jak pracujesz zespołowo, to trzeba się w takie rzeczy bawić. Ale do tego są gotowe narzędzia z gotowymi konfiguracjami, więc nie trzeba całości budować od zera. Nawet moje IDE do układów Microchip ma funkcje do zarządzania wersjami kodu (o ile dobrze pamiętam), choć sam z tego nie korzystam, bo nie widzę powodu...

    Ostatnio miałem do czynienia z takim projektem, co jest przygotowany dla pięćdziesięciu różnych platform z setką parametrów do ustawienia, domyślnymi konfiguracjami dla tych platform i z parametrami rozbitymi na dziesięć plików, w każdym kilkadziesiąt komend #define, część skomentowana, część nie, i nie ma do tego sensownej dokumentacji, bo to programiści programistom zgotowali ten los. Poddałem się po godzinie i znalazłem skompilowany już plik dla mojej platformy, choć jest w ciut starszej wersji.

    Inny przykład, jest sobie program DAW Open Source. Twórcy udostępniają go dla Linuxa za darmo, dla Windows za opłatą, ale jak ktoś nie chce płacić, to może pobrać kod i skompilować samemu. W praktyce wygląda to tak, że jednemu człowiekowi zajęło to ponad dwanaście godzin, przy czym uzyskał sporą pomoc od developerów programu. Ale na ich prośbę wersji skompilowanej nie udostępnił...
  • #8 20549115
    DJ.TRoX
    Poziom 18  
    khoam napisał:
    W większych firmach są osoby odpowiedzialne za przygotowywanie oraz aktualizacje toolchain i ustawień IDE dla określonego embedded tak, żeby "świeży" programista nie musiał się już skupiać na konfiguracji środowiska i powielać tych samych czynności.


    I tak powinno być. Świadomość, że tracisz czas na rzeczy, które nic nie wnoszą zabija psychikę. Wiesz co masz zrobić, wiesz jak a legniesz na guzikologi. Później tłumacz się, że coś co jest względnie proste zjadło kosmiczną ilość czasu.
  • #9 20549175
    pepedombo
    Poziom 11  
    DJ.TRoX napisał:
    khoam napisał:
    W większych firmach są osoby odpowiedzialne za przygotowywanie oraz aktualizacje toolchain i ustawień IDE dla określonego embedded tak, żeby "świeży" programista nie musiał się już skupiać na konfiguracji środowiska i powielać tych samych czynności.


    I tak powinno być. Świadomość, że tracisz czas na rzeczy, które nic nie wnoszą zabija psychikę. Wiesz co masz zrobić, wiesz jak a legniesz na guzikologi. Później tłumacz się, że coś co jest względnie proste zjadło kosmiczną ilość czasu.


    Jedno z niewielu sensownych rozwiazan. Embedded to chaos i bajzel. MS zrobil dx'a + visual studio, ktostam opengl/vulkan i stos bylejakich IDE, gdzie zamiast malpowac visual studio to robia po swojemu. Moze to kwestia opinii, ale jezeli uczylem sie na ms, dx, visual studio, to jako dowod swojego kalectwa moge przedstawic kompletnie bylejakie IDE qt 5.7 niezbyt gotowe na przyjscie takiego Pana, bo dali mi F2 zamiast F12.

    Analogia podobna do windowsa i linuxa, w kontekscie takim, ze mowimy, ze cos juz ma ksztalt i wiele lat za soba. Kiedys linux robil wszystko na odwrot. Gdyby malpowali wszystko jak leci i upodobniali sie do windowsa (swojego glownego konkurenta), z ktorego i tak wiekszosc korzysta, dzisiaj systemy linuxowe bylyby duzo chetniej i latwiej przyswajalne. Gdzies w koncu poszli po rozum, ale chyba juz nie jestem w temacie i zapewne nadal ciezko z tym, co mam na mysli.

    Embedded moze rosnie, ale to nadal ten sam konflikt i ten sam nielad.
  • #10 20549216
    DJ.TRoX
    Poziom 18  
    Embedded zazwyczaj jest chaosem i bajzlem ale wcale tak nie musi być. Wydaje mi się, że wynika to z tego, że większość ludzi (łącznie ze mną) zajmują się tym jako kolejny etap ewolucji elektroniki. Nigdy nie wiązałem swojej przyszłości z programowaniem, ale tak wyszło, że musiałem od początku kariery. Kiedy projektujesz płytkę i twój kod jedyne co ma zrobić to sprawdzić poprawność sprzętu, to nie zależy Ci na żadnej estetyce. I to jest najgorszy z możliwych etapów rozwoju jaki można zaliczyć. Oczywiście to Ty przekopiesz się przez najczarniejsze meandry a później przyjdzie ktoś i zrobi z tego docelowy soft. Niestety wiele osób ewoluuje z tego etapu do budowania bardziej złożonych projektów nie zmieniając nawyków. Niektórzy potrafią nawet uzasadnić celowość trzymania całego projektu w main.c o długości tysięcy linii i jakoś nad tym panować. Warto pamiętać, że embedded to szerokie pojęcie poczynając od zegarka na AVR, przez Cortexy, kończąc na kobyłach z zakutym linuxem. Czy wszędzie jest bajzel? Na pewno jest tam gdzie da się żeby był. Kolejna kwestia jest taka, że rynek na to jest taki sobie, przynajmniej u nas. Nie masz szalonej rotacji ludzi i dużej wymiany myśli. Niektórzy nawet nie wiedzą, że coś da się zrobić lepiej. Mnie życie nauczyło, że porządek to oszczędność czasu. Kilka dni temu kolega mnie skrytykował, że jak mogłem rozbić projekt na 18 plików skoro to procesor za 0.5$. Bo przesadzam, bo tracę czas, bo poco tak komplikować...
  • #11 20549338
    elektryku5
    Poziom 39  
    DJ.TRoX napisał:
    I tak powinno być. Świadomość, że tracisz czas na rzeczy, które nic nie wnoszą zabija psychikę. Wiesz co masz zrobić, wiesz jak a legniesz na guzikologi. Później tłumacz się, że coś co jest względnie proste zjadło kosmiczną ilość czasu.


    Zabawa w makefile podobała mi się w czasach WinAVR, jedyne co musiałem zrobić, to wpisać model MCU, F_CPU i nazwy plików, jak zacząłem bawić się w STMy, to chęć dłubania w makefile wyparowała bardzo szybko na cześć gotowych środowisk.

    Ostatnio bawiłem się w kompilację Optiboot, stare wersje po drobnych kombinacjach się kompilowały, przy ostatniej (wówczas) wersji już nie było tak różowo i skończyło się na kompilacji w AS7.
  • #12 20549444
    Urgon
    Poziom 38  
    DJ.TRoX napisał:
    Embedded zazwyczaj jest chaosem i bajzlem ale wcale tak nie musi być. Wydaje mi się, że wynika to z tego, że większość ludzi (łącznie ze mną) zajmują się tym jako kolejny etap ewolucji elektroniki.

    Hobbyści tak, ale od lat programowanie systemów embedded jest częścią studiów kierunkowych związanych z elektroniką. Na początku bardzo popularne były zestawy z mikroprocesorami '51, ale od jakiegoś czasu do tego dołożone są układy bardziej zaawansowane, wliczając w to ARM. Co do hobbystów, to połowa zaczynała 15-20 lat temu z kursem Bascom w EdW, młodsze pokolenia zaś uczyły się i uczą na Arduino. I czasem ci hobbyści stają się profesjonalistami biorąc ze sobą wszelkie dobre i złe nawyki.

    DJ.TRoX napisał:
    Nigdy nie wiązałem swojej przyszłości z programowaniem, ale tak wyszło, że musiałem od początku kariery. Kiedy projektujesz płytkę i twój kod jedyne co ma zrobić to sprawdzić poprawność sprzętu, to nie zależy Ci na żadnej estetyce. I to jest najgorszy z możliwych etapów rozwoju jaki można zaliczyć.

    Dobre IDE dba o formatowanie kodu do czytelnej postaci. Większym problemem jest brak dokumentacji, bo przez lata "stare wygi" wmawiały początkującym, że kod jest swoją własną dokumentacją. Drugim grzechem, i czymś, z czym sam miałem problemy, jest stosowanie bezsensownych i nic nie mówiących nazw zmiennych czy funkcji. Chyba w jednym z pierwszych projektów miałem zmienne m, n, mm, Mm, mn i nm.

    DJ.TRoX napisał:
    Oczywiście to Ty przekopiesz się przez najczarniejsze meandry a później przyjdzie ktoś i zrobi z tego docelowy soft. Niestety wiele osób ewoluuje z tego etapu do budowania bardziej złożonych projektów nie zmieniając nawyków.

    Ba, niektórzy nie potrafią zmienić narzędzi na bardziej odpowiednie/wydajne, bo myślą, że nauka nowego języka programowania to ekstremalne wyzwanie. Stąd cała masa projektów, które zyskałyby na przejściu z Pythona na C++/C# czy nawet VB. Ciekawi mnie, jak wielu młodych programistów embedded zapytało się swoich szefów "Przepraszam, ale czemu tu nie ma Bascoma?"...

    DJ.TRoX napisał:
    Niektórzy potrafią nawet uzasadnić celowość trzymania całego projektu w main.c o długości tysięcy linii i jakoś nad tym panować.

    To pikuś. Większość systemów bankowych i finansowych stoi na COBOLu, gdzie plik źródłowy ma od kilkudziesięciu tysięcy linijek kodu wzwyż. Kod musiał być swoją dokumentacją, bo każdy bajt oszczędzony to bajt lepiej wykorzystany. Programiści, co w tym kodowali albo nie żyją, albo są na emeryturze od 20+ lat.
    Swoją szosą też wszystko trzymam w main.c, ale żaden z programów nie miał więcej jak 400 linijek, z czego 1/4 to komentarze i puste linie dla estetyki...

    DJ.TRoX napisał:
    Kolejna kwestia jest taka, że rynek na to jest taki sobie, przynajmniej u nas. Nie masz szalonej rotacji ludzi i dużej wymiany myśli. Niektórzy nawet nie wiedzą, że coś da się zrobić lepiej. Mnie życie nauczyło, że porządek to oszczędność czasu.

    Brak rotacji w kadrach to akurat coś dobrego, bo oznacza stabilność zatrudnienia. Wymiana myśli wymaga też odpowiedniej kultury komunikacji, czego brak. Jest to tak stary problem, że ostatnio widziałem filmik z lat bodaj 70tych na temat zarówno poprawnego kodowania, jak i komunikacji dobrych praktyk w sposób, który nikogo nie urazi.
    Przesadna dbałość o porządek może prowadzić do niepotrzebnego marnowania czasu.

    DJ.TRoX napisał:
    Kilka dni temu kolega mnie skrytykował, że jak mogłem rozbić projekt na 18 plików skoro to procesor za 0.5$. Bo przesadzam, bo tracę czas, bo poco tak komplikować...

    Jeśli to był złożony projekt na jakimś szybkim ARMie, to okej. Jeśli zegarek na AVR, to trochę przeginasz. Chyba że includowałeś standardowe biblioteki do obsługi peryferiów.
  • #13 20549537
    khoam
    Poziom 42  
    Cytat:
    Stąd cała masa projektów, które zyskałyby na przejściu z Pythona na C++/C# czy nawet VB.

    Przejście z Pythona na VB czy C# to, jak w powiedzeniu: "zamienił stryjek siekierkę na kijek".

    Cytat:
    Ciekawi mnie, jak wielu młodych programistów embedded zapytało się swoich szefów "Przepraszam, ale czemu tu nie ma Bascoma?"...

    Całe szczęście, że już nie padają takie pytania. To by dyskwalifikowało takiego "programistę". W BASCOM się koduje, a nie programuje.

    Dodano po 7 [minuty]:

    DJ.TRoX napisał:
    Warto pamiętać, że embedded to szerokie pojęcie poczynając od zegarka na AVR, przez Cortexy, kończąc na kobyłach z zakutym linuxem. Czy wszędzie jest bajzel? Na pewno jest tam gdzie da się żeby był.

    Proponuję zapoznać się z projektem PlatformIO, który stawia sobie za cel, być może zbyt ambitny, aby taka unifikacja środowiska IDE była możliwa dla szerokiej grupy mikroprocesorów.
  • #14 20549564
    Mlody_Zdolny
    Poziom 30  
    Urgon napisał:
    niektórzy nie potrafią zmienić narzędzi na bardziej odpowiednie/wydajne, bo myślą, że nauka nowego języka programowania to ekstremalne wyzwanie. Stąd cała masa projektów, które zyskałyby na przejściu z Pythona na C++/C# czy nawet VB.

    Chyba nie do końca wiesz o czym piszesz. Performance to jedno a złożoność programu źródłowego drugie. Obecnie C++ w porównaniu z Pythonem to już prawie nisza.
    Zakładając, że programistów Pythona na rynku pracy jest 5x więcej niż C++, a program źródłowy w C++ i robiący to samo w Pythonie jest 4x bardziej złożony wychodzi, że projekt w Pythonie jest tańszy i bardziej elastyczny. A to jest istotne w krótkich projektach, np. pisaniu jakiegoś toola, albo w wytrenowaniu jakiejś instancji AI. Pisząc tego typu narzędzia, które są w ciągłym rozwoju, w C++ można szybko ugrzęznąć w zawiłościach wskaźników, referencji i całej masie zbędnego kodu.
    Porównanie Hello World C++ i Pythona:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Kod: Python
    Zaloguj się, aby zobaczyć kod


    Poruszanie się po tablicy asocjacyjnej:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Kod: Python
    Zaloguj się, aby zobaczyć kod


    Urgon napisał:
    Ciekawi mnie, jak wielu młodych programistów embedded zapytało się swoich szefów "Przepraszam, ale czemu tu nie ma Bascoma?"...

    Jeżeli pracodawca w ramach rekrutacji stosuje łapanki na ulicy to rzeczywiście mogłoby to mieć miejsce. Ale zwykle jest tak, że takie rzeczy wychodzą już na pierwszej rozmowie, kiedy delikwent chwali się, że jest BASCOMowcem.
    Ja osobiście nic nie mam do Bascoma, kiedyś nawet parę rzeczy napisałem, ale przez myśl by mi nie przeszło, żeby używać tego do poważniejszych zastosowań.
  • #15 20549572
    khoam
    Poziom 42  
    Mlody_Zdolny napisał:
    Pisząc tego typu narzędzia, które są w ciągłym rozwoju, w C++ można szybko ugrzęznąć w zawiłościach wskaźników, referencji i całej masie zbędnego kodu.

    Być może można, ale rzadko jest to "zbędny" kod. Parafrazując powyższe stwierdzenie: "w Python można szybko ugrzęznąć z powodu braku pamięci, zbyt wolnego działania programu i niemożliwości zrobienia tysiąca rzeczy bez odpowiednich bibliotek napisanych w C".
  • #16 20549599
    Mlody_Zdolny
    Poziom 30  
    khoam napisał:
    w Python można szybko ugrzęznąć z powodu braku pamięci, zbyt wolnego działania programu i niemożliwości zrobienia tysiąca rzeczy bez odpowiednich bibliotek napisanych w C

    A to niby programy pisane w C/C++ nie potrzebują pamięci?
    Też potrzebują i też wywalają się z powodu jej braku, i to często nie z powodu ogromnych struktur danych lecz memory leaków spowodowanych niewłaściwie zrealizowanym zwalnianiem pamięci.
  • #17 20549606
    khoam
    Poziom 42  
    Mlody_Zdolny napisał:
    A to niby programy pisane w C/C++ nie potrzebują pamięci?

    Nie chodzi o to, czy "potrzebują", ale ile w porównaniu z programami napisanymi w Python. Mam tu na myśli środowisko embedded.

    Mlody_Zdolny napisał:
    Też potrzebują i też wywalają się z powodu jej braki, i to często nie z powodu ogromnych struktur danych lecz memory leaków spowodowanych niewłaściwie zrealizowanym zwalnianiem pamięci.

    Jest bardzo wiele artykułów w necie o tym, jak wykrywać i usuwać memory leaks w programach napisanych w Pythonie. Jeżeli jakiś programista Python sądzi, że jemu to się nie może przytrafić, to jest w całkowitym błędzie.
  • #18 20549621
    kekon
    Poziom 19  
    Niektórzy twierdzą, że Python to język dla tych, którzy nie umieją programować. Paradoksalnie jego główne zalety czasem stają się jego wadami. Pamiętam czasy kiedy weszła Java i była "rewelacyjna". Teraz jest Python. Potem będzie znowu coś innego. Te języki sprawiły, że programy w nich napisane zżerają zasoby komputerów, wymagają ogromnej ilości pamięci (cena za łatwość i wygodę programowania).
    Co ciekawe sam interpreter Pythona jest napisany w C a wiele bibliotek z którego korzysta ten język używa C/C++.

    p.s. Poniższy kod:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    można zapisać prościej:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #19 20549743
    Urgon
    Poziom 38  
    AVE...

    Każdy język programowania, który używa niewidzialnych znaków w swojej składni jest z gruntu złym językiem. Programiści Pythona twierdzą, że to po to, by kod ładnie wyglądał i był czytelny. Za ładny wygląd i czytelność kodu, który piszę dla mikrokontrolerów PIC odpowiada edytor kodu w IDE, przez co ja nie muszę o tym myśleć. Edytor rozpoznaje bloki kodu i dodaje wcięcia w miarę potrzeby. Ba, poszczególne bloki mogę sobie zwinąć, tak że wyświetla mi się tylko nazwa funkcji i parametry, a jej treść estetycznie jest schowana, gdy nie potrzebuję oglądać tego paskudnego kodu, który w niej umieściłem.

    Dalej, dlaczego biblioteki Pythona są pisane w C++? Bo napisać ich w Pythonie się zwyczajnie nie da. Wliczając w to SciPy i NumPy, czyli biblioteki przeznaczone do zaawansowanych działań matematycznych. Gdyby napisać je w całości w Pythonie, każdy program ich używający byłby nawet kilka tysięcy razy wolniejszy. A te składniowe zalety, jak łatwa obsługa tablic czy innych struktur danych? To samo potrafi wiele innych języków, wliczając w to Go, Common Lisp i COBOL. Python zdobył popularność, bo jest na pierwszy rzut oka łatwym w użyciu językiem skryptowym. Tragedią informatyki jest to, że ludzie zapominają o tym, że to wciąż język skryptowy, i do tego wcale nie jest najlepszy spośród języków skryptowych.

    Wracając jednak do głównego tematu dyskusji, to przypomnę, iż artykuł oryginalny skierowany jest do profesjonalistów, i nawet im udziela złych porad, bo budowanie całego środowiska od zera nie ma sensu, gdy ktoś, zwykle producent danej platformy, już to zrobił. Często lepiej, niż jest w stanie to zrobić programista. Zwłaszcza że programista taki będzie pracować miesiącami z jedną platformą, więc nie potrzebuje szukać uniwersalnych rozwiązań. Ba, dedykowane do platformy IDE zwykle ma bonusowe funkcje, o które będzie trudno w czymś robionym od zera. Począwszy od generatorów kodu dla peryferiów, generatorów fusebitów poprzez funkcje debuggera. Debugger to szczególnie potężne narzędzie, i często specyficzne dla konkretnej platformy i konkretnego IDE. Zabawa w "środowisko po mojemu" często pozbawia nas tego narzędzia. Ale jak ktoś wyrósł na Arduino czy Pythonie, to często nie widzi, jak to fajnie jest móc sprawdzić, co się dzieje w programnie w trakcie pracy na docelowej platformie sprzętowej...
  • #20 20550156
    khoam
    Poziom 42  
    Generatory kodów C/C++ w IDE to super narzędzie dopóki nie nastąpi aktualizacja toolchain albo samego generatora (z powodu błędów). Myślenia, a przede wszystkim czytania dokumentacji nic nie zastąpi. Nawet na tym forum pojawiło się już wiele postów w stylu "wygenerowany kod mi nie działa" połączonych z brakiem chęci analizowania potencjalnych przyczyn oraz z pytaniami typu "gdzie mam kliknąć, aby było dobrze".

    Dodano po 18 [minuty]:

    Cytat:
    Debugger to szczególnie potężne narzędzie, i często specyficzne dla konkretnej platformy i konkretnego IDE. Zabawa w "środowisko po mojemu" często pozbawia nas tego narzędzia.

    Wręcz przeciwnie. To właśnie specjalizowane środowisko programistyczne pozwala nierzadko na użycie tych wersji czy modeli debuggerów, których nie można "wyklikać" w IDE producenta.
  • #21 20550281
    tronics
    Poziom 38  
    Niby spoko, można FPGA pisać bez IDE producentów tylko sobie wszystko po kolei konfigurować... widziałem tutki, dziękuję postoję. Ogarnięcie aparatury kontrolno-pomiarowej w C jest jak najbardziej możliwe i niektórzy tak robią. A inni kupują np. labview i sobie klikają. Efekt jest taki, że aplikacja testowa wymaga 4 rdzeni i 16GB pamięci, ale POC działa w ciągu tygodnia w Berlinie i zaimplementować w ciągu miesiąca z zupełnie innym teamem w Shanghaju... To, że MOŻNA robić jakieś rzeczy i że zasadniczo jest to lepsze rozwiązanie względem wydajności, zasobów, elastyczności etc. ma zupełnie zerowe znaczenie w środowisku biznesowym.
  • #22 20550657
    Wirnick
    Poziom 30  
    Ja jestem jak stary rolnik. Patrze jak to rośnie - niby do nieba. Pamiętam, jak brało się dwa worki zboża 50kg pod pachy i szło się pogadać z sąsiadami. Jak rodziły się zegarki w kodzie BCD na bramkach TTL zaczęło mi już brakować czasu i worki po 20kg zaczęli wozić kurierzy. Do sąsiada wysyłało się faks(bajty 4 bitowe). Ale mnie zakręciło.
    Częścią wspólną dawnych i obecnych czasów jest tablica znaków za pomocą której można się porozumiewać.
    Typ char pozostał taki sam, ale ilość bitów w bajcie zwiększyła się już do 64 - a co tam, przyśpieszymy zegary.
    By to opanować, rozbudowuje się środowiska programistyczne w których lauchs wygląda jak ślaczek pierwszoklasisty i nie wiadomo co autor miał na myśli.
    By pośpiewać i potańczyć to obecnie są w użyciu bajty co najmniej 128 bitowe, a wystarczały z Amigi.
    Nie piętnuję, ale namawiam do optymalizacji środowisk programistycznych i owoców pracy, by nie tworzyły się kobyły.
  • #23 20550690
    stachu_l
    Poziom 37  
    Wirnick napisał:
    bajty co najmniej 128 bitowe
    A gdzie są takie bajty? Słowo maszynowe, wielkość rejestrów czy arytmometru tak ale bajt to nie jest synonim słowa maszynowego a raczej podstawowej adresowalnej jednostki pamięci i gdzieś od IBM360 jest ciągle 8 bitowy. W Odrze były znaki 6 bitowe - cztery w słowie 24-bitowym. Jednak ich adresowanie występowało tylko w specjalnych rozkazach używając dodatkowych 2 bitów w stosunku do normalnego adresu wskazującego słowa 24bitowe.
    Pewno bywały w międzyczasie architektury o innych bajtach niż 8-bitowe ale chyba na tyle egzotyczne, że mało znane.
    Faks był 4 bitowy? Może kodowanie szarości było 4 bitowe ale chyba nie sama architektura systemu wewnątrz faksu.
    Może starsze faksymile - nie pamiętam bo może było analogowe.
    Może chodzi o dalekopis/telegraf/telex - tam był kod 5-biotwy tak zwany telegraficzny.
  • #24 20550743
    Wirnick
    Poziom 30  
    @stachu_l Tablica znaków mieści się w zakresie 256, czyli w 4 bitach kodu maszynowego. To że Ty się posługujesz systemem heksagonalnym, oktonalnym czy dwójkowym(maszynowym) to Twój problem. Przemyśl różnicę między adresem a datą w mc.
    "Pewno bywały w międzyczasie architektury o innych bajtach niż 8-bitowe ale chyba na tyle egzotyczne, że mało znane.", albo mało się interesowałeś - microfale były oparte o tą architekturę 4-bitową. obsługiwany był zegar i nastawy pieczenia.
  • #25 20550751
    Mlody_Zdolny
    Poziom 30  
    Urgon napisał:
    Programiści Pythona twierdzą, że to po to, by kod ładnie wyglądał i był czytelny. Za ładny wygląd i czytelność kodu, który piszę dla mikrokontrolerów PIC odpowiada edytor kodu w IDE, przez co ja nie muszę o tym myśleć.

    Programiści Pythona też używają wypasionych IDE co same formatują kod, przykład to PyCharm.
  • #26 20550978
    Urgon
    Poziom 38  
    AVE...

    Wirnick napisał:
    Ja jestem jak stary rolnik. Patrze jak to rośnie - niby do nieba. Pamiętam, jak brało się dwa worki zboża 50kg pod pachy i szło się pogadać z sąsiadami. Jak rodziły się zegarki w kodzie BCD na bramkach TTL zaczęło mi już brakować czasu i worki po 20kg zaczęli wozić kurierzy. Do sąsiada wysyłało się faks(bajty 4 bitowe). Ale mnie zakręciło.

    Moja nie rozumieć, co Twoja chcieć powiedzieć...

    Wirnick napisał:
    Częścią wspólną dawnych i obecnych czasów jest tablica znaków za pomocą której można się porozumiewać.

    No nie za bardzo, bo tablic i standardów było przynajmniej kilka. Od pięciobitowego kodu Baudota, przez tablice o 6 i 7 bitach, po rozszerzoną tablicę ośmiobitową, oraz obecne tablice Unicode. Przed Unicode każdy kraj miał swoją tablicę, i to nie było kompatybilne, dlatego przeglądarki internetowe pozwalały je przełączać. Nawet Polska miała przynajmniej 3 standardy ASCII.

    Wirnick napisał:
    Typ char pozostał taki sam, ale ilość bitów w bajcie zwiększyła się już do 64 - a co tam, przyśpieszymy zegary.

    Char to char, osiem bitów, albo jeden bajt. To jednostki stosowane od dekad i dawno temu zdefiniowane. Dla rozmiarów innych, niż bajt używa się terminu "słowo". Na przykład "słowo 64-bitowe". Nie twórz nowej informatyki, okej?

    Wirnick napisał:
    By to opanować, rozbudowuje się środowiska programistyczne w których lauchs wygląda jak ślaczek pierwszoklasisty i nie wiadomo co autor miał na myśli.

    Moja nie rozumieć.

    Wirnick napisał:
    By pośpiewać i potańczyć to obecnie są w użyciu bajty co najmniej 128 bitowe, a wystarczały z Amigi.

    Nie bajty, a słowa. I gadasz głupoty, bo od lat wszystko jest 64-bitowe, i ze względu na kompatybilność wsteczną masz obsługę aplikacji 16-bitowych i 32-bitowych, ale z tych pierwszych powoli się już wycofują. Wojny bitowe to miały miejsce w świecie konsol do gier w latach 90tych, gdzie niską prędkość zegara kompensowano szerszym słowem.

    Wirnick napisał:
    Nie piętnuję, ale namawiam do optymalizacji środowisk programistycznych i owoców pracy, by nie tworzyły się kobyły.

    Ty może lepiej nikogo do niczego nie namawiaj, bo nie masz pojęcia, o czym piszesz. Ja też nie mam pojęcia, o czym piszesz...


    @Mlody_Zdolny

    To zaawansowane IDE do Pythona to produkty firm trzecich. Developerzy języka oferują proste IDE/środowisko wykonawcze, bo to jest przede wszystkim język skryptowy do pisania prostych programów. a nie język do tworzenia wielkich projektów. Szkoda, że użytkownicy o tym zapomnieli i tworzą w tym języku skryptowym wielkie projekty...
  • #27 20550992
    Wirnick
    Poziom 30  
    @Urgon Ale mi dowaliłeś , bo jak sam przyznajesz wiele nie rozumiesz.
  • #28 20550998
    tronics
    Poziom 38  
    No bo trudno zrozumieć o co koledze chodzi. Procesory 8 bitowe miały z reguły 16bitowe możliwości adresowe (a czasem i 24), co ma piernik do wiatraka? :) Procesory 64bitowe CPU adresują fizycznej pamięci od 40 do 48 bitów. A nie 64 ;)
    A char na 64bit CPU dalej jest typem 8bitowym tak jak na 8051.
    Wreszcie by poruszać się po 256 elementowej tablicy to wypadałoby mieć 8 linii adresów, a nie 4.
  • #29 20551040
    Wirnick
    Poziom 30  
    tronics napisał:
    No bo trudno zrozumieć o co koledze chodzi. Procesory 8 bitowe miały z reguły 16bitowe możliwości adresowe (a czasem i 24), co ma piernik do wiatraka? :) Procesory 64bitowe CPU adresują fizycznej pamięci od 40 do 48 bitów. A nie 64 ;)
    .

    Nie wiem o co pytasz - czy o tego co rósł, rósł i urósł czy rosnących do nieba.
    Adresowanie w układzie mikroprocesorowym zależy od użytych pamięci danych. Możliwe, że będą potrzebne adresy ponad 64 bity, ale jak będą użyte pamięci o takim dostępie - ale możesz to sobie wyliczyć na kalkulatorze.
  • #30 20551059
    Urgon
    Poziom 38  
    AVE...

    @tronics, taki PIC16F628A ma osiem bitów, ale pamięć programów ma szerokość szyny danych 14 bitów i 13 bitów dla adresów. Daje to łącznie dwa kilosłowa czternastobitowe pamięci programu. Główna szyna danych ma 8 bitów, szyna adresowa RAM 9 bitów, ale RAMu jest tylko 224 bajty, resztę przestrzeni "zjadają" rejestry. Do tego bezpośrednio można zaadresować tylko 128 bajtów na raz, bo pamięć i rejestry są w bankach przełączanych przez rejestr STATUS. Warto dodać kolejne 128 bajtów pamięci EEPROM. ALU ma osiem bitów, więc cały dlatego układ jest ośmiobitowy. Od strony programisty ten "bajzel strukturalny" nie ma znaczenia - kompilator się tym zajmuje "w tle", a plik nagłówkowy dla danego układu mapuje adresy rejestrów i ich nazwy. Microchip w obrębie tych samych rodzin i peryferiów stosuje te same konwencje nazewnicze, więc wystarczy się tego nauczyć raz dla danej rodziny...

Podsumowanie tematu

W dyskusji poruszono pięć powodów, dla których programiści powinni rozważyć budowę własnego środowiska do kodowania w C/C++ zamiast korzystania z gotowych rozwiązań dostarczanych przez producentów mikrokontrolerów. Uczestnicy podkreślili znaczenie zrozumienia podstaw aplikacji, elastyczności w dostosowywaniu środowiska do specyficznych potrzeb projektów, a także korzyści płynące z lepszego zarządzania wersjami i integracji ciągłej. Wskazano również na problemy związane z różnorodnością platform oraz konieczność dostosowywania narzędzi do współpracy w zespołach. Wiele osób zauważyło, że gotowe IDE mogą ograniczać kreatywność i zrozumienie kodu, a także prowadzić do chaosu w większych projektach. Wspomniano o narzędziach takich jak PlatformIO oraz o wyzwaniach związanych z zarządzaniem pamięcią i strukturami danych w kontekście programowania embedded.
Podsumowanie wygenerowane przez model językowy.
REKLAMA