Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    357
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    16

GAndaLF wygrał w ostatnim dniu 17 sierpnia 2019

GAndaLF ma najbardziej lubianą zawartość!

Reputacja

120 Mistrz

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. 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.
×
×
  • Utwórz nowe...