Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    345
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    16

GAndaLF wygrał w ostatnim dniu 17 sierpnia

GAndaLF ma najbardziej lubianą zawartość!

Reputacja

99 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. 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"
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. @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.
  7. 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
  8. @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ół.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Utwórz nowe...