Programowanie i Robotyka
W poprzedniej części cyklu o TDD opisałem dlaczego sposób wytwarzania oprogramowania, który praktykowałem na początku się nie sprawdzał i co mnie skłoniło do zainteresowania się Test Driven Development. Dzisiaj opiszę jak wygląda praca zgodnie z TDD. Jak to często bywa w przypadku praktyk zwinnych zasady teoretyczne są dosyć proste, a kluczem do sukcesu jest dyscyplina.
Kiedy uczyłem się programować, pisałem metodą code and fix. Czyli najpierw pisałem jakiś fragment kodu – mogła to być jedna funkcja, moduł albo nawet cały program. Następnie uruchamiałem go i ręcznie sprawdzałem czy działa, przechodziłem kod debuggerem sprawdzając wartości zmiennych i przepływ sterowania. Następnie poprawiałem znalezione błędy, dodawałem funkcjonalności i znowu sprawdzałem. Na pewno każdy programista zaczynał w ten sposób.
W miarę jak moje umiejętności rosły i pisałem trudniejsze programy zauważałem coraz więcej problemów związanych z tą „metodologią”. Miałem jednak przeświadczenie, że robienie skomplikowanych aplikacji po prostu musi być skomplikowane. Tym bardziej, że na studiach (co prawda z Automatyki, a nie Informatyki) nikt się nawet nie zająknął o automatyzacji testów, o Test Driven Development nie wspominając. W kolejnych akapitach wytłumaczę, o jakie problemy mi chodziło.
Dzisiaj omówię, w jaki sposób zaprojektować regulator obrotów silnika. Pokażę jak zebrać dane pomiarowe, a następnie dokonać ich analizy i obróbki. W trakcie tego procesu wytłumaczę jakich narzędzi używam i w jaki sposób je wykorzystuję.
Podobny artykuł napisałem kiedyś na Forbocie – link. Jednak jest kilka istotnych różnic. Przede wszystkim tam był brany pod uwagę sam układ enkoder – silnik bez kół i całej konstrukcji mechanicznej robota. Przez to nie musiałem wtedy walczyć z takimi zakłóceniami i nieliniowościami. Poza tym wtedy wyprowadziłem model na podstawie pomiaru dla jednej wartości wypełnienia. Tutaj wykonuję pomiary dla trzech wartości i patrzę jak wyznaczone modele sprawdzają się dla innych danych pomiarowych.
Ostatnio miałem trochę przerwy od pisania na blogu. Nie oznacza to jednak, że w tym czasie leżałem do góry brzuchem. Większość mojego czasu pochłaniały przygotowania do przeprowadzenia pierwszego w życiu szkolenia – „Test Driven Development dla Systemów Embedded”.
Ten artykuł jest kontynuacją tematu testów pamięci RAM rozpoczętego w poprzednim wpisie – link. Poprzednio przybliżyłem trochę ogólnych informacji dotyczących RAMu i jego testowania. Dzisiaj zajmę się omówieniem konkretnych algorytmów. Nie udostępniam swojej implementacji opisanych tutaj testów, podaję za to linki do bibliotek producentów mikrokontrolerów, którzy takie testy zaimplementowali i opisali w notach katalogowych.
Pamięć RAM, jak każdy inny element systemu mikroprocesorowego może się zepsuć. Skutki złego działania RAM mogą być bardzo niebezpieczne. Szczególnie kiedy system wykonuje jakieś odpowiedzialne zadanie. Dlatego testy RAM są wymagane do zapewnienia odpowiedniego SIL (Safety Integrity Level – Poziom Nienaruszalności Bezpieczeństwa) przez różne normy:
W ostatnim czasie w pracy spędziłem sporo czasu na pisaniu testów poprawności działania mikrokontrolera, w tym testów pamięci RAM. Postanowiłem więc podzielić się zgromadzoną wiedzą.
Aby ruszyć dalej z pracami nad micromousem, potrzebuję funkcji logujących dane z działania programu na konsolę w czasie rzeczywistym. Są mi one potrzebne do kalibracji czujników ścian i doboru nastaw dla regulatorów silników. Idealnym rozwiązaniem było by wykorzystanie standardowej funkcji printf. Na mikrokontrolerze jednak nie jest to takie proste, ponieważ trzeba dopisać warstwę obsługi drivera USARTa. Poza tym należy rozwiązać pewne problemy implementacyjne. To wszystko opiszę w tym artykule. Poza tym kod data loggera oraz drivera USART jest dostępny na moim GitHubie.
W dzisiejszym wpisie zebrałem listę ciekawych blogów uczestników DSP. Większość wybranych przeze mnie pozycji jest dosyć zaawansowana technicznie. Poruszane w nich problemy są często trudne i właśnie przez to interesujące. Linki do innych ciekawych blogów, i może trochę łatwiejszych w odbiorze, można znaleźć we wpisie o gali finałowej – link.
Konkurs Daj Się Poznać to świetna inicjatywa mająca za zadanie skłonić programistów do wyjścia ze swojej piwnicy. Uczestnicy mają przed sobą dwa zadania – prowadzić bloga technicznego i rozwijać projekt open source. Obie te aktywności skupiają się na udostępnieniu innym osobom naszego kodu, doświadczeń, czy luźnych przemyśleń, a tym samym wystawieniu się na oceny i krytykę. Pewnie nie tylko dla mnie ta wizja wydawała się przerażająca. Jednak okazało się, że dzielenie się swoimi doświadczeniami daje dużo satysfakcji, a ten początkowy lęk ma też pozytywny aspekt objawiający się dokładnym przygotowaniem merytorycznym do każdego wpisu. W końcu nie chcę napisać jakiś bzdur i wyjść na debila 😀
Konkurs Daj Się Poznać 2017 dobiegł końca i przyszedł czas na podsumowanie. Nie chciałem brać się za to dopóki mój udział się nie zakończy. Byłem przekonany, że stanie się to po ogłoszeniu wyników głosowania zamkniętego. Jednak ku mojemu wielkiemu zaskoczeniu znalazłem się wśród 25 finalistów, którzy przeszli do otwartego głosowania. Ostatecznie uplasowałem się na 12 miejscu gromadząc 232 punkty. Moje zaskoczenie było jeszcze większe, kiedy okazało się, że zostałem wyróżniony przez jednego ze sponsorów konkursu – firmę Ivanti. Dziękuje w tym miejscu wszystkim, którzy głosowali, a także tym, którzy wchodzą na bloga i czytają to, co piszę.
Wracając pociągiem z Warszawy zacząłem sobie zapisywać, o czym chciałbym wspomnieć w podsumowaniu konkursu. Tematy, jakie chcę poruszyć to:
Wyszło tego naprawdę dużo i na pewno nie zmieszczę się ze wszystkim w jednym poście. Dzisiaj skupię się tylko na gali finałowej. Kolejne elementy z listy będą pojawiać się w następnych wpisach.