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.
Kategoria: Daj się poznać 2017
Jak utrzymać zadowolenie z pracy
Praca zajmuje dużą część naszego dorosłego życia. W tygodniu, jeśli odliczymy czas na sen, jest to połowa dnia, a doliczając dojazdy i codzienne obowiązki – nawet więcej. Zadowolenie z pracy jest więc bardzo ważnym czynnikiem wpływającym na nasze samopoczucie. Dzisiaj zastanowię się nad satysfakcją z pracy, wypaleniem i sposobami na utrzymanie dobrego samopoczucia.
Prima aprilis 2017
Ledwo minęła północ, a już znalazłem w necie newsa: „Z ostatniej chwili – Liroy pobił Morawieckiego”. Dotarło to do mnie dopiero po chwili – no tak, Prima Aprilis można uznać za rozpoczęty. Jeden z cytatów z internetu głosi, że 1 kwietnia to jedyny dzień w roku, kiedy ludzie zastanawiają się, czy informacje, które przeczytali, zobaczyli w telewizji, czy znaleźli w internecie są prawdziwe. Dla firm z branży IT (i nie tylko!) jest to świetna okazja, aby pokazać kreatywność i poczucie humoru swoich pracowników. Postanowiłem w tym wpisie zebrać trochę primaaprilisowych żartów.
Dlaczego warto robić unit testy?
Ostatnio w pracy miałem do wykonania dosyć proste zadanie. Chodziło o to, aby w przerwaniu od timera wykonującym się co 10 ms umieścić funkcję, która miała wykonywać się co 100 ms. W tym przerwaniu już wcześniej był wywoływany task co 10 ms i obsługa komunikacji. Napisany przeze mnie kod wyglądał mniej więcej tak:
void irq_timer_10ms(void) { static int32_t cnt = 0; task_comm(); task_10ms(); cnt++; if (cnt < 10) { cnt = 0; task_100ms(); } }
Kryje się tutaj dosyć często spotykany błąd – warunek w ifie jest odwrócony. Funkcja zamiast wywoływać się raz na 10, wykonuje się 9 razy na 10. Po dodaniu tej zmiany uruchomiłem aplikację i na pierwszy rzut oka wyglądało, że działa. Nie miałem do dyspozycji żadnych unit testów, ani dokładniejszych testów na docelowym hardware, więc wypushowałem tę zmianę razem z kilkoma innymi.
Początek prac nad kodem
Płytka została oddana do produkcji, więc ostatnio było trochę czasu, żeby usiąść do softu. W tym tygodniu udało mi się zrobić kilka rzeczy:
- postawić projekt na STM32F4,
- dodać najnowszą wersję systemu FreeRTOS – 9.0.0,
- uruchomić framework do unit testów CppUTest.
Aktualny kod źródłowy projektu można znaleźć na moim GitHubie.
Poprawiony projekt płytki
Płytka robota, którą ostatnio zaprojektowałem, miała kilka wad. Głównym problemem była grubość ścieżek. Praktycznie wszystkie ścieżki miały tam 10 mils. Ścieżki zasilania i inne, po których mogą płynąć większe prądy powinny być odpowiednio grube. Grubsze ścieżki zapewniają mniejszą rezystancję. Poza tym jeśli płynie nimi większy prąd, mogą się nagrzać i uszkodzić. Zdarzały mi się już takie sytuacje przy wcześniejszych płytkach, ale jakoś nie wyciągnąłem z tego wniosków. Korzystając z faktu, że płytkę dopiero co wysłałem do produkcji, postanowiłem ją przeprojektować i podesłać poprawioną wersję.
Zestawienie wykorzystywanych elementów
Miałem na ten tydzień zaplanowanych kilka ciekawych rzeczy. Chciałem iść na spotkanie Hackerspace Trójmiasto i napisać z tego relację oraz rozpocząć pracę nad kodem źródłowym robota. Na pierwszy ogień miał iść framework do unit testów CppUTest i konfiguracja continuous integration. Niestety plany pokrzyżowała mi choroba i przez kilka ostatnich dni prowadzę tryb życia zbliżony do kota, gdzie w ciągu doby na kilka godzin aktywności przypada kilkanaście godzin leżenia. A kiedy próbuję zrobić coś produktywnego nagminnie zdarza mi się np. otworzyć przeglądarkę i zapomnieć co chciałem znaleźć. Tym bardziej mogę być z siebie zadowolony, że cokolwiek udało mi się zrobić. Przez cokolwiek rozumiem wygenerowanie listy elementów potrzebnych do budowy robota i określenie jakie elementy mam na stanie, a jakie muszę dokupić.
Projekt płytki drukowanej
Po zrobieniu schematu ideowego przyszła pora na projekt płytki PCB. Udało mi się uwinąć z tym zadaniem w weekend. W tym poście opiszę, czym się kierowałem przy projekcie PCB.
Wymiary robota
Pierwszym krokiem do stworzenia PCB było określenie wymiarów. Byłem tutaj ograniczony przez program Eagle, który wykorzystałem do zrobienia projektu. Maksymalny rozmiar płytki możliwy w darmowej wersji programu to 80x100mm. Minimalna szerokość musiała być taka, aby zmieściły się dwa mocowania silników – długość jednego to 23mm, a szerokość to 40mm. Szerokość z zamontowanymi kołami to 50mm. Ostatecznie zdecydowałem, że pomiędzy silnikami umieszczę jeszcze baterię i szerokość wyniesie 60mm. Przed mocowaniami silników po zostawieniu miejsca na koła zdecydowałem się na zwiększenie szerokości do 80mm i wyprofilowanie kształtu półkola. Wzorowałem się tutaj na istniejących robotach. Takie rozwiązanie jest standardem, a przykłady można obejrzeć tu(należy wybrać Projects->Micromouse), tu i tu. Jak bym chciał być pro, to mogłem jeszcze tam wyciąć ze środka część PCB dla odchudzenia konstrukcji. Jednak nie byłem pewny, czy się ze wszystkim zmieszczę, a dopóki nie będę chciał rywalizować z najlepszymi Micromouse na zawodach w Japonii raczej nie będę musiał dbać o każdy gram. Ostateczny kształt płytki można obejrzeć na rysunku. Obraz jest mocno zaciemniony przez żółte linie reprezentujące niedokończone połączenia, których oczywiście zapomniałem wyłączyć do screena. Jednak obrys robota i rozmieszczenie najważniejszych elementów są widoczne.
Sandro Mancuso – Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja – recenzja
Po raz kolejny dałem się złapać na ten sam chwyt. Jak widzę, że na Helionie jest promocja, nie mogę się powstrzymać i zawsze kupuję jakąś książkę. Dobrze, jeśli kończy się tylko na jednej. Tym razem padło na „Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja” autorstwa Sandro Macuso, która została wybrana przez Helion książką roku 2017 w kategorii programowanie. O książce wiedziałem już wcześniej, ale nie byłem do niej dobrze nastawiony, ponieważ bycie rzemieślnikiem w programowaniu kojarzyło mi się ze żmudnym wyrabianiem godzin i klepaniem ciągle tego samego kodu. Ciekawe, kto chciał by napisać książkę na ten temat. Tak naprawdę ruch Software Craftsmanship promuje postawę ciągłego podnoszenia swoich umiejętności, dbania o jakość dostarczanych produktów i udoskonalania swojego programistycznego warsztatu. Celem jest dążenie do mistrzostwa w swojej profesji.
Schemat ideowy robota
Prace nad robotem ruszyły. Dodałem pierwsze commity na GitHuba, wybrałem licencję dla projektu (tym aspektem zainteresowałem się dzięki Slackowi konkursowemu, normalnie bym olał ten temat), dodałem krótkie readme, a przede wszystkim zrobiłem schemat ideowy robota. W tym wpisie opiszę wykonany schemat.
Do wykonaniu schematu użyłem programu Cadsoft Eagle 7.2, czyli starszej wersji programu wydanej jeszcze zanim Eagle został kupiony przez Autodesk. Początkowo chciałem wypróbować nową wersję, ale stwierdziłem, że płytki projektuję raz na kiedyś, w tej wersji mam wszystko czego potrzebuję łącznie z customowymi bibliotekami elementów i poznawanie nowej wersji będzie startą czasu. Zamiast tego wolę skupić się na narzędziach programistycznych. Cały schemat prezentuje się następująco:
W kolejnych rozdziałach omówię poszczególne moduły.