Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    357
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    16

Wszystko napisane przez GAndaLF

  1. Ostatnio trochę zapominałem informować o streamach. W zeszłym tygodniu był odcinek o IDE i debugerach sprzętowych na embedded: Możecie też na moim blogu znaleźć dodatkowe informacje: https://ucgosu.pl/2020/05/stream-o-ide-i-debugerach-sprzetowych/ Wcześniej był też odcinek z analizą udostępnionego projektu respiratora do walki z Koronawirusem: Za to w czwartek o 20:00 będzie kolejny odcinek, tym razem o językach programowania w embedded. Skupię się głównie na czterech - C, C++, Ada, Rust:
  2. Po pierwsze - jeżeli 4000 linii ma cały projekt to jeszcze nie jest zbyt duży. Jeżeli tyle ma pojedynczy plik, jego edycja jest już mocno uciążliwa. Chociaż zdarzają się i kilkukrotnie większe pliki. Jednak już przy 4000 na cały projekt widać pewne problemy projektowe i właśnie ich doświadczasz Te problemy to zwykle brak dokumentacji i nie wiadomo jaki jest cel danego kodu, brak sensownego podziału na elementy składowe - podział jest zwykle wymuszony np. przez peryferia, długie funkcje robiące wiele rzeczy na raz, często z jakimiś dziwnymi konstrukcjami. Jeżeli to projekt na uczelni, który ma już swoje lata to pewnie wszystkie te rzeczy występują i może jeszcze różne inne. Dla embedded niestety nie ma jasno sprecyzowanych wzorców co do których wszyscy się zgadzają i stosują je w praktyce. Jest raczej wolna amerykanka i kod bardziej podchodzący pod antywzorce. Ja od jakiegoś czasu już staram się szukać takich wzorców na własny użytek i jakoś je generalizować do całego embedded i opisuję to właśnie na https://ucgosu.pl jak wspomniał @Matthew11 W moich materiałach znajdziesz coś na ten temat tutaj: https://ucgosu.pl/materialy-do-nauki-embedded/ https://ucgosu.pl/projekt-embedded/ Robię też na YouTube livestreama, gdzie poruszam te tematy: I ostatnio szykuję szkolenie online z C. To tyle z autopromocji, teraz przechodząc do odpowiedzi: 1. Czy monolit jest typową praktyką? Rozumiem, że chodzi Ci o podział monolit/mikroserwisy jak w aplikacjach webowych? Tutaj najbliższym odpowiednikiem mikroserwisów (czy ogólnie serwisów na różnych serwerach) jest stosowanie kilku procesorów. I odpowiedź brzmi - zależy od projektu. Bardzo dobrze sprawdzają się konstrukcje w stylu dedykowany procesor do obsługi wyświetlacza graficznego, czy obsługi innych zadań mało krytycznych a wymagających dla procesora. Możliwa też jest opcja z jednym procesorem i RTOSem, albo jakieś inne podejście do wielozadaniowości na jednym procesorze (np. przerwania, maszyny stanów). 2. Czy sensowne jest używanie zmiennych globalnych (np wartości, które coś konfigurują, wymieniają dane między funkcjami), czy np.: lepiej przekazywać wskaźniki do tych danych między funkcjami? Generalnie zmienne globalne to zło. Wskaźniki do zmiennych globalnych, czy nawet settery gettery to też zło, tylko bardziej ukryte. Mamy dokładnie te same problemy (współbieżność, modyfikacja z wielu miejsc, problemy z zależnościami). Mi się podoba koncepcja interfejsów opisujących konkretne czynności wystawianych przez moduł zamiast dawania na zewnątrz kontroli nad szczegółami implementacyjnymi. To może szczególnie zaboleć przy większym refactorze. Obrazując koncepcję interfejsu - załóżmy, że sterujemy silnikiem. ZŁA PRAKTYKA: set direction, set speed, set flags itd. DOBRA PRAKTYKA: konkretne funkcje: move_forward(speed), stop() itd W ten sposób ukrywamy informacje, że jest jakaś zmienna direction i jakieś flagi. Potem jak zmieni nam się koncepcja to nie musimy przerabiać połowy innych modułów bo z ich perspektywy funkcje wysokopoziomowe zostają te same. Osiągnięcie czegoś takiego jest trudne i często wymaga dostosowywania się na bieżąco wraz z wzrostem naszej wiedzy o problemie - dlatego nie bój się wprowadzać zmian. 3. W przypadku gdy chcemy odłączyć jakiś podzespół, załóżmy jakiś czujnik temperatury dla przykładu , to lepiej tworzyć jakąś flagę czy lepszym wyborem będą dyrektywy procesora. Chodzi Ci o nie wywoływanie jakiejś części kodu? Tutaj opcji jest więcej - możesz też na przykład korzystać z usuwania niewykorzystywanych funkcji przez linker. Ale generalnie - musisz sobie odpowiedzieć na pytanie, czy chcesz na sztywno odłączać podczas kompilacji, czy dynamicznie zmieniać w trakcie działania programu. W drugim przypadku musisz bazować na konfiguracji jakimiś zmiennymi. Pozostaje natomiast kwestia obudowania tego czytelnymi interfejsami. 4. Gdy wyodrębniamy jakiś element kodu do zewnętrznej funkcji, warto by operował na wskaźnikach czy normalnie przyjmował kopie danych i zwracał daną? Wiem, że popadanie w optymalizacyjną paranoje nie ma czasem sensu, ale być może ktoś bardziej doświadczony jest w stanie odpowiedzieć co warto stosować, a co jest przesadą. Jeżeli przekazujesz argumenty przez kopię i funkcja nie ma wewnętrznego stanu zachowanego między wywołaniami - możesz ją bezpiecznie używać przy wielowątkowości. To na pewno duży plus. Kolejna kwestia ze wskaźnikami jest taka, że masz całą gamę dodatkowych błędów, które możesz przypadkiem popełnić - nadpisanie nie swoich danych, przekazanie wskaźnika w kilka miejsc na raz, nadpisywanie wskaźnika wykorzystywanego właśnie przez hardware, nullpointery, unaligned access itd. Dlatego tak jak mówił @Matthew11 - przez wskaźnik przekazujesz duże obiekty jak tablice, czy struktury. A przy pojedynczych zmiennych lepiej dawać argument przez wartość, a modyfikację zwracać jako wynik. Jako referencyjny projekt polecam kod PW-Sat2 - satelity rozwijanego przez studentów Politechniki Warszawskiej i pisanego w C++: https://pw-sat.pl/ https://github.com/PW-Sat2/PWSat2OBC
  3. @RomekAtomek czas całkowania zawarty jest we wzmocnieniu członu całkującego k_i, tak samo okres próbkowania. To jest typowe przekształcenie przy implementacji PID w kodzie. A te limity są właśnie, żeby nie było overflowa. Ma to nawet swoją nazwę w teorii: anti-windup
  4. Cześć! We wtorek o 20:00 robię kolejnego streama. Tematem będzie praca zdalna w embedded. Odpowiemy sobie na pytania: Jak pracować zdalnie w branży embedded? Czy to w ogóle możliwe na dłuższą metę? Jak się do tego zabrać? Link do transmisji: Temat był już wspomniany podczas odcinka o tym jak wygląda ogólnie praca w embedded, jednak aktualna sytuacja wymaga szerszego omówienia. W planie mam między innymi: - Moje dotychczasowe doświadczenia z pracą zdalną. Co się sprawdzało, a co nie. - Jakie warunki musisz spełnić, żeby dało się pracować zdalnie? - Typowe problemy - sprzęt, sprzęt i jeszcze raz sprzęt - Narzędzia i techniki programistyczne, które mogą pomóc - unit testy, continuous integration, testy automatyczne na HW, code review, dokumentacja - Wsparcie sprzętowe - zasilacze sterowane, zdalny debug, generatory, sniffery, analizatory, symulatory, emulatory - Jak przygotować projekt na możliwość pracy zdalnej? - Gaszenie pożaru - jak pracować zdalnie z projektem, który nie jest na to gotowy? Jeżeli chcecie wiedzieć coś jeszcze w tym temacie - piszcie w komentarzach. Jeżeli macie jakieś sprawdzone sposoby na tematy wymienione w powyższej liście - również możecie się podzielić.
  5. Kolejne spotkanie odbędzie się w środę 4 marca tradycyjnie w Inkubatorze STARTER ul. Lęborska 3B, Gdańsk: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/268530120/ Harmonogram: 18.00 Paweł Krzyżanowski - "Systemy czasu rzeczywistego (RTOS) – techniki, wzorce, pułapki i dobre praktyki" 19.00 Przerwa na pizzę 19.20 Piotr Suwala - "Timery w STM32 - jak zrozumieć dokumentacje i porządkować swoją pracę" Po raz kolejny spotkanie będzie nagrywane. Mam nadzieję, że tym razem nie zaskoczą mnie rozładowane baterie w dyktafonie i dźwięk się nagra jak trzeba.
  6. Są już nagrania z lutego: Zapraszamy na kanał meetupu na YT, gdzie będą dodawane kolejne: https://www.youtube.com/channel/UCws6uU6LUrHH-Byl171gpTA
  7. Od kilku tygodni robię na YouTube livestreamy o różnych tematach związanych z embedded. Streamy zwykle poruszają jakieś tematy techniczne, które próbuję na bieżąco zaprezentować w formie livecodingu. Do tej pory dwa odcinki były o Test Driven Development, a dwa kolejne o kompilatorze, linkerze i co się dzieje przed mainem w C w mikrokontrolerach. Przy okazji omawiane przykłady trochę zahaczają o różne tematy związane z systemami safety-critical (może poza pierwszym odcinkiem), żeby było też coś ciekawego dla osób bardziej zaawansowanych. Konwencję streama wzoruję na Gynvaelu Coldwindzie - jak ktoś widział to wie o co chodzi, a jak nie to polecam zobaczyć: https://www.youtube.com/user/GynvaelColdwind/videos https://www.youtube.com/user/GynvaelEN/videos Czyli w każdym odcinku jakieś ciekawe problemy rozwiązywane na bieżąco bez przygotowania wszystkiego dokładnie wcześniej. Dlatego mam nadzieję, że uda się pokazać nie tylko rozwiązania problemów, ale też drogę do ich osiągnięcia i czasem też błędy i sposób radzenia sobie z nimi. Kolejny odcinek odbędzie się dzisiaj (środa 19.02.2020) o godzinie 20:00. Temat tym razem będzie nietechniczny, ale mam nadzieję, że ciekawy. Będę mówić jak wygląda praca w branży embedded. W planie mam takie zagadnienia: - Studia - czy trzeba zacząć już przed studiami, jaki kierunek wybrać, czy w ogóle opłaca się studiować, czy idąc na studia musisz już wiedzieć co chcesz w życiu - Pierwsza praca - praca w trakcie studiów, szukanie pierwszej pracy w zawodzie, pierwsza rozmowa kwalifikacyjna - Praca w korpo - Praca w małym startupie - Praca w dużym software house - Praca w średniej firmie - Kiedy zmienić projekt/pracę - Wypalenie, work-life balance - Rozwój i dodatkowe inicjatywy - Czy da się pracować zdalnie w embedded - Jak zmieniał się mój sposób pracy na przestrzeni lat Zobaczymy, czy uda się wszystko omówić. Możecie również zadawać pytania w komentarzach, jeżeli coś was szczególnie interesuje. Link do transmisji: Playlista ze wszystkimi odcinkami: PS. Nie wiem czy to dobra kategoria, ale do żadnej mi za bardzo nie pasowała. Także @Treker proszę o przeniesienie, jeżeli jest na to lepszy dział.
  8. Piąte spotkanie Gdańsk Embedded Meetup we wtorek 4 lutego w Inkubatorze STARTER ul. Lęborska 3B, Gdańsk https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/267790698/ Harmonogram: 18.00 Maciej Godek - "Dobre praktyki (których nie ma) na Embedded" 19.00 Przerwa na pizzę 19.20 Karol Trzciński - "Jak się nie zgubić - lokalizacja wewnątrzbudynkowa" W pierwszej prezentacji otworzymy puszkę pandory i porozmawiamy o jakości kodu w systemach embedded. Szykuje się roast bibliotek do peryferiów typu Cube i parę gorzkich słów o tym jak projektujemy systemy, wydzielamy interfejsy i testujemy poprawność kodu. Po przerwie natomiast będziemy mogli posłuchać o lokalizacji za pomocą fal radiowych. Pewnie więc będzie trochę zaawansowanej matematyki, może jakieś gotowe rozwiązania hardware'owe i doświadczenia z istniejących systemów tego typu. Jak zwykle - będzie ciekawie. Nieoficjalnie mogę też zdradzić, że planujemy po raz pierwszy nagrywać prezentacje.
  9. Następne spotkanie 7 stycznia o 18.00 w Inkubatorze STARTER ul. Lęborska 3B, Gdańsk https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/266958702/ Harmonogram: 18.00 Grzegorz Ficht - "Roboty Humanoidalne grające w piłkę nożną" 18.50 Przerwa na pizzę 19.10 Maciej Kraszewski - "Wizualizacja danych w systemach embedded za pomocą technologii webowych" Grzegorz, który jest również na Forbocie @mog123 opowie nam o: Po nim przyjdzie kolej na Macieja Kraszewskiego, który opowie jak wykorzystać technologie webowe do wizualizacji danych. Jest to bardzo przydatna wiedza w kontekście IoT i smart sensorów. Bardziej szczegółowe info o prezentacjach i prelegentach w linku powyżej. Zapraszam do przyjścia!
  10. Kolejne spotkanie już 3 grudnia o 18.00 w Inkubatorze STARTER ul. Lęborska 3B, Gdańsk. https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/266282842/ Harmonogram: 18.00 Dawid Linowski - "Układy FPGA w zastosowaniach kosmicznych" 18.50 Przerwa na pizzę 19.10 Arkadiusz Jędrzejewski - "Conan - menadżer pakietów dla C/C++" Pierwsza prezentacja będzie połączeniem dwóch niesamowicie ciekawych tematów. Jednym z nich jest FPGA, a drugim systemy działające w kosmosie. Dawid opowie nam o FPGA w kosmosie z perspektywy osoby, która zawodowo zajmuje się takimi systemami. Po przerwie zejdziemy na ziemię i wrócimy do uwielbianego przez wszystkich tematu, czyli C i C++. Arek opowie nam o menadżerze pakietów Conan i pokaże, że programowanie w tych językach może być jeszcze fajniejsze. Bardziej szczegółowe info o prezentacjach i prelegentach w linku powyżej.
  11. @szczawiosław ja też się z rok czaiłem przed zorganizowaniem. A wcześniej jeszcze co najmniej drugie tyle byłem w fazie "fajnie jakby ktoś coś takiego u nas zorganizował". Mam zamiar gdzieś spisać jak wygląda organizacja takiego meetupu i z czym się liczyć, żeby w ogóle wystartować. Jeszcze nie wiem na kiedy się uda to przygotować. Ale jakbyś chciał coś takiego zrobić u siebie to mogę coś pomóc na PW.
  12. Drugie spotkanie odbędzie się 5 listopada o 18:00. Jeszcze jesteśmy w trakcie umawiania miejscówki. Link do wydarzenia: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/events/265871940 Pierwsza prezentacja poruszy problem, który niejednemu programiście spędza sen z powiek - błędy związane z pamięcią. Istnieje wiele mitów mówiących o tym, że C++ nie nadaje się do Embedded, ponieważ programy napisane w tym języku są wolniejsze i potrzebują dużo więcej pamięci od tych napisanych w C. Jak się okazuje, nic bardziej mylnego - C++ jest coraz częściej wybierany do tego typu projektów i zdecydowanie warto się nim zainteresować. Abstrahując od tego, który język nadaje się lepiej, zarówno w C, jak i C++ zdarzają się błędy w pamięci, które potem trzeba zdebugować. O tym, jak taki proces wygląda w C++ dowiemy się na pierwszej z listopadowych prezentacji. Po przerwie przyjdzie pora na coś luźniejszego - Łukasz opowie o robotach dla dzieci. Z jednej strony temat może interesować studentów, bo zajęcia z robotyki dla dzieci to dobry sposób na dorobienie sobie podczas studiów. Natomiast starsi uczestnicy mogą być ciekawi jak zainteresować swoje dzieci kreatywną i przyszłościową rozrywką jaką jest robotyka. Więcej szczegółów o drugiej prezentacji już wkrótce. Na razie mogę zdradzić, że nie będzie ona dotyczyła Lego Mindstorms, tylko skupi się głównie na bardziej zaawansowanych zestawach. Harmonogram: 18.00 Mateusz Nowak - "Debugowanie błędów w pamięci przy użyciu C++" 18.50 Przerwa na pizzę 19.10 Łukasz Kaczmarczyk - "Robot edukacyjny dla dzieci" Możecie również obejrzeć kilka zdjęć z pierwszego spotkania: https://www.meetup.com/pl-PL/Gdańsk-Embedded-Meetup/photos/30434633/
  13. 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"
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. @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.
  19. 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
  20. @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ół.
  21. 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
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Utwórz nowe...