Skocz do zawartości

GAndaLF

Użytkownicy
  • Zawartość

    329
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    15

GAndaLF wygrał w ostatnim dniu 5 marca

GAndaLF ma najbardziej lubianą zawartość!

Reputacja

80 Bardzo dobra

O GAndaLF

  • Ranga
    6/10
  • Urodziny 01.01.1989

Informacje

  • Płeć
    Mężczyzna
  • Zainteresowania
    esport/elektronika
  • Zawód
    Student

Ostatnio na profilu byli

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

  1. GAndaLF

    STM32F103C8Tx - komunikacja i2c jako slave

    Sądząc po rozszerzeniach plików projektu (xcodeproj, pbxproj), to był projekt na XCode na Maca. Najprawdopodobniej w ustawieniach projektu były dodane jakieś specjalne definy, flagi kompilacji itp, które powodują, że twoja kompilacja się różni. Możesz spróbować odszukać ustawień z plików projektu - są w xmlu, więc powinieneś być w stanie znaleźć odpowiednie pola. Tylko może to wymagać trochę wiedzy i doświadczenia.
  2. GAndaLF

    Praca jako konstruktor robotów

    Moim zdaniem taka umowa właśnie jest czymś dziwnym, bardzo możliwe, że nawet łamie jakieś prawo pracy, czy coś takiego. Rozumiem, że chciałbyś zajmować się konstrukcją mechaniczną robotów. To jest dosyć wąska specjalizacja. Pewnie musiałbyś uderzać do jakiejś większej firmy, gdzie jest większy zespół i wyraźny podział obowiązków. Wątpię, żeby w Polsce było dużo takich firm robiących własne roboty. Ale jak będziesz w tym dobry, to pewnie i tak sobie poradzisz. Skoro masz jeszcze 1.5 roku studiów, to najlepiej rozwijaj się w tym co lubisz i w czym jesteś dobry. Do tego nie olewaj wiedzy z tematów pokrewnych, które też się mogą przydać. Nie ograniczaj się do tego co jest na uczelni, tylko próbuj jakiś własnych projektów, albo grupowych w kołach naukowych itp. Do tego spróbuj poszukać ofert na wymarzone docelowe stanowisko np. w jakiejś NASA czy SpaceX i zobacz jakie mają wymagania.
  3. GAndaLF

    Przełączanie diody LED problem

    Żeby się dowiedzieć, w czym jest problem musisz rozbić sprawdzanie na etapy: 1. Sprawdź, czy funkcja LED() zapala diodę. 2. Sprawdź, czy funkcja LED2() gasi diodę. 3. Sprawdź, czy przerwanie się wywołuje i robi to co chcesz. Jak każda część działa poprawnie, program w całości też raczej będzie działać. Zakładam, że nie masz do AVRa debuggera i musisz po prostu wykomentowywać części kodu, kompilować i sprawdzać świeceniem leda. Jak chcesz się nauczyć programować to musisz się hartować od początku Zawsze na początku coś nie działa i im szybciej się nauczyć drążyć temat, tym lepiej.
  4. GAndaLF

    Filtracja wyników z żyroskopu Kalmanem

    Fajnie, że sobie poradziłeś. Jak widać wystarczy parę pytań i metoda gumowej kaczki
  5. Zobacz temat na StackOverflow: https://stackoverflow.com/questions/2100448/multiple-target-patterns-makefile-error W linijce: EXTRA_SOURCE_DIR = ../../:Programowanie_AVR_library/ masz dwukropek w ścieżce. Przy okazji co to jest za makefile? Skąd go masz? Bo raczej nie jest napisany zgodnie ze sztuką (chociaż mówienie o sztuce w odniesieniu do Makefile jest trochę nie na miejscu ) i może zawierać inne błędy.
  6. GAndaLF

    Filtracja wyników z żyroskopu Kalmanem

    Nie sprecyzowałeś dokładnie co właściwie chcesz zrobić. To trochę za mało informacji. Jakie dokładnie wartości fizyczne mierzysz? Czy chcesz tylko odszumić pomiary z każdego kanału, czy zrobić fuzję danych z obu sensorów w celu zwiększenia dokładności? Czy chodzi ci tylko o szum, czy np. dryft też? Czy sensor stoi na biurku i działa na niego tylko grawitacja, czy się porusza? Pytań jest sporo, wszystkie jakoś wpływają na model układu. Czyli jest to pomiar jednej losowej wartości, czy wielu losowych wartości? Filtr Kalmana z definicji służy właśnie do estymowania wartości zmiennych losowych obarczonych białym szumem więc to akurat nie powinien być problem. W jednym z artykułów wspomnianych przez Trekera (https://forbot.pl/blog/filtr-kalmana-od-teorii-praktyki-2-id3885) jest właśnie poruszane zagadnienie odczytów z akcelerometru i żyroskopu. Czym różni się twój przypadek od tego z artykułu? W ten sposób możesz sprawdzić, czy kod się kompiluje i odpala na procku, ale jeżeli model obiektu zupełnie mija się z prawdą, wyniki będą zupełnie z księżyca i tak naprawdę nie dostaniesz odpowiedzi na pytanie, czy kod właściwie działa. Co więcej przy strojeniu Kalmana możesz napotkać wiele subtelnych błędów np. z czasem próbkowania, wyborem stanu początkowego, czy doborem macierzy szumów. Żeby je rozwiązać, trzeba trochę podziałać metodą prób i błędów, ale niezbędne jest też zrozumienie teorii chociaż na tyle, żeby wiedzieć jaki dana zmiana będzie mieć spodziewany wpływ.
  7. GAndaLF

    ARM Cortex M-3 a biblioteka STL

    Od około pół roku w pracy rozwijam projekt medyczny na STM32 w C++11. I muszę powiedzieć, że na początku miałem obawy takie same jak wy: narzuty, alokacja dynamiczna itp. Muszę jednak przyznać, że dobrze używany modern C++ w embedded jest niesamowicie wręcz przydatny. Język C++ opiera się na koncepcji zero cost abstractions - możemy używać klas, templatów i innych konstrukcji, które daje nam C++ aby zwiększyć czytelność kodu i zminimalizować ilość głupich błędów, a jednocześnie po kompilacji otrzymujemy ten sam kod w assemblerze. Musimy tylko włączyć optymalizację O2. Pisałem o tym na swoim blogu, przy okazji w linkowanym artykule możesz znaleźć trochę bibliotek do C++ na embedded: https://ucgosu.pl/2018/05/przydatne-biblioteki-c-stm32/ Przykładowy sposób na poprawienie procedur manipulacji rejestrami sprzętowymi można znaleźć np. w tym artykule: https://mklimenko.github.io/english/2018/06/19/write-only-variables/ To tylko wprowadzenie do tematu, jest cały ruch propagatorów C++ w embedded, którzy tworzą między innymi swoje własne biblioteki do rejestrów. Warto odwiedzić takie strony jak: https://embeddedartistry.com/ https://blog.feabhas.com/ http://kvasir.io/ https://modm.io/ Natomiast co do użycia biblioteki STL i vector - STL jest pisany z myślą o użyciu dynamicznej alokacji i exceptionów. Dlatego tylko mały jej podzbiór dobrze współgra z embedded. Istnieje za to biblioteka ETL, która stara się zapewnić potrzebne funkcjonalności w sposób bezpieczny dla systemów embedded - https://www.etlcpp.com/ Przy okazji zachęcam do śledzenia mojego fanpage na fejsie, gdzie od niedawna staram się wrzucać materiały z neta dotyczące C++ w embedded: https://www.facebook.com/ucgosupl/ I zachęcam też do korzystania z Twittera - tam dużo osób wrzuca materiały o embedded C++ polecam na początek użytkowników: https://twitter.com/mbeddedartistry https://twitter.com/odinthenerd No i oczywiście zachęcam do własnych eksperymentów z C++ w embedded. Moim zdaniem to jest przyszłość branży.
  8. Jeżeli chodzi o programowanie mikrokontrolerów komercyjnie to faktycznie do prototypów można użyć generatora, a docelowe rozwiązanie często jest napisane na rejestrach. Pisząc komercyjnie musimy brać pod uwagę poza szybkością wykonania jeszcze takie aspekty jak licencja i możliwość certyfikacji np. zgodność z MISRA C. To ostatnie szczególnie ważne jeżeli piszemy coś wojskowego, medycznego, automotive itp.
  9. Przy zwiększaniu czytelności kodu pisanego na rejestrach niestety nie masz zbyt wiele pola manewru. Twoimi przyjaciółmi powinny być #define i komentarze. Możesz też inicjalizację pojedynczych peryferiów zwijać w oddzielne funkcje. Moje moduły hw operujące na rejestrach wyglądają na przykład tak jak tutaj: https://github.com/ucgosupl/mm_legend_v2/blob/dev/src/hw/adc/adc.c W powyższym kodzie można jeszcze define niektórych wartości bitowych przenieść oddzielnych headerów z zestawem wszystkich define dla danego peryferium tworząc uzupełnienie bibliotek procka. Tak naprawde powinien to dla nas zrobić producent, a te definy były tylko dostępne jako część StdPeriph pod nieintuicyjnymi nazwami. Być może STM już wydał jakieś nowe headery.
  10. Jeżeli dopiero zaczynasz, na pewno łatwiej Ci będzie najpierw poznać 8-bitowce, a dopiero potem przesiąść się na STM32. Natomiast jeżeli masz zamiar najpierw nauczyć się STM, a potem przesiąść na 8-bitowce to tak jak pisałem wcześniej, nie będziesz musiał się uczyć niczego nowego, przeczytanie dokumentacji wystarczy. Faktycznie zapomniałem, że każdy na STM pisze na bibliotekach producenta, bo sam nigdy ich nie tykałem tylko zawsze wszystko na rejestrach. Wtedy faktycznie przejście na 8-bitowce i pisanie na rejestrach rozwinie nowe umiejętności. Powinieneś poznać 8-bitowce, albo popróbować cokolwiek z rejestrami na STM32 aby mieć pojęcie co te biblioteki robią pod spodem. Podczas debugowania peryferiów i tak będziesz musiał wiedzieć, czy zapalone bity oznaczają taką konfigurację jaką chciałeś. Najlepiej poznać rejestry po napisaniu kilku pierwszych programów, kiedy już wiesz że umiesz coś zrobić i chcesz to dalej zgłębiać. Jeżeli chodzi o sposób nauki, to nie ma tutaj nic odkrywczego - praktyka czyni mistrza. Przykładowy plan może wyglądać tak: 1. Proste programy obsługujące poszczególne peryferia dokładnie jak w kursach. 2. Łączenie kilku peryferiów w jednym programie np. ADC wyzwalane timerem i wynik zapisywany do bufora przez DMA. 3. Jakiś własny projekt np. prosty robot. Przy okazji nauczysz się wtedy projektowania całej aplikacji i zdobędziesz wiedzę z tematów pokrewnych typu silniki, sensory elektronika. Nie da się programować embedded bez tej wiedzy. 4. Zdobywanie wiedzy ogólnej o programowaniu embedded (artykuły, książki itp) - mając trochę doświadczenia powinieneś uzupełnić podstawy teoretyczne. Dzięki temu będziesz wiedział np. dlaczego nie wołać printfa w przerwaniach, co się dzieje między uruchomieniem zasilania a wejścia procka do funkcji main, jak dobrze wykorzystywać przerwania itp. Oczywiście w międzyczasie nową wiedzę warto stosować w praktyce. A jak chcesz dokładnie wiedzieć co się dzieje pod spodem to polecam najpierw programowanie rejestrów, a jak chcesz wiedzieć więcej to możesz pobawić się z assemblerem. Wtedy dowiesz się jakie rejestry CPU do czego są używane, jakie są tryby adresowania, jak się korzysta ze stosu i różne inne niskopoziomowe rzeczy.
  11. Zastosowanie dla 8-bitowców na pewno znajdziesz, natomiast jeśli nauczysz się dobrze programowania embedded na jakiejś rodzinie 32-bitowej, nie będziesz się musiał 8-bitowców specjalnie uczyć. Po prostu przeczytasz noty katalogowe, poznasz kompilator, IDE, debugger i sobie poradzisz. Poza peryferiami jest tylko kilka zagadnień specyficznych dla 8-bitowców np. jest mniej pamięci FLASH i RAM, więc musisz brać to pod uwagę przy pisaniu i często nie ma debuggera, bo szkoda na niego nóżek i trzeba sobie z debugowaniem radzić jakoś inaczej. Jednak zdecydowana większość wiedzy zdobytej na jednej rodzinie procesorów przenosi się również na inne rodziny.
  12. Jest kilka możliwości rozwiązania Twojego problemu. 1. Możesz zastosować RTOS, wtedy obsługę LCD umieszczasz w oddzielnym tasku. Do delayów służą wtedy odpowiednie funkcje RTOS, które oddają sterowanie innemu wątkowi w tym czasie. Zaletą tego rozwiązania jest bardzo mała ingerencja w istniejący kod. Wadą potrzeba poznania RTOSa i zmiana architektury całego programu pod niego. 2. Możesz przepisać bibliotekę wykorzystując przerwania i maszyny stanu. Jest to dosyć skomplikowane i wymaga najprawdopodobniej przepisanie całego drivera LCD. Możesz na przykład wykorzystać przerwanie od timera uruchamiane co określony przedział czasu. W jednym obiegu przerwania wykonujesz operacje, które możesz zrobić od razu, a jak musisz na coś czekać, zapisujesz stan i wychodzisz. W następnym wejściu do przerwania ze stanu odczytujesz w którym miejscu kontynuować. Taki driver wykonuje bardzo niskopoziomowe operacje - zwykle będzie to wysyłanie komend, które poznasz czytając dokumentację. Będziesz też potrzebował mechanizm wyższego poziomu, który kolejkuje zadania wyższego poziomu np. teksty składające się z wielu znaków. To rozwiązanie jest chyba jeszcze bardziej skomplikowane niż poprzednie. To tyle jeśli chodzi o opcje implementacji nieblokującej LCD. Jak widać, stwarzają one spore trudności i jeśli jesteś początkujący, możesz mieć problemy. Możesz jednak podejść do problemu trochę inaczej. Sprawdzi się to, jeżeli nie będziesz chciał rozbudowywać już aplikacji o kolejne taski. Otóż możesz zostawić wyświetlanie LCD w pętli głównej, a odczyt ADC i obsługę PID dać do przerwań. ADC może na przykład pomiar zapisywać w zmiennej, a przerwanie timera o niskim priorytecie będzie obsługiwać obliczanie PID korzystając z wartości ADC. Dzięki temu możesz dalej korzystać z gotowej biblioteki, a program pozostanie prosty i nie dojdą nowe zależności.
  13. Tak naprawdę nie musisz realizować wszystkich kroków z artykułu. Wystarczy podłączyć zasilanie i analizator do TSOPa i odczytać przebiegi dla wszystkich możliwych przycisków. To jest bardzo proste i ogranicza się do połączenia trzech przewodów. Częstotliwością odbiornika też nie musisz się tak bardzo przejmować, bo pobliskie częstotliwości i tak powinno jeszcze wyłapywać. Dalej te kody w asemblerze i w C to już interpretowanie ramek. Jeśli ci się poszczęści i zidentyfikujesz kodowanie jako jakieś popularne, to może znajdziesz do niego gotową bibliotekę.
  14. Dawno temu napisałem tutaj artykuł o dekodowaniu nieznanego sygnału z pilota: https://forbot.pl/blog/jak-przystosowac-domowego-pilota-wlasnych-celow-id1223 Potrzebujesz do tego standardowego odbiornika podczerwieni i jakiegoś oscyloskopu/analizatora logicznego do badania przebiegów czasowych. Warto też przeczytać wcześniej o różnych sposobach kodowania w pilotach np. długością sygnału, manchester
  15. GAndaLF

    Logika rozmyta Matlab

    Gdzie ty widzisz zlewkę? Rozumiem, że jesteś początkujący i możesz nie wiedzieć jak się zabiera do takich projektów, ale pytania które wypisałem to nie żadna złośliwość tylko pierwszy krok, który inżynier musi wykonać. Analiza wymagań i doprecyzowanie. Bez tego ani rusz. To samo zresztą robi w prawie każdym temacie na Forbocie marek1707 wykonując tytaniczną pracę i wykazując się niesamowitą cierpliwością.
×