Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    344
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    16

GAndaLF wygrał w ostatnim dniu 17 sierpnia

GAndaLF ma najbardziej lubianą zawartość!

Reputacja

98 Bardzo dobra

O GAndaLF

  • Ranga
    6/10
  • Urodziny 01.01.1989

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Gdańsk
  • Języki programowania
    ASM, C, C++, Python
  • Zainteresowania
    robotyka embedded kolarstwo starcraft
  • Zawód
    Programista Embedded
  • www

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. @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.
  6. 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
  7. @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ół.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. A ten LinkerScript.ld skąd masz? Wygenerowany automatycznie przy zakładaniu projektu, czy też skopiowany z przykładu? Bo obstawiam, że wygenerowany się różni od oryginalnego.
  14. Streaming na RPi był zestawiany na szybko jako tymczasowe rozwiązanie, żeby tylko coś pokazać na prezentacji i szczerze mówiąc nie analizowaliśmy tematu za bardzo. O szczegóły realizacji muszę podpytać, bo ja akurat nad tym nie siedziałem.
  15. Już jakiś czas temu zebraliśmy się w pracy w kilka osób, żeby pomyśleć nad jakimś projektem, w którym moglibyśmy wykorzystać machine learning, chmurę i robotykę. Padło na jeżdżącego robota z kamerką, który mógłby służyć do mapowania terenu i umieszczania na tej mapie obiektów rozpoznanych przy pomocy kamery. Skończyło się na samym gadaniu i przez długi czas nic w tym kierunku nie robiliśmy. Aż w końcu przyszedł NASA Space Apps Challenge, gdzie postanowiliśmy wystartować z ekipą z firmy. Nasz pomysł przerodził się w łazika marsjańskiego, który miał pomóc pierwszym kolonizatorom Marsa w rozpoznaniu terenu dookoła obozowiska. Podczas 24-godzinnego hackatonu udało nam się poskładać coś co jeździ i streamuje obraz z kamery. Biorąc pod uwagę ile rzeczy nie chciało działać, to i tak sukces. Robota w akcji można zobaczyć na filmiku: Teraz trochę o bebechach: Raspberry Pi 3B+ - miał być na nim postawiony ROS, ale na razie tylko obsługuje kamerkę STM32F4 Discovery - miał być klient rosserial obrabiający komendy z ROSa, na razie jest prosta aplikacja sterująca na sztywno silnikami w pętli 4 moduły mostków H TB6612 kamerka USB Powerbank do zasilania logiki - aktualnie ogromny powerbank 30 Ah, bo taki mieliśmy pod ręką Lipol 2S 800 mAh do zasilania silników - docelowo zostanie tylko jedno zasilanie Płytka stykowa do podłączenia lipola, mostków H i switcha ON/OFF Podwozie Pirate 4WD Co jeszcze planowaliśmy: Intel RealSense - kamera RGB z czujnikiem odległości - układ jaki dostaliśmy nie działał w pełni - brak kamery RGB, sama chmura punktów. Poza tym były wielkie problemy z driverami. Intel Movidius - koprocesor do obliczeń na sieciach neuronowych. Dzięki temu będziemy mogli zrezygnować z chmury. Czujnik IMU - MinIMUv5 Pololu - podczas hackatonu nie było czasu podłączyć. Poza tym i tak ROS nie działał. Jeżeli chodzi o soft: większość funkcji miał zapewnić ROS działający na Raspberry. Nigdy go nie używaliśmy i chcieliśmy się pobawić modułami sensorów, nawigacji, analizy obrazów itp. na STM projekt powstaje w C++. Miał być system operacyjny DistoRTOS i docelowo będzie, ale na hackatonie nie było czasu go zintegrować. Repozytorium na razie nie zawiera zbyt wiele. Tylko prosty program w C++ sterujący na sztywno silnikami. Prawdopodobnie repo się mocno przeobrazi i będziemy je wykorzystywać do rozwoju projektu razem z issue trackerem, wiki itp. Kod można oglądać na GitHubie: https://github.com/ucgosupl/solwit_space_robot Części takie jak RealSense, czy Movidius dostaliśmy z sampli. Poza tym nasza firma - Solwit - zaangażowała się w projekt. Dostaliśmy między innymi Raspberry, mamy też w planach kilka kolejnych wydatków. Docelowo robot ma być wykorzystywany na różnych targach itp. Dodatkowo myślimy, żeby zrobić z niego pomocnika biurowego. Planujemy też wymienić Raspberry i Discovery na zintegrowaną płytkę z procesorem Intel Atom i STM32F4. Myśleliśmy zamiast tego o zastosowaniu Intel Euclid - platformy ze zintegrowanym RealSensem i prockiem z preinstalowanym ROSem, ale niestety Euclida nie ma w samplach. Zastosowane podwozie na filmiku działa dobrze, ale kiedy jeździ po wykładzinie, opony nie dają rady. Będziemy potrzebowali coś lepszego. Poza tym aktualne silniki nie mają enkoderów i ogólnie nie są najwyższych lotów. Aktualnie poszukuję jakiegoś gotowego podwozia 4-kołowego z enkoderami i porządniejszymi silnikami. Znacie może jakieś dobre modele? W grę wchodzi też zaprojektowanie własnego podwozia. Docelowo pewnie będziemy chcieli pójść właśnie tą drogą. Tylko nie mamy jeszcze sprecyzowanych wymagań, jakie stawiamy konstrukcji. Dlatego możliwe, że będzie kilka prototypów. Najlepiej je pewnie zrobić na drukarce 3D i dopiero ostateczną wersję wyciąć z jakiejś blachy. Przy okazji poszukujemy kogoś, kto mógłby nam takie podwozie zaprojektować. Najlepiej z okolic Trójmiasta. Więcej o robocie można przeczytać na moim blogu: https://ucgosu.pl/2018/10/lazik-z-nasa-space-apps-challenge-szczegoly-techniczne/
×
×
  • Utwórz nowe...