Robotyka, Embedded, C
Podczas pracy z systemami embedded mamy do czynienia z różnymi procesorami. Każdy producent ma do nich swoje narzędzia - edytor kodu, kompilator, debuger, biblioteki. Często te narzędzia są płatne i nie jesteśmy w stanie zawczasu stwierdzić, czy rozwiążą nasze problemy. Dlatego w tym odcinku porozmawiamy sobie właśnie o IDE i debugerach. Postaram się odpowiedzieć na następujące pytania: Czy da się używać tego samego edytora w każdym projekcie? Jak ciężko przesiąść się na inny procesor/kompilator/IDE? Jakie są najważniejsze opcje debugerów sprzętowych? Czym się różni debuger za 100 zł od debugera za 3000 zł? Na co zwracać uwagę przy wyborze IDE i debugera? Jeżeli interesują Was jakieś inne kwestie w tym temacie - piszcie komentarze albo pytajcie na streamie. Znajdziesz mnie w internecie: Blog: https://ucgosu.pl/ Facebook: https://www.facebook.com/ucgosupl/ Twitter: https://twitter.com/MaciekGajdzica/ Zapisz się na mój newsletter: https://ucgosu.pl/newsletter
Jakiś czas temu firma Medtronic upubliczniła swój projekt respiratora, aby pomóc w walce z epidemią: https://www.medtronic.com/us-en/e/open-files.html Podczas streama przyjrzymy się opublikowanym materiałom i omówię różne aspekty dotyczące wytwarzania systemów safety-critical. Zobaczymy sobie zarówno kod źródłowy jak i udostępnione dokumenty projektowe.
Wróciłem już ze wsi i mogę znowu streamować. Pora więc kontynuować projekt zegara szachowego. Ostatnio udało się dopisać ładny kawałek logiki, a przy okazji pokazać jak wcześniejszy research i używanie unit testów przyspieszają prace. W tym odcinku będziemy kontynuować.
To już dziesiąty odcinek streama, a przy okazji Prima aprilis. Z tej okazji będzie na luzie i zamiast pisać kod w coś sobie pogramy. Mam nadzieję, że Wam się spodoba. Przy okazji to się dobrze wpisuje w akcję #zostanwdomu. Gry będą na multiplayer, więc zapraszam do dołączania. Najwięcej głosów miał Quake 3 Arena. Jednak z tego co widzę, za darmo można grać tylko po LANie, a płatna wersja za 60 zł. Dlatego zrezygnowałem z tego pomysłu. Może to i dobrze, bo bym spadał tylko w przepaść na tej kosmicznej mapie :D Dlatego na streamie będzie drugi w głosowaniu Starcraft Broodwar. A jako rezerwowy CS:GO. Oba mają wersję darmową pozwalającą grać na multiplayer. Starcraft Broodwar: https://us.shop.battle.net/en-us/product/starcraft CS:GO: https://store.steampowered.com/app/730/CounterStrike_Global_Offensive/
W tym tygodniu wracamy z powrotem do projektu zegara. Już najwyższa pora na zaimplementowanie logiki aplikacji. Zapraszam na: https://ucgosu.pl/ I do zapisywania się na newsletter: https://ucgosu.pl/newsletter aby być na bieżąco z kolejnymi streamami i innymi inicjatywami. Aktualnie pracuję nad szkoleniem online dotyczącym C dla zaawansowanych. Draft agendy możecie znaleźć tutaj: https://ucgosu.pl/agenda-c Informacje dotyczące szkolenia najszybciej znajdziecie na newsletterze. Jeżeli masz pomysł na kolejne tematy, chcesz omówić problemy związane z systemami embedded, czy masz jakiekolwiek pytania, zapraszam do kontaktu: https://ucgosu.pl/kontakt/
W tym tygodniu na chwilę przerwiemy cykl z projektem od zera i omówimy palący problem w kontekście epidemii koronawirusa. Jak pracować zdalnie w branży embedded? Czy to w ogóle możliwe na dłuższą metę? Jak się do tego zabrać? Temat był już wspomniany podczas odcinka o tym jak wygląda ogólnie praca w embedded: https://www.youtube.com/watch?v=yufUhkyOTdk Jednak aktualna sytuacja wymaga szerszego omówienia. Poruszone tematy: 1:25 Kontrolowanie pracowników, kamery internetowe - NIE RÓB TEGO 2:57 Komunikacja w zespole - remote asynch 5:25 Informowanie o postępach w pracy 8:56 Moje doświadczenia z pracą zdalną 9:45 O projekcie, gdzie mogłem cały czas pracować zdalnie 10:26 Dlaczego łatwiej pracować zdalnie w dojrzałym projekcie? 12:43 Jakość kodu, testy automatyczne, Continuous Integration 14:14 Kontrola wersji 15:18 Czy chciałbym pracować w 100% zdalnie? 17:05 Jak zorganizować swoje domowe stanowisko pracy? 21:15 Dokumentacja 22:16 Spotkania - Review Sprintu, Prezentowanie nowych funkcji
W kolejnej części o projekcie zegara szachowego kontynuujemy temat zbierania wymagań i projektowania logiki aplikacji. Powinien pojawić się już pierwszy kod.
Kolejny live będzie początkiem serii podczas której będę robić od zera projekt i tłumaczyć różne dobre praktyki. Tematy czystego kodu w C, podejścia do wymagań systemowych, architektury itp są ciężkie do pokazania w oderwaniu i to w dodatku na cudzych przykładach. Dlatego zrobimy sobie projekt i będę na bieżąco tłumaczył różne rzeczy, kiedy się będą pojawiać. Jako projekt wybrałem zegar szachowy. Na pewno będzie zawierać jakieś wyświetlacze, przyciski i trochę logiki sterującej. Ale do szczegółów dojdziemy sobie podczas analizy wymagań.
Tym razem nie będzie tematu technicznego, tylko pogadanka. Porozmawiamy sobie o tym, jak wygląda praca w embedded. Post na ten temat na moim blogu jest jednym z popularniejszych, czasem dostaję też od Was na maila prośby o porady. Dlatego opiszę jak u mnie wyglądała ścieżka zawodowa i jakie mam na ten temat przemyślenia. Co bym zrobił inaczej i co bym doradzał osobom, które teraz są na początku drogi. Zachęcam również do zadawania pytań. Poruszone tematy: 2:48 - Studia 3:25 - Jaki kierunek wybrać? 4:10 - Czy studia dobrze przygotowują do pracy w zawodzie? 5:14 - Kierunek informatyka 5:47 - Czy w pracy przydaje się teoria sterowania? 7:20 - Czy już przed pójściem na studia musimy umieć dobrze programować? 10:20 - Czy opłaca się iść na studia? Czy lepiej od razu pracować? 12:35 - Czy w pracy przydaje się analiza matematyczna? 14:50 - Czy jeżeli nie jestem pilnym studentem to jest jeszcze dla mnie nadzieja? 18:00 - Poszukiwanie pierwszej pracy 20:12 - Pierwsza rozmowa kwalifikacyjna 20:
Podczas streama będziemy kontynuować temat kompilatora, linkera i procedur startowych przed mainem na mikrokontrolerach STM32. Tym razem zastosujemy teorię z poprzedniego odcinka do implementacji procedur testowych zgodnych z normami EN60730 i EN60335 dotyczącymi elektroniki domowej czyli np. pralek, mikrofalówek itp.
Kiedy zaczynamy przygodę z mikrokontrolerami zwykle używamy projektów wygenerowanych przez IDE, które magicznie robią za nas całą początkową konfigurację i nie musimy się tym martwić. I bardzo dobrze, bo to jest skomplikowane i tylko odciąga nas od zadania. Jednak po jakimś czasie wiedza co się dzieje pod spodem w końcu się przyda. Albo dlatego, że coś nie działa jak trzeba, albo dlatego, że chcemy zrobić coś niestandardowego. W trakcie streama omówimy: - wektor przerwań - kod wykonywany przed funkcją main - regiony pamięci - skrypt linkera - plik map służący do podglądania adresów i rozmiarów zmiennych i funkcji - plik lst - kod naszego programu w asemblerze - datasheety ARM Cortex-M core i STM32 reference manual Oczywiście jeśli na wszystko starczy czasu
Kontynuacja tematu z zeszłego tygodnia - Test Driven Development w Embedded Dzisiaj omawiamy kolejny przykład - analizę przebiegu czasowego. Mamy więc większe powiązanie z hardware'm. Analiza przebiegów czasowych będzie częścią implementacji heartbeata (https://en.wikipedia.org/wiki/Heartbeat_(computing). Jest to technika wykorzystywana w systemach wieloprocesorowych do sprawdzenia, czy drugi procesor działa poprawnie. Poruszone zagadnienia: - 3:38 - Co to jest heartbeat - 13:35 - Początek implementacji - 23:46 - Separacja działań na HW od logiki - 32:23 - Obsługa fatal errora - 34:52 - inne frameworki do testowania - 40:58 - PW-SAT - produkcyjny projekt embedded z TDD i otwartym kodem - 44:03 - implementacja mocka nieskończonej pętli (nieudana) - 1:08:20 - Refactoring - 1:18:35 - dlaczego w omawianym przykładzie TDD jest lepsze niż testowanie na HW? - 1:38:55 - o copy-paste'owaniu scenariuszy testowych - 1:41:20 - debugowanie testów na PC - dlaczego w dalszym ciągu jest lepsze niż d
W trakcie pierwszego streama zajmiemy się Test Driven Development. Poruszone zagadnienia: - 2:32 - Wprowadzenie do TDD - 5:13 - Omówienie konfiguracji przykładowego projektu w CMake - 19:43 - Wytłumaczenie zasady działania bufora cyklicznego - 28:13 - Na czym polega TDD - 31:03 - Początek implementacji - 34:02 - Omówienie składni frameworka testowego Catch2 - 40:25 - Pierwszy test - 51:06 - Test przechodzący przez przypadek - 55:40 - Wpływ TDD na projekt - 59:11 - Określenie czy bufor cykliczny jest pusty - 1:09:35 - Testy na overflow - fail przez runtime error (nie udało się wywołać) - 1:18:27 - Refactor i jego wpływ na łatwość wprowadzania przyszłych zmian - 1:36:35 - Jak przekonać zespół do TDD? - 1:39:20 - Jak przekonać managerów do TDD? - 1:44:45 - Jak TDD pozwala poznawać kruczki języka? Dalszy ciąg w przyszłym tygodniu. Linki wspomniane podczas nagrania: Circular Buffer - https://en.wikipedia.org/wiki/Circular_buffer Catch2 - https://github.com/catchorg/Catch2 Trompeloeil -
Więcej informacji: https://ucgosu.pl/2018/10/lazik-z-nasa-space-apps-challenge-szczegoly-techniczne/
Robotyka, Embedded, C
Programowaniem zajmuję się zawodowo od 2012 roku. Moją specjalnością są systemy embedded, pracowałem już nad systemami safety critical, inteligentymi budynkami, czy Internet of Things. Jestem również wielkim fanem robotyki i w wolnym czasie robię własnego robota micromouse.