Zealota

Jeśli chodzi o F0x2 to mamy taki wpis w RM: "Automatic end mode (AUTOEND = ‘1’ in the I2C_CR2 register). In this mode, the master automatically sends a STOP condition once the number of bytes programmed in the NBYTES[7:0] bit field has been transferred." Zacząłbym od sprawdzenia czy AUTOEND jest ustawiony w rejestrze, pod debuggerem, jeśli nie to oczywiście należy go zmodyfikować. W innych rodzinach należałoby sprawdzić czy odpowiednia funkcja jest dostępna.

No cóż geniuszem nie jestem, tylko ciężka prac w myśl: "dużo samozaparcia i intensywnie drążyć temat" Co do komunikatu to nie znam takiego, u mnie nie występował. Z drugiej strony aktualizacje zainstalowały Ci się w SW? Jeśli nie sprawdź: Menu->Help->Check for updates. Później sprawdź czy masz najnowszy firmware w STlink. Odpal ST link utility Menu->STLink->Firmware update

U mnie nie ma nic zielonego, jeśli pytasz o okienko debuggera. Jedynie taka limonka jest w oknie kodu źródłowego. Jeśli jest białe w oknie debuggera to od ostatniego kroku rejestr się nie zmienił, jeśli żółte to oznacza, że w ostatnim kroku nastąpiła zmiana wartości rejestru. Żółte oznacza również to, że gdzieś głębiej w drzewie uległ zmianie konkretny rejestr, zwykle należy rozwijać gałęzi. Warto już na tym etapie porównywać wartości z debuggera z RM. Próbować, kombinować, czasami coś popsuć i tak do przodu.

W żadnym z "tych sensów", jeszcze jestem na początku drogi z STM32, że bardzo dobrze pamiętam, iż miałem dokładnie takie same problemy, a mój wpis miał trochę wstrząsnąć i zmusić do intensywnej pracy. Najlepiej mieć dużo samozaparcia i intensywnie drążyć temat, oczywiście nie każdy ma tyle cierpliwości, czasu itp. ale to jedna z dróg. Druga to robić swoje, ale zarazem nie bać się pytać. Trzeba pamiętać, że programowanie to nie jest łatwy temat dla każdego, jak to przyszło się twierdzić przy okazji zjawiska zwanego "arduino". Swoje frycowe trzeba zapłacić No dość już tego mędrkowania, a Kolega do roboty

No tak mnie też się już Ich odechciewa jak to czytam @vp32, nie obraź się, ale Twój ostatni wpis to po prostu takie "błądzenie ślepego po ciemku", ale nie ma się co dziwić to normalna reakcja każdego kto chwyta się czegoś nowego, czego nie zna i nie rozumie. Następuje projekcja wyobrażeń, które nie mają logicznego uzasadnienia. Również i ja tak do tego podchodziłem - dlaczego sądzisz, że Atollic i SW4STM32 muszą mieć takie same typy debuggera? Przecież to są różne programy, o różnych założeniach. - czemu piszesz "może spróbować z Eclipse?" Przecież wszystkie te narzędzia, które wymieniłeś, oprócz MDK-ARM to właśnie Eclipse. - po co zainstalowałeś 500 programów do "jednego procesora" I tylko nie odpowiadaj na nie, bo w tej fazie to nie ma sensu - dlaczego, to napisałem w drugim akapicie A teraz już merytorycznie. SW4STM32 będzie działać od strzała na płytkach Nucleo i Discovery, bo jest przystosowany do oryginalnego ST-linka z wyprowadzonym resetem sprzętowym - z klonami ST-linka nie zadziała od razu, należy wyedytować plik .cfg, który jest konfiguratorem OpenOCD - w tym screenie co rzuciłeś w ostatnim poście - należy wybrać "User Defined" i w pliku cfg, który po pierwszym uruchomieniu debuggera, dla każdego nowego projektu, zostanie utworzony w katalogu głównym projektu, zakomentować linię, którą wytłuściłem: # STlink Debug clock frequency set CLOCK_FREQ 8000 # use hardware reset, connect under reset # connect_assert_srst needed if low power mode application running (WFI...) #reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1 W ten sposób OpenOCD nie korzysta ze sprzętowego resetu, tylko programowego. To właściwie tyle, mamy działający SWSTM32 z klonami ST-linka. To wystarczy, do pracy z STM32. Skup się na jednym środowisku, zacznij je poznawać. Z każdą chwilą będziesz lepiej to ogarniał. Nie zbaczaj do innego środowiska, jak tylko pojawią się niejasności, pytaj, na pewno na Forbocie ktoś Ci pomoże.

Na razie przycisk Run nie jest dostępny. Jest to znane ograniczenie w STMCubeIDE To "ograniczenie" dla niektórych to tylko pożądana cecha środowiska (pewnie tych "przyzwyczajonych"), bezpośrednio pochodzi już z Atollic True Studio. Osobiście ta filozofia również i mnie przeszkadzała od samego początku pracy z ATS, dlatego też wolałem pracować w System Workbench for STM32. Niemniej jednak ma swoje pozytywne cechy jeśli skorzystamy z pewnego obejścia, modyfikacji skryptu GDB. Należy skrypt tak zmodyfikować, żeby podczas debuggowania pomijać pierwszy breakpoint na funkcji main, co powoduje, że mamy efekt całkiem podobny do pracy z Run w SW, tzn. od razu mamy możliwość podglądu jak działa urządzenie - bo w końcu spojrzenie na urządzenia to najczęściej najlepsze debuggowanie Takie rozwiązanie ma jedną istotną zaletę, w każdej chwili można włączyć breakpointy (ze skrótu lub myszki) i przejść do trybu debuggowania, a potem z niego wyjść jeśli jest taka konieczność. Inna istotna zaleta, że w dowolnej chwili pracy serwera GDB można jednym skrótem klawiszowym, bez zatrzymywania serwera - po modyfikacji kodu, "zresetartować" GDB i pracować po kolejnej kompilacji właściwie "bez przerwy". Praktyczny efekt u mnie wygląda tak, że sobie właściwie tylko naciskam F12 (debug) i modyfikuję kod niejako w "czasie rzeczywistym". Bardzo wygodna praca, dużo bardziej ergonomiczna niż kombinacja Run/Debug w System Workbench. Wg mnie warto wypróbować choć też jest jedna drobna wada - modyfikację skryptu należy tworzyć dla każdego nowego projektu.

Zupełnie nie rozumiem o co tutaj chodzi. Jakie exFat, Fat ex, po co to w ogóle? Kupujesz kartę załóżmy Goodram, czy Sandisk, 8 czy 16 GB, wypalasz image za pomocą Win32DiskImager.exe i tyle. Format systemu plików karty jest ustalony przez tylko i wyłącznie image z systemem Raspbian. Tworzone są automatycznie 2 partycje, jedna DOS - fat, druga ext4. Bootujesz RPI, wcześniej podłączasz kabel ethernet do switcha i to ma działać. Robię tak od pierwszej wersji RPI, a skończyłem na RPI4 4GB. Za każdym razem powtarzalnie. Oczywiście były gorsze, lepsze image, ale wszystko działało od strzała. Oczywiście podstawą jest poprawnie działająca sieć, z poprawnie skonfigurowanym sprzętem, a zwykle każdy router "z pudełka" potrafi przydzielić adres IP. Cały wątek dla mnie to jak jakieś błądzenie "ślepego" nie wiadomo gdzie. Przepraszam, za to porównanie, ale ono oddaje pewien sens, który można skwitować powiedzeniem, że "sprzęt komputerowy działa tylko w obecności wykwalifikowanego pracownika".

Co też ci ludzie nie wymyślą

Coś czuję, że jednak niekoniecznie "musi", bo chyba problem jest większy w mojej ocenie. Tezę opieram jeszcze na innych przesłankach: https://www.elektroda.pl/rtvforum/topic3653726.html https://github.com/raspberrypi/linux/issues/3034

Taki komunikat ma niewiele wspólnego z samym AVRDUDESS, a dużo więcej z avrdude - oznacza brak komunikacji z mikrokontrolerem. Jeśli Atmega jest zupełnie nowa to pewnie pracuje z domyślną prędkością 1 MHZ, zatem należy obniżyć taktowanie programatora, jeśli masz zworkę w programatorze to należy ją przełączyć na niskie taktowania. Połączyć się z uK zmienić fuse bity na zewn. kwarc, a potem zdjąć zworkę. Chyba, że masz usbasp z poprawnym firmware to można prędkość zmniejszyć za pomocą opcji "-B 375" w avrdude.

Z dobrze wgranym obrazem powinien dostać dwie partycje na karcie uSD, jedną FAT, a drugą o nieznanym systemie plików, co nawet w Windows daje dobry podgląd na to, czy można mieć szanse na poprawnie wykonaną operację wgrania obrazu systemu. W nowszych Windowsach (8 i 10) wykrycie obu partycji powinno nastąpić niezwłocznie po wgraniu obrazu karty (dwa nowe woluminy z literami dysku). Brak obsługi partycji typu ext nie powinien być żadną przeszkodą w pierwszej fazie oceny (u mnie ta ocena jest najczęściej ostateczna - bo to żadna skomplikowana operacja). Ze swej strony mogę polecić: https://sourceforge.net/projects/win32diskimager/

Coś dla miłośników trytytek

Wg mnie rozpatrywanie kolejności "tych samych" działań jest bezcelowe. Przynajmniej dla mnie oczywistym jest, że 2*3*5 = 2*5*3 = 5*3*2, (2*3)*2 = 2*(3*5) = 3*(5*2) itd. Inaczej pisząc przy tych samych operatorach kolejność od lewej czy prawej, nie ma żadnego znaczenia. Przykład z AND'ami hmm, to co bramka 3 wejściowa AND sprawdza "gdzie jest nawias" lub "czy lewa czy prawa strona" Dywagacje na temat nawiasów i "od lewej czy prawej" poszły za daleko...

No to może jakiś odnośnik, no chyba, że to sprawa tajna

Proponuję zatem interfejs OSD do kamery RPI na podstawie źródeł raspistill i raspivid w języku C++ Z chęcią dowiedziałbym się jak jakieś proste OSD wykonać.