Programowanie i Robotyka
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.
Po omówieniu modyfikatora volatile w poprzednim wpisie, dzisiaj zajmę się drugim podobnym modyfikatorem – const. Modyfikator const jest często przedstawiany jako sposób deklarowania stałych liczbowych. W artykule wytłumaczę, dlaczego do definiowania pojedynczych stałych liczbowych lepiej nadają się inne mechanizmy oraz jak używać const w deklaracjach funkcji, aby uzyskać lepszą kontrolę typów.
Dzisiaj omówię element składni języka C, który jest rzadko tłumaczony większości kursów. W książce K&R został wspomniany zaledwie w trzech zdaniach, które zupełnie nie sugerowały, że może on być ważny. Chodzi o modyfikator volatile. Jego nieprawidłowe stosowanie może powodować:
W dzisiejszym artykule omówię element składni języka C, jakim jest dyrektywa preprocesora #define. Nie będzie to tekst przeznaczony dla początkujących. Skupię się raczej na bardziej zaawansowanych zastosowaniach, przydatnych sztuczkach i dobrych praktykach.
Zgodnie z założeniami, które nakreśliłem we wpisie o architekturze systemu, zabrałem się do projektowania prototypów funkcji poszczególnych bloków. Dzięki temu mogę zbudować szkielet aplikacji przechodzący przez wszystkie warstwy i stopniowo wypełniać go kodem. Główny nacisk położyłem na driverach powiązanych z warstwą sprzętową. Zależy mi na szybkim zaimplementowaniu driverów, żeby można było przetestować poprawność pracy poszczególnych podzespołów na docelowej płytce. Poza tym hardware jest najbardziej zależny od rzeczy narzuconych odgórnie i dobrze jest sprawdzić jak najszybciej, czy planowana koncepcja jest na pewno realizowalna. Zaktualizowany kod znajduje się na GitHubie projektu na gałęzi dev.
Ostatnio pisałem o walce z konfiguracją Travis-CI. Po kolejnych 30 próbach w końcu udało mi się go skonfigurować tak jak chciałem. Przy okazji musiałem pokonać kilka problemów, które opiszę w tym poście.
Ostatnio w pracy miałem pewien problem dotyczący znaków końca linii w Gicie. Skłoniło mnie to do poszukiwań w internecie, a zdobyte informacje postanowiłem zebrać w tym poście, żeby zostały na przyszłość.
Istnieją dwie konwencje dodawania znaków końca linii w plikach tekstowych. Wywodzą się one z dwóch głównych systemów operacyjnych:
Jeżeli więc nad tym samym projektem pracują osoby używające różnych systemów operacyjnych, pliki tworzone przez różne osoby mogą mieć różne konwencje końca linii. Co więcej, jeśli plik z linuksowymi znakami nowej linii jest edytowany w Windowsie, edytor tekstu może nadpisać istniejące znaki nowej linii w całym pliku lub użyć swojej konwencji dla nowo dodanych linii.
W ten weekend w końcu stanąłem do potyczki z konfiguracją Travis-CI. Długo to odkładałem, bo wiedziałem, że będą problemy. Chcę skonfigurować build system w dosyć niestandardowy sposób i nie mogę za bardzo skorzystać z wbudowanych w Travisa ułatwień. Zamiast tego muszę posiłkować się bashowymi skryptami. W wykonaniu zadania pomagają mi skrypty Freddie Chopina (link1, link2), któremu udało się skonfigurować podobny build system do tego, który chciał bym uzyskać. Nie udało mi się jeszcze wykonać poprawnego builda, dlatego dzisiaj opiszę ogólne spostrzeżenia do jakich udało mi się dojść. Nie składam jeszcze broni i pewnie pojawią się jeszcze kolejne wpisy w tym temacie opisujące mam nadzieję rozwiązanie problemu.