Bardzo sobie cenię Twoje materiały i mam cichą nadzieję, że kiedyś powstanie seria zaawansowanego programowania w języku C (oczywiście w kontekście embedded).
@@tmfmikro może w takim razie zapytam, jakimi zagadnieniami należałoby się zainteresować w kontekście zaawansowanych technik programowania w języku C, wykorzystywanych w embedded? Z góry dziękuję za odpowiedź.
Proponuję temat na odcinek - tworzenie bibliotek. Ale oczywiście chodzi mi o gotowe skompilowane biblioteki, których zawartość jest niewidoczna dla użytkownika. Takie jak libm.a na przykład.
Jak patrze na to kombinowanie, to jednak wolę PWM na stm32 i wiaderko timerów;) Ale ogólnie debugger zawsze potrzebny! Jakikolwiek by to procesor nie był.
@@tmfmikro a drugi preskalerem;) tam poprostu wpisał bym dzielnik na 1 lub 2 timery i tyle. Na rtc dał bym osobny timer tylko do użytku rtc i zostało by mi kilka timerów wolnych.
@@MarekPaszek dokładnie tak to jest zrobione. Jest dedykowany timer dla tych, po prostu przez pomyłkę wskazałem timer użyty do czegoś innego. Normalnie wszystko by załatwił preskaler timera, ale że wybrałem sobie f=1Hz to preskaler nie wystarczył. W STM byłoby tak samo
@@tmfmikro sprawdzałem, z 64mhz zejdę preskalerem do 1hz;) preskaler pomocniczy /8 później przez 65535 preskaler główny. Wiec timer wystarczy aby liczył do 120 - a może do 65535, dodatkowo jeszcze mamy preskaler na timery wszystkie razem do /16. Mowa o najtańszym stm jaki dostanę w tme za mniej jak 10zł. Dodatkowo możemy dzielić timer / timer itd jak w xmega. Ogólnie sam używam dość dużo tinny. Teraz kilka avr64 zamówiłem, zobaczymy jak sie sprawdzi "nowa" architektura.
@@MarekPaszek ja jeśli mogę to lubię używać timera jako preskaler. Jest to bardziej uniwersalne i jeśli aplikacja może pracować z różnym taktowaniem to automatyczne przeliczanie częstotliwości jest łatwiejsze.
Może nie zauważyeś, ale pokazałem taką opcję. Tu są jednak pewne problemy - pierwszy - takich fraz w kodzie może być wiele. Drugi - tak jak w moim prykładzie, podstawiłem inny symbol przez define i w efekcie nie było widać, że odwołania do RTC_TIMER, to w istocie odwołania do TCC1. No i kolejna możliwość - modyfikacja PER w kodzie mogła być np. poprzez wskaźnik, lub odwołanie do błędnego wskaźnika itd. W takiej sytuacji wyszukiwanie frazy PER zupełnie nie pomoże. Jest jeszcze podstawowy problem - skądś trzeba wiedzieć, że chodzi właśnie o modyfikację PER. Jeśli się nie ustawi breakpointa w celu podglądu IO to można długo szukać przyczyny.
@@tmfmikro > tak jak w moim prykładzie, podstawiłem inny symbol przez define i w efekcie nie było widać, że odwołania do RTC_TIMER, to w istocie odwołania do TCC1 To podstawienie łatwo było wypatrzyć, więc potem można było poszukać co się dzieje z TCC1. Czyli łatwo dało się to znaleźć analizując chwilę kod. Nie uważam, bynajmniej, że debugger to niepotrzebna zabawka, wręcz przeciwnie - bez niego nie udałoby się wyśledzić całej masy błędów w kodzie. Chciałem tylko jeszcze raz podkreślić, że akurat w prezentowanym w filmie problemie można sobie było dosyć łatwo poradzić bez debuggera i tyle.
Super filmik! Jak zwykle z resztą. Prosimy o więcej!
Bardzo sobie cenię Twoje materiały i mam cichą nadzieję, że kiedyś powstanie seria zaawansowanego programowania w języku C (oczywiście w kontekście embedded).
Byłoby fajnie, ale obawiam się że zapotrzebowanie jest małe. Niestety.
@@tmfmikro może w takim razie zapytam, jakimi zagadnieniami należałoby się zainteresować w kontekście zaawansowanych technik programowania w języku C, wykorzystywanych w embedded? Z góry dziękuję za odpowiedź.
Proponuję temat na odcinek - tworzenie bibliotek. Ale oczywiście chodzi mi o gotowe skompilowane biblioteki, których zawartość jest niewidoczna dla użytkownika. Takie jak libm.a na przykład.
Bardzo dobry odcinek i fajnie zmowntowany 😀Czy planujesz serię od zera jak to podłączyć co kupić itp czyli taka seria od zera do Master Debuggera 🙃
Pomysł na nazwę serii jest super. Więc jeśli pozwolisz to wykorzystam. Jeśli to byłoby interesujące dla słuchaczy to mnie się taka seria super podoba.
@@tmfmikro dla mnie spoko nie wiem czy code composer studio używasz z Black hawkiem to mi by się przydało 😜
Jak patrze na to kombinowanie, to jednak wolę PWM na stm32 i wiaderko timerów;) Ale ogólnie debugger zawsze potrzebny! Jakikolwiek by to procesor nie był.
Tu nie ma kombinowania. Jeden timer z ośmioma kanałami PWM.
@@tmfmikro a drugi preskalerem;) tam poprostu wpisał bym dzielnik na 1 lub 2 timery i tyle. Na rtc dał bym osobny timer tylko do użytku rtc i zostało by mi kilka timerów wolnych.
@@MarekPaszek dokładnie tak to jest zrobione. Jest dedykowany timer dla tych, po prostu przez pomyłkę wskazałem timer użyty do czegoś innego. Normalnie wszystko by załatwił preskaler timera, ale że wybrałem sobie f=1Hz to preskaler nie wystarczył. W STM byłoby tak samo
@@tmfmikro sprawdzałem, z 64mhz zejdę preskalerem do 1hz;) preskaler pomocniczy /8 później przez 65535 preskaler główny. Wiec timer wystarczy aby liczył do 120 - a może do 65535, dodatkowo jeszcze mamy preskaler na timery wszystkie razem do /16. Mowa o najtańszym stm jaki dostanę w tme za mniej jak 10zł. Dodatkowo możemy dzielić timer / timer itd jak w xmega. Ogólnie sam używam dość dużo tinny. Teraz kilka avr64 zamówiłem, zobaczymy jak sie sprawdzi "nowa" architektura.
@@MarekPaszek ja jeśli mogę to lubię używać timera jako preskaler. Jest to bardziej uniwersalne i jeśli aplikacja może pracować z różnym taktowaniem to automatyczne przeliczanie częstotliwości jest łatwiejsze.
Ja wyszukałbym w całym kodzie frazy "PER" i zmalazłbym to w ciągu sekund. Tu raczej debugger to overkill
Może nie zauważyeś, ale pokazałem taką opcję. Tu są jednak pewne problemy - pierwszy - takich fraz w kodzie może być wiele. Drugi - tak jak w moim prykładzie, podstawiłem inny symbol przez define i w efekcie nie było widać, że odwołania do RTC_TIMER, to w istocie odwołania do TCC1. No i kolejna możliwość - modyfikacja PER w kodzie mogła być np. poprzez wskaźnik, lub odwołanie do błędnego wskaźnika itd. W takiej sytuacji wyszukiwanie frazy PER zupełnie nie pomoże. Jest jeszcze podstawowy problem - skądś trzeba wiedzieć, że chodzi właśnie o modyfikację PER. Jeśli się nie ustawi breakpointa w celu podglądu IO to można długo szukać przyczyny.
@@tmfmikro
> tak jak w moim prykładzie, podstawiłem inny symbol przez define i w efekcie nie było widać, że odwołania do RTC_TIMER, to w istocie odwołania do TCC1
To podstawienie łatwo było wypatrzyć, więc potem można było poszukać co się dzieje z TCC1. Czyli łatwo dało się to znaleźć analizując chwilę kod.
Nie uważam, bynajmniej, że debugger to niepotrzebna zabawka, wręcz przeciwnie - bez niego nie udałoby się wyśledzić całej masy błędów w kodzie. Chciałem tylko jeszcze raz podkreślić, że akurat w prezentowanym w filmie problemie można sobie było dosyć łatwo poradzić bez debuggera i tyle.