Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    345
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    16

Wszystko napisane przez GAndaLF

  1. Pierwsze spotkanie już 8 października o 18:00 w Sztuce Wyboru ul. Słowackiego 19 Gdańsk. Link do wydarzenia: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/264532531/ Pierwsze spotkanie będzie skupione wokół systemów safety-critical. Adam Lasota opowie nam o Model Based Design, czyli technice tworzenia oprogramowania za pomocą diagramów, z których następnie generowany jest kod. Taki sposób tworzenia kodu jest popularny między innymi w lotnictwie. Adam na co dzień pracuje z użyciem Model Based Design i podzieli się z nami swoimi wrażeniami na temat tej techniki. Następnie Piotr Strzałkowski zachęci Was do zapoznania się z językiem Ada. Jest to język stworzony na potrzeby amerykańskiego wojska i jest uznawany za najbezpieczniejszy język programowania. Ada jest językiem wysokiego poziomu zawierającym klasy, czy typy generyczne a jednocześnie pozwala na tworzenie niskopoziomowego kodu do obsługi peryferiów. Do tego posiada bardzo zaawansowany system typów i różne zabezpieczenia nie pozwalające na przykład na wyjście poza indeks tablicy, czy dereferencję null pointera. Piotr opowie jak Ada mogłaby ułatwić życie programisty embedded przyzwyczajonego do języka C. Meetup jest również świetną okazją, żeby porozmawiać z osobami z okolic Trójmiasta zajmującymi się podobną tematyką i wymienić się doświadczeniami. Harmonogram: 18.00 Adam Lasota - "Model Based Design" 18.50 Przerwa na pizzę 19.10 Piotr Strzałkowski - "Wprowadzenie do Ady"
  2. Od października w Gdańsku ruszamy z meetupem dotyczącym systemów embedded. O co chodzi w meetupach? To okazja aby osoby pracujące w branży, studenci i pasjonaci z danej okolicy mogli się spotkać na żywo, wymienić doświadczeniami i podnieść umiejętności. Odbywają się zwykle w godzinach popołudniowych i składają się z prezentacji i luźnych dyskusji. Grupy użytkowników Javy, czy .NETa od lat prężnie funkcjonują w większych polskich miastach. Pora więc na grupę embedded. Tematyka W ramach spotkań będziemy prowadzić prelekcje na tematy takie jak: Programowanie w C, C++, Rust, Ada, Asembler Mikrokontrolery AVR, ARM, PIC i inne RTOS - Real Time Operating Systems Embedded Linux Projektów na Arduino, Raspberry Pi i inne platformy IoT - Internet of Things Systemy safety-critical Dobre praktyki programowania i prowadzenia projektów Testowanie, automatyzacja i podnoszenie jakości Wszystkie inne pokrewne tematy oczywiście również mile widziane. Pierwsze spotkanie Pierwsze spotkanie gdańskiego meetupu planuję na październik. Już niedługo zamieszczę informację o dokładnej dacie i miejscu, a także o tematach prezentacji i ich autorach. Zapisy Można już zapisywać się do grupy na meetup.com: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/ Tam też będzie rejestracja na konkretne spotkania (spotkania będą darmowe, ale potrzebujemy liczby uczestników żeby wybrać odpowiednią salę). Jeżeli macie jakieś pytania, pomysły, uwagi - piszcie w komentarzach, chętnie odpowiem.
  3. To co robiłem jak najbardziej było testami jednostkowymi. A logika biznesowa to miejsce, gdzie takie testy dają najwięcej wartości i są najłatwiejsze do napisania.
  4. TDD sprawdza się tam, gdzie masz do napisania jakąś logikę aplikacji. Z przykładów mogę podać np. protokoły komunikacyjne. Pisałem ich już trochę i TDD jest świetne do sprawdzania przekłamania pól w ramkach, retransmisji, timeoutów, handshakeów i innych tego typu procedur, które ciężko jest dobrze napisać, a debugowanie jest problematyczne, bo czasem ciężko wywołać te błędy. Poza tym później jak się na przykład zmieni się długość i kolejność pól to bez unit testów nawet mała zmiana może oznaczać całe dni debugowania. Pisałem też w ten sposób różne sterowniki z logiką typu wyłącz awaryjnie, jeżeli przez określony czas sygnał jest powyżej progu. Poza tym obliczenia zawierające logikę, obsługa błędów, triggerowanie eventów. W tych wszystkich zastosowaniach TDD po prostu pomaga. Owszem, pracowałem też ze źle napisanymi testami i faktycznie jest to udręka. Jednak często wystarczą proste refactoringi typu podzielenie ogromnego testu, w którym nie wiadomo o co chodzi na wiele małych skupionych na jednym zadaniu. Wtedy jak taki test nie przechodzi, od razu nazwa daje wskazówkę co jest nie tak. Inna sprawa, że zwykle trudność w testowaniu pokazuje problemy z implementacją np. wielka funkcja robiąca wiele rzeczy na raz. Sformułowania takie jak: w stosunku do TDD są bardzo niesprawiedliwe. Zwykle jest właśnie w drugą stronę - duże projekty bez testów jednostkowych też czasem przez przypadek mogą działać poprawnie, ale jest to raczej wyjątek od reguły.
  5. Ja stosuje TDD komercyjnie już od paru ładnych lat i widzę w nim ogromne korzyści. Co więcej walczyłem o wprowadzenie unit testów w różnych projektach, w których brałem udział i widziałem jak ludzie z czasem się do nich przekonywali. Jak zmieniała się ich ocena po tym jak testy wyłapały coś naprawdę grubego, co normalnie mogłoby kosztować wiele dni poszukiwań. Mam dużo doświadczeń pokazujących, że unit testy są przydatne, dlatego je polecam. Z resztą zdecydowana większość autorytetów programowania takich jak np. Uncle Bob, czy Martin Fowler też poleca TDD. DHH w swoim artykule pisze, że już nie potrzebuje używać TDD bo wyłapał dobre nawyki przez lata, kiedy go stosował. Podejście bez testów może się sprawdzić w środowisku, gdzie kod piszę tylko jedna osoba, która ma duże doświadczenie. Natomiast jeżeli pracujesz w zespole, są tam nie tylko seniorzy, a system jest duży to musisz mieć feedback, czy coś zepsułeś w innym kodzie. A z XP też poruszyłeś ciekawy temat, bo XP jako termin nie jest już praktycznie używane, ale większość stawianym w nich tez i zalecanych technik ma się bardzo dobrze. Żeby wymienić choćby TDD, Continuous Integration, Code Review, czy Refactoring.
  6. @Elvis przykład miał na celu pokazanie czytelnikowi zaczynającemu z TDD sposobu pracy, który jest zupełnie odmienny od standardowego podejścia. Napisałem kilka pierwszych testów i zaznaczyłem w tekście, że dopisanie pozostałych pozostawiam czytelnikom jako ćwiczenie. Konkretne nazwy testów do zrobienia nawet są wypisane w formie komentarza. Zawierają one z resztą dokładnie te przypadki, o których mówisz. Może faktycznie przydała by się wielka czerwona ramka mówiąca, że to nie jest jeszcze skończona implementacja i kodu w takiej formie nie należy kopiować do własnych projektów. Świadomie zrezygnowałem z łopatologicznego opisywania całej implementacji do końca, bo po tych pierwszych testach już cały schemat pracy się powtarza i nie ma sensu opisywać ciągle tego samego. Tym bardziej, że artykuł już był bardzo długi. Pewnie lepiej do prezentacji sprawdziłoby się wideo. Albo mogę w przykładzie na githubie dopisać pełną implementację zgodnie z TDD, żebyś nie oceniał niedokończonego kodu. Bo stosowanie TDD właśnie sprzyja myśleniu o błędach i prędzej w ten sposób zabezpieczysz się przed overflowami itp niż pisząc wszystko z palca. A teraz co w TDD jest złe? Nic nie jest złe, po prostu TDD nie nadaje się do każdej sytuacji. Nie znajdziemy w ten sposób np. błędów ze współbieżnością, czy problemów performance'owych. Nie ma sensu robić TDD jeżeli eksperymentujemy z kodem i nie wiemy jeszcze co chcemy osiągnąć. Napisałem o tym cały artykuł: https://ucgosu.pl/2017/09/kiedy-nie-stosowac-tdd/ Dlatego w dobrym projekcie powinno być też miejsce na inne poziomy testów i analizę statyczną. Natomiast w króciutkim programie na 100 linijek pisanym w jeden dzień faktycznie nie opłaca się stosować TDD (ani wielu innych przydatnych technik), bo więcej czasu stracimy na konfigurację niż na samo pisanie kodu. Natomiast ten artykuł nie miał analizować wszystkich aspektów TDD, tylko pokazać tryb pracy, w którym robimy małe iteracje test-implementacja zamiast siedzieć długi czas nad implementacją, a potem długi czas nad debugowaniem. Często jako argument przeciw TDD podaje się, że tracimy w ten sposób dużo więcej czasu, a testy nic nie dają. Oba stwierdzenia nie są prawdziwe, bo po pierwsze tracimy podczas developmentu dużo czasu schodzi na debugowanie, którego potem nie możemy łatwo powtórzyć. A poza tym więcej bugów wraca do nas w późniejszych fazach projektu. @Elvis skoro nie jesteś entuzjastą TDD to śmiało napisz jakie widzisz w nim problemy, może z tego powstać ciekawa dyskusja.
  7. Ostatnio ukazał się odcinek podcastu "Ja, programista" z moim udziałem. Rozmawiamy o systemach embedded: https://devsession.pl/japrogramista-3/ Myślę, że najbardziej może zainteresować osoby, które zaczynają, żeby zobaczyły rodzaje problemów, z jakimi trzeba się mierzyć. Jest też parę słów o Forbocie Miłego słuchania
  8. @SOYER bez przesady z tym panem Jeżeli dopiero zaczynasz, to faktycznie narzędzia i praktyki o których wspomniałem będą Cię rozpraszać od nauki programowania. Natomiast jak już poznasz podstawy to pierwszym krokiem powinna być nauka kontroli wersji, najlepiej w gicie. @Nawyk święte słowa z tym zaoszczędzonym czasem. Wiele z tych technik powstało jako odpowiedź na wcześniej popełnione błędy. Ale jeżeli ktoś samemu ich również nie popełni to chyba się nie przekona Z długiem technicznym dobry temat i w embedded chyba nie aż tak przeanalizowany, szczególnie aspekty związane z hardwarem. @deshipu dla mnie review to miejsce wyłapywania bardziej ogólnych i trudnych problemów niż stylistyczne (te zostawmy automatom) przykładem mogą być np. problemy ze współbieżnością, wydajnością, późniejszymi modyfikacjami. Ale faktycznie komunikacja też potęguje dobre efekty - po kilku takich uwagach autor sam zaczyna zwracać uwagę na problem, rodzą się wartościowe dyskusje i buduje się zespół.
  9. A masz zdjęty write protection na te strony? To się robi ST-Linkiem. Więcej info w dokumencie, który wyżej gdzieś wklejałem
  10. W takim razie musisz się przyjrzeć jaką stronę w pamięci FLASH zapisuje twój emulowany EEPROM. Możliwe, że jest to jedna z pierwszych stron pamięci, na których znajduje się kod programu. Po nadpisaniu tej pamięci zamiast programu wykonują się jakieś śmieci.
  11. Błędy od ST wcale nie są takie nieprawdopodobne, jak może się wydawać Jednak w Twoim wypadku bardziej prawdopodobne jest, że zrobiłeś coś źle przy tworzeniu nowego projektu z przykładowego kodu, albo przy rozbudowywaniu przykładu o UART. Dlatego właśnie chciałem, żebyś najpierw potwierdził, że czysty przykład EEPROM od ST bez dodanego UART działa poprawnie i zapisuje zadane wartości do pamięci nieulotnej - powinieneś sprawdzić to debugerem. Potem musisz przestepować debugerem kod z dodanym UARTem i zobaczyć czy też zapisuje do pamięci i nie zawiesza się np. na assercie.
  12. Temat musisz podzielić na mniejsze: - czy sam kod emulated EEPROM działał? - czy sam kod UART działał? Jak te dwa kroki zrobisz to w debuggerze powinieneś uruchomić kod i po jakimś czasie zatrzymać żeby zobaczyć, czy np. nie wywalił się na assercie ani nie siedzi w nieskończonej pętli. Potem możesz przestepować od początku debuggerem. Przyczyn błędów może być milion i z małego opisu rzadko ktoś dobrze strzeli co jest powodem. Musisz nauczyć się samemu te kroki wykonywać i formułować dodatkowe wnioski o działaniu programu. A jeżeli chodzi o ten dokument to spojrzałem na ref man STM32F0. W STM32F1 faktycznie datasheet jest bardziej okrojony w tym względzie. Opisy z dokładniejszymi diagramami są w oddzielnym dokumencie PM0075: STM32F10xxx Flash memory microcontrollers Polecam się z nim zapoznać, bo możliwą przyczyną jest na przykład zła sekwencja odblokowywania strony pamięci.
  13. Jeżeli dopiero się uczysz proponuję wykorzystać to zadanie właśnie do celów edukacyjnych. Na początek spróbuj napisać program, który po prostu zapisuje coś do FLASHa STMa. W tym celu musisz przeczytać rozdział Embedded Flash Memory w reference manualu i dowiedzieć się jak robić zapis i odczyt. Masz tam fajne diagramy obrazujące kolejne kroki. Następnie możesz użyć rejestrów bezpośrednio, albo wspomóc się HALem, żeby napisać prosty program zapisujący/odczytujący jakąś komórkę z Flasha. Jak będziesz umiał obsłużyć peripheral Flasha, to możesz przeczytać Application Note STMa o emulacji EEPROM i przeanalizować kod. Wtedy powinieneś być w stanie samemu znaleźć błąd, albo zaimplementować emulację po swojemu dopasowaną do swoich potrzeb. Ja na przykład kiedyś pisałem pamięć nieulotną na Flashu STMa i zrobiłem to prościej, bopodejście z tego AN wydawało mi się przekombinowane.
  14. A ten LinkerScript.ld skąd masz? Wygenerowany automatycznie przy zakładaniu projektu, czy też skopiowany z przykładu? Bo obstawiam, że wygenerowany się różni od oryginalnego.
  15. Streaming na RPi był zestawiany na szybko jako tymczasowe rozwiązanie, żeby tylko coś pokazać na prezentacji i szczerze mówiąc nie analizowaliśmy tematu za bardzo. O szczegóły realizacji muszę podpytać, bo ja akurat nad tym nie siedziałem.
  16. Już jakiś czas temu zebraliśmy się w pracy w kilka osób, żeby pomyśleć nad jakimś projektem, w którym moglibyśmy wykorzystać machine learning, chmurę i robotykę. Padło na jeżdżącego robota z kamerką, który mógłby służyć do mapowania terenu i umieszczania na tej mapie obiektów rozpoznanych przy pomocy kamery. Skończyło się na samym gadaniu i przez długi czas nic w tym kierunku nie robiliśmy. Aż w końcu przyszedł NASA Space Apps Challenge, gdzie postanowiliśmy wystartować z ekipą z firmy. Nasz pomysł przerodził się w łazika marsjańskiego, który miał pomóc pierwszym kolonizatorom Marsa w rozpoznaniu terenu dookoła obozowiska. Podczas 24-godzinnego hackatonu udało nam się poskładać coś co jeździ i streamuje obraz z kamery. Biorąc pod uwagę ile rzeczy nie chciało działać, to i tak sukces. Robota w akcji można zobaczyć na filmiku: Teraz trochę o bebechach: Raspberry Pi 3B+ - miał być na nim postawiony ROS, ale na razie tylko obsługuje kamerkę STM32F4 Discovery - miał być klient rosserial obrabiający komendy z ROSa, na razie jest prosta aplikacja sterująca na sztywno silnikami w pętli 4 moduły mostków H TB6612 kamerka USB Powerbank do zasilania logiki - aktualnie ogromny powerbank 30 Ah, bo taki mieliśmy pod ręką Lipol 2S 800 mAh do zasilania silników - docelowo zostanie tylko jedno zasilanie Płytka stykowa do podłączenia lipola, mostków H i switcha ON/OFF Podwozie Pirate 4WD Co jeszcze planowaliśmy: Intel RealSense - kamera RGB z czujnikiem odległości - układ jaki dostaliśmy nie działał w pełni - brak kamery RGB, sama chmura punktów. Poza tym były wielkie problemy z driverami. Intel Movidius - koprocesor do obliczeń na sieciach neuronowych. Dzięki temu będziemy mogli zrezygnować z chmury. Czujnik IMU - MinIMUv5 Pololu - podczas hackatonu nie było czasu podłączyć. Poza tym i tak ROS nie działał. Jeżeli chodzi o soft: większość funkcji miał zapewnić ROS działający na Raspberry. Nigdy go nie używaliśmy i chcieliśmy się pobawić modułami sensorów, nawigacji, analizy obrazów itp. na STM projekt powstaje w C++. Miał być system operacyjny DistoRTOS i docelowo będzie, ale na hackatonie nie było czasu go zintegrować. Repozytorium na razie nie zawiera zbyt wiele. Tylko prosty program w C++ sterujący na sztywno silnikami. Prawdopodobnie repo się mocno przeobrazi i będziemy je wykorzystywać do rozwoju projektu razem z issue trackerem, wiki itp. Kod można oglądać na GitHubie: https://github.com/ucgosupl/solwit_space_robot Części takie jak RealSense, czy Movidius dostaliśmy z sampli. Poza tym nasza firma - Solwit - zaangażowała się w projekt. Dostaliśmy między innymi Raspberry, mamy też w planach kilka kolejnych wydatków. Docelowo robot ma być wykorzystywany na różnych targach itp. Dodatkowo myślimy, żeby zrobić z niego pomocnika biurowego. Planujemy też wymienić Raspberry i Discovery na zintegrowaną płytkę z procesorem Intel Atom i STM32F4. Myśleliśmy zamiast tego o zastosowaniu Intel Euclid - platformy ze zintegrowanym RealSensem i prockiem z preinstalowanym ROSem, ale niestety Euclida nie ma w samplach. Zastosowane podwozie na filmiku działa dobrze, ale kiedy jeździ po wykładzinie, opony nie dają rady. Będziemy potrzebowali coś lepszego. Poza tym aktualne silniki nie mają enkoderów i ogólnie nie są najwyższych lotów. Aktualnie poszukuję jakiegoś gotowego podwozia 4-kołowego z enkoderami i porządniejszymi silnikami. Znacie może jakieś dobre modele? W grę wchodzi też zaprojektowanie własnego podwozia. Docelowo pewnie będziemy chcieli pójść właśnie tą drogą. Tylko nie mamy jeszcze sprecyzowanych wymagań, jakie stawiamy konstrukcji. Dlatego możliwe, że będzie kilka prototypów. Najlepiej je pewnie zrobić na drukarce 3D i dopiero ostateczną wersję wyciąć z jakiejś blachy. Przy okazji poszukujemy kogoś, kto mógłby nam takie podwozie zaprojektować. Najlepiej z okolic Trójmiasta. Więcej o robocie można przeczytać na moim blogu: https://ucgosu.pl/2018/10/lazik-z-nasa-space-apps-challenge-szczegoly-techniczne/
  17. Sądząc po rozszerzeniach plików projektu (xcodeproj, pbxproj), to był projekt na XCode na Maca. Najprawdopodobniej w ustawieniach projektu były dodane jakieś specjalne definy, flagi kompilacji itp, które powodują, że twoja kompilacja się różni. Możesz spróbować odszukać ustawień z plików projektu - są w xmlu, więc powinieneś być w stanie znaleźć odpowiednie pola. Tylko może to wymagać trochę wiedzy i doświadczenia.
  18. Moim zdaniem taka umowa właśnie jest czymś dziwnym, bardzo możliwe, że nawet łamie jakieś prawo pracy, czy coś takiego. Rozumiem, że chciałbyś zajmować się konstrukcją mechaniczną robotów. To jest dosyć wąska specjalizacja. Pewnie musiałbyś uderzać do jakiejś większej firmy, gdzie jest większy zespół i wyraźny podział obowiązków. Wątpię, żeby w Polsce było dużo takich firm robiących własne roboty. Ale jak będziesz w tym dobry, to pewnie i tak sobie poradzisz. Skoro masz jeszcze 1.5 roku studiów, to najlepiej rozwijaj się w tym co lubisz i w czym jesteś dobry. Do tego nie olewaj wiedzy z tematów pokrewnych, które też się mogą przydać. Nie ograniczaj się do tego co jest na uczelni, tylko próbuj jakiś własnych projektów, albo grupowych w kołach naukowych itp. Do tego spróbuj poszukać ofert na wymarzone docelowe stanowisko np. w jakiejś NASA czy SpaceX i zobacz jakie mają wymagania.
  19. Żeby się dowiedzieć, w czym jest problem musisz rozbić sprawdzanie na etapy: 1. Sprawdź, czy funkcja LED() zapala diodę. 2. Sprawdź, czy funkcja LED2() gasi diodę. 3. Sprawdź, czy przerwanie się wywołuje i robi to co chcesz. Jak każda część działa poprawnie, program w całości też raczej będzie działać. Zakładam, że nie masz do AVRa debuggera i musisz po prostu wykomentowywać części kodu, kompilować i sprawdzać świeceniem leda. Jak chcesz się nauczyć programować to musisz się hartować od początku Zawsze na początku coś nie działa i im szybciej się nauczyć drążyć temat, tym lepiej.
  20. Fajnie, że sobie poradziłeś. Jak widać wystarczy parę pytań i metoda gumowej kaczki
  21. Zobacz temat na StackOverflow: https://stackoverflow.com/questions/2100448/multiple-target-patterns-makefile-error W linijce: EXTRA_SOURCE_DIR = ../../:Programowanie_AVR_library/ masz dwukropek w ścieżce. Przy okazji co to jest za makefile? Skąd go masz? Bo raczej nie jest napisany zgodnie ze sztuką (chociaż mówienie o sztuce w odniesieniu do Makefile jest trochę nie na miejscu ) i może zawierać inne błędy.
  22. Nie sprecyzowałeś dokładnie co właściwie chcesz zrobić. To trochę za mało informacji. Jakie dokładnie wartości fizyczne mierzysz? Czy chcesz tylko odszumić pomiary z każdego kanału, czy zrobić fuzję danych z obu sensorów w celu zwiększenia dokładności? Czy chodzi ci tylko o szum, czy np. dryft też? Czy sensor stoi na biurku i działa na niego tylko grawitacja, czy się porusza? Pytań jest sporo, wszystkie jakoś wpływają na model układu. Czyli jest to pomiar jednej losowej wartości, czy wielu losowych wartości? Filtr Kalmana z definicji służy właśnie do estymowania wartości zmiennych losowych obarczonych białym szumem więc to akurat nie powinien być problem. W jednym z artykułów wspomnianych przez Trekera (https://forbot.pl/blog/filtr-kalmana-od-teorii-praktyki-2-id3885) jest właśnie poruszane zagadnienie odczytów z akcelerometru i żyroskopu. Czym różni się twój przypadek od tego z artykułu? W ten sposób możesz sprawdzić, czy kod się kompiluje i odpala na procku, ale jeżeli model obiektu zupełnie mija się z prawdą, wyniki będą zupełnie z księżyca i tak naprawdę nie dostaniesz odpowiedzi na pytanie, czy kod właściwie działa. Co więcej przy strojeniu Kalmana możesz napotkać wiele subtelnych błędów np. z czasem próbkowania, wyborem stanu początkowego, czy doborem macierzy szumów. Żeby je rozwiązać, trzeba trochę podziałać metodą prób i błędów, ale niezbędne jest też zrozumienie teorii chociaż na tyle, żeby wiedzieć jaki dana zmiana będzie mieć spodziewany wpływ.
  23. Od około pół roku w pracy rozwijam projekt medyczny na STM32 w C++11. I muszę powiedzieć, że na początku miałem obawy takie same jak wy: narzuty, alokacja dynamiczna itp. Muszę jednak przyznać, że dobrze używany modern C++ w embedded jest niesamowicie wręcz przydatny. Język C++ opiera się na koncepcji zero cost abstractions - możemy używać klas, templatów i innych konstrukcji, które daje nam C++ aby zwiększyć czytelność kodu i zminimalizować ilość głupich błędów, a jednocześnie po kompilacji otrzymujemy ten sam kod w assemblerze. Musimy tylko włączyć optymalizację O2. Pisałem o tym na swoim blogu, przy okazji w linkowanym artykule możesz znaleźć trochę bibliotek do C++ na embedded: https://ucgosu.pl/2018/05/przydatne-biblioteki-c-stm32/ Przykładowy sposób na poprawienie procedur manipulacji rejestrami sprzętowymi można znaleźć np. w tym artykule: https://mklimenko.github.io/english/2018/06/19/write-only-variables/ To tylko wprowadzenie do tematu, jest cały ruch propagatorów C++ w embedded, którzy tworzą między innymi swoje własne biblioteki do rejestrów. Warto odwiedzić takie strony jak: https://embeddedartistry.com/ https://blog.feabhas.com/ http://kvasir.io/ https://modm.io/ Natomiast co do użycia biblioteki STL i vector - STL jest pisany z myślą o użyciu dynamicznej alokacji i exceptionów. Dlatego tylko mały jej podzbiór dobrze współgra z embedded. Istnieje za to biblioteka ETL, która stara się zapewnić potrzebne funkcjonalności w sposób bezpieczny dla systemów embedded - https://www.etlcpp.com/ Przy okazji zachęcam do śledzenia mojego fanpage na fejsie, gdzie od niedawna staram się wrzucać materiały z neta dotyczące C++ w embedded: https://www.facebook.com/ucgosupl/ I zachęcam też do korzystania z Twittera - tam dużo osób wrzuca materiały o embedded C++ polecam na początek użytkowników: https://twitter.com/mbeddedartistry https://twitter.com/odinthenerd No i oczywiście zachęcam do własnych eksperymentów z C++ w embedded. Moim zdaniem to jest przyszłość branży.
  24. Jeżeli chodzi o programowanie mikrokontrolerów komercyjnie to faktycznie do prototypów można użyć generatora, a docelowe rozwiązanie często jest napisane na rejestrach. Pisząc komercyjnie musimy brać pod uwagę poza szybkością wykonania jeszcze takie aspekty jak licencja i możliwość certyfikacji np. zgodność z MISRA C. To ostatnie szczególnie ważne jeżeli piszemy coś wojskowego, medycznego, automotive itp.
  25. Przy zwiększaniu czytelności kodu pisanego na rejestrach niestety nie masz zbyt wiele pola manewru. Twoimi przyjaciółmi powinny być #define i komentarze. Możesz też inicjalizację pojedynczych peryferiów zwijać w oddzielne funkcje. Moje moduły hw operujące na rejestrach wyglądają na przykład tak jak tutaj: https://github.com/ucgosupl/mm_legend_v2/blob/dev/src/hw/adc/adc.c W powyższym kodzie można jeszcze define niektórych wartości bitowych przenieść oddzielnych headerów z zestawem wszystkich define dla danego peryferium tworząc uzupełnienie bibliotek procka. Tak naprawde powinien to dla nas zrobić producent, a te definy były tylko dostępne jako część StdPeriph pod nieintuicyjnymi nazwami. Być może STM już wydał jakieś nowe headery.
×
×
  • Utwórz nowe...