Skocz do zawartości

Zealota

Użytkownicy
  • Zawartość

    108
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    2

Wszystko napisane przez Zealota

  1. Krytyki nie będzie bo te stmy, hidy i klawisze to moje klimaty z chęcią obejrzę każdy materiał, a Twój jest nawet kompletny, jest projekt, wykonanie, brakuje glutów jak w większości projektów arduino, a na końcu jeszcze obudowa w 3D. Mam za to sugestie: 1. Skoro zapoznałeś się już USB w STM32 to zobacz sobie ciekawą alternatywę dla kodu od ST: https://github.com/dmitrystu/libusb_stm32 Oprócz tego zapoznaj się z poradnikiem, który przygotował Kolega @Elvis https://forum.sunduino.pl/viewtopic.php?f=9&t=520 Mnie się udało z większym czy tez mniejszym zrozumieniem zrobić urządzenie HID na podstawie tego poradnika. 2. Co do wydruku 3d to warto przy precyzyjnych wydrukach używać PETG, który ma małą kurczliwość pod wpływem temperatury. Mnie się udało wykonać kilka nawet dość precyzyjnych modeli. https://prusament.com/pl/materials/prusament-petg/ Zresztą na stronie Prusa są charakterystyki dla większości materiałów i warto się z nimi zapoznać przy wyborze filamentu.
  2. Nie zapomnij o Update, bo domyślna wersja jest całkiem stara i mogą być problemu z odpowiednimi nagłówkami do uK.
  3. Najnowsza wersja CebeIDE (1.3.0) jest pod tym względem całkiem udana. Kilka klików i jest projekt "na rejestry". Dodatkowo dodali przycisk do bezpośredniego wgrania wsadu do uK, więc pod tym względem bardzo się zbliżyli do SW, niestety pozostały gorsze właściwości pod względem podpowiadania składni, ale to już pewnie zależy od konkretnych wtyczek do Eclipse.
  4. Zastanawia mnie jedno: "przygotować własną sieć neuronową" Gdzie niby jest ta sieć neuronowa, gdzie są te ""neurony". Pewnie to zwykły brak wiedzy u mnie lub pomieszanie pojęć. Zaglądając do wiki można wyczytać, że właściwie chodzi o "sztuczną sieć neuronową" - czemu pomijany jest przedrostek "sztuczną"? Takim tokiem to za parę lat te "kilka bramek" będzie się nazywało neuronami Poza tym ciekawie poczytać o takich nowoczesnych zagadnieniach.
  5. Bezpośrednio raczej nie pomogę, ale zaglądnij tutaj: https://msalamon.pl/ Masz tam kilka poradników tyczących się F101 i właśnie RTC. Jest tam kilka istotnych porad tyczących tego zagadnienia. Ogólnie bardzo interesująca strona, która dotyczy STM32, polecam.
  6. Właściwie wszystko się zgadza. 13 to kod ASCII w DEC (Return), a 28 to kod HID w HEX (Enter) zgodny ze specyfikacją USB: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf Strona 54. Generalnie z kodami należy uważać na to czy zapis decymalny czy heksadecymalny bo często jest z tego powodu bałagan.
  7. Wg mnie masz źle ustawione zworki boot na uruchamianie z bootloadera, a nie z kodu z pamięci Flash, bo to są podobne objawy.
  8. Prawdopodobnie masz zimny lut na masie, po dociskaniu masa zaczyna łączyć i brum cichnie. Zacząłbym od przelutowania gniazda.
  9. Po prostu starą wersję płytki musisz zapisać z nową nazwą i tyle. Nie ma znaczenia czy schemat czy PCB - Eagle sam sobie skopiuje drugą część projektu. Można też zrobić to ręcznie, w katalogu projektu - skopiować oba pliki z nową nazwą. Schemat i pcb muszą mieć taką samą nazwę, oczywiście poza rozszerzeniem . Gdy będziesz miała taką nową parę plików, to wystarczy, że usuniesz wszystkie połączenia, ścieżki z PCB, można też oczywiście modyfikować po trochu.
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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.
  15. 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.
  16. 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".
  17. 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
  18. 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.
  19. 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/
  20. 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...
  21. 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ć.
  22. Pozwolę się wtrącić bo odniosłem wrażenie, że spór idzie na różnych płaszczyznach, jakby jeden mówił o jabłkach a drugi o gruszkach, a Kolega Elvis to jakby zupełnie na innym "poziomie abstrakcji". - RTC się nie nadaje, bo zmiany czasu itp. przeszkadzają, bo wprowadzają "błędy"? Wszystkie z tych zaburzeń jest przewidywalne i korygowalne, na potrzeby zadania zliczania czasu - RTC można go zrobić na milis, kwarcu zegarkowym, DS3231, stabilizowanym temperaturowo generatorze i pewnie jeszcze innym. - rozmawiacie o projekcie zliczania czasu pracownika. Dokładność do minuty na dobę może nie jest wystarczająca? No to może do 10 s. Po co wprowadzać "aptekarstwo" w tej dziedzinie na poziomie s lub co gorsza milisekund. Może moje wyobrażenie co do zatrudnienia jest niedostateczne, ale stawiałbym, że wystarczy "co do minuty". Jeśli damy takie założenie to każdy z wybranych RTC się nada. Co do linuksa? Hmm można to rozwinąć? Tam jest jeden zegar RTC, taki z bateryjką na płycie głównej. Reszta "zegarów" "programowych" to chyba wynika tylko z przeliczania danych. Jeśli linuks nie ma dostępu do ntpdate to korzysta tylko z tego "co zapisane w bios" - tak przewrotnie pisząc, a mam na myśli to co podtrzymuje bateryjka. Jeśli weźmiemy arduino czy jakąś bibliotekę time.h z STM, to w każdej chwili mogę przeliczyć na czas (a właściwie stan licznika) względem 1 stycznia 1970, sam z tego korzystam używając np RTC w STM32F103, gdzie jest najprostszy z RTC w STM, właśnie taki monotoniczny, który tylko tyka, a resztę, łącznie z cofaniem czasu należy zrobić ręcznie, a zatem można go rozmyślnie kontrolować. Jak działa taki DS3231? Wg mnie tam w środku jest "monotoniczny zegar" zwany licznikiem, który ze sprawną bateryjką i bez ingerencji użytkownika tylko sobie "tyka" i pomyli się o jakie "sekundy" na rok. Jaki to może mieć wpływ na wyliczenia czasu roboczogodzin? Zatem wracając do początku "spór należy" rozstrzygnąć, bo jest INTRYGUJĄCY, dla takiego czytelnika Forbota jak ja
×
×
  • Utwórz nowe...