Zealota

Connect Under Reset, Hardware Reset, ale przed wciśnięciem connect powinieneś koniecznie wywołać reset sprzętowy. Dolutuj micro switcha i eksperymentuj. Wciskasz reset, dajesz Connect w STlink Utility, po chwili puszczasz reset i STlink powinien się połączyć, oczywiście jeśli nie ma innych problemów: zimne luty, brak połączenia itp.

Długo myślałem, ale nic sensownego nie wymyśliłem Potem przeglądając kody znalazłem taka konstrukcję: int funkcja(a,b) int a; int b; { int c; return c = a*b; } Czy to poprawne? Z którą wersją języka C "to przyszło", jeśli poprawne? Po co tak pisać??

Myślę, że powinieneś spojrzeć do RM od STM32L011, tam masz tabelkę: Te procki mają tylko 3 możliwości, a chodzi o różne możliwości startu programu. "• Boot from Flash program memory: the Flash program memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x0800 0000). In other words, the Flash memory contents can be accessed starting from address 0x0000 0000 or 0x0800 0000. • Boot from system memory: the system memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x1FF0 0000). • Boot from the embedded SRAM: the SRAM is aliased in the boot memory space (0x0000 0000), but it is still accessible from its original memory space (0x2000 0000)." Żeby skonfigurować odpowiedni dla Ciebie tryb musisz skonfigurować odpowiednio pin boot0 oraz bity nBoot1 oraz nBoot_sel. Te dwa ostatnie możesz ustawić za pomocą STlinka jak już pisałem, zaznaczając odp. "ptaszki" w programie.

Option bytes możesz zmieniać co najmniej dwojako, albo poprzez dostęp z kodu zaszytego w procesorze, pewnie jest to przydatne przy tworzeniu własnych bootloaderów, ale do tej tajemnej wiedzy jeszcze nie doszedłem, albo choćby z poziomu oprogramowania STLink. W takim F042 wygląda to tak jak na zrzucie:

Dzięki za ten przykład, bo zwykle staram się szerokim łukiem omijać tablice wielowymiarowe, zawsze jest z nimi "jakiś kłopot" Niemniej jednak zadanie wyzwoliło pokłady badawcze. Musiałem przypomnieć sobie teorię i zrobić kilka przykładów, ponieważ nie jestem zbyt biegły w C oczywiście skorzystałem z debuggera, ale nie było mowy o tym, że nie można skorzystać W odpowiedzi na pytanie wartość będzie równa 0. Dlaczego? Najciekawszy jest sposób inicjalizacji, zapis w nawiasami kwadratowymi pierwszy raz widzę (brak doświadczenia), ale z tego co zdążyłem ustalić, to podmienia wartości w konkretnych polach pamięci (wiersza), zgodnie względnym wskaźnikiem w wierszu. Zatem po inicjalizacji zmienna tab będzie miała takie wartości w pamięci: tab[][4] = { { 23, 2, 7, 1 }, { 4, 1, 0, 0 }, { 0, 0, 2, 11 }, { 0, 27, 0, 7 }, { 9, 2, 1, 0 } }; Wartości 2 oraz 27 z wiersza 2 i 3 zajmą miejsca zgodnie z podanym wskaźnikami odpowiednio 2 oraz 1, "rozpychając" na inne pozycje resztę wartości w wierszach. Zatem patrząc na wyrażenie *(*(tab+2)+1) mamy wskazanie na wartość 2 wiersza i pierwszej kolumny (licząc od zera). Nie bez powodu "mówi" się, że tablica 2 wymiarowa to "wskaźnik na wskaźnik", a trójwymiarowa to "wskaźnik na wskaźnik na wskaźnik" itd. z innymi wymiarami.

Chyba pominąłeś jedną zasadnicza różnice między boot0 a boot1. Pierwszy to pin kontrolera a drugi to bit, który znajdziesz pod hasłem "Option byte register", oczywiście w Reference Manual

W takim razie jaki to ma być typ zmiennej? char odpada, tak wnioskuję, po innych wpisach w wątku, bo jest typem archaicznym. Osobiście nie korzystam z char, właśnie z tego powodu. Trochę szukałem informacji na ten temat, ale zdania są zwykle podzielone. Natomiast wniosek wyciągnąłem taki, że należy wybierać typy zmiennych zgodnie z ich przeznaczenie, zatem znak ascii nie ma "znaku" to trzeba zapomnieć o char. Z chęcią dowiem się coś więcej na ten temat, choć czuję podskórnie, że po to wymyślono inne języki, żeby nie doktoryzować się przy tych już wiekowych

http://ww1.microchip.com/downloads/en/AppNotes/AN2551-Noise-Countermeasures-for-ADC-Applications-00002551B.pdf Mamy zarówno ADC, mamy DAC'a, a najistotniejsze jest zdanie: "To generate a true random noise signal, sufficiently high DAC conversion rate is needed." Czy zatem da się wykorzystać szum i DAC do generacji "danych losowych" czy nie? Czy to wymaga nie wiadomo czego? Czy pomysły (oczywiście niekoniecznie moje) to jest aż tak "skończona głupota" "rodem z przedszkola" jak to próbujesz przedstawiać? Oczywiście to tylko dokument, a posługiwanie się "jakimś autorytetem" to może nie do końca dobry sposób na argumentację, zatem pozostawiam czytelnikom dalszą ocenę.

Zasadne może być użycie dodatkowego klucza np CMOS, żeby wyłączać całkowicie kartę poprzez odłączenie zasilania. Takie rozwiązanie pozwoli też zwiększyć niezawodność odczytu karty, jeśli dobrze się to oprogramuje.

Dobre pytanie. Aczkolwiek należy zacząć od wejścia z dołączoną "antenką", tak by zbierała śmieci. Potem można pójść w tym kierunku: http://mikrokontrolery.blogspot.com/2011/04/generator-liczb-losowych.html Osobiście nie sprawdzałem, ale zaprezentowane techniki wydają się obiecujące. Dobierając inny procesor np. z serii STM32F3 można użyć DAC'a , które potrafią generować szum biały, dodatkowo wbudowane są w mikrokontroler wzmacniacze operacyjnego z wejściem różnicowym, a to już powinno pozwolić na odpowiednie wzmocnienie sygnału, np z jakiegoś złącza p-n.

Może zamiast pseudolosowości użyj przetwornika ADC. "Badaj szum" a dostaniesz dobry poziom losowości. Można też dorzucić pseudolosowość - losowanie najpierw wejścia przetwornika, a dopiero potem pomiar napięcia.

Musisz zarazem pamiętać, że to USB3.0 musi obsłużyć kilka interfejsów, a to oznacza że nie dla każdego będzie 5 GBit/s. Już dysk oraz ethernet mocno obciąży USB. Dodatkowo nic nie wiadomo o przepustowości rdzenia - mostek USB - czy aby na pewno jest tak wydajny w komunikacji jak kontroler USB 3.0? Tego nie wiemy, brakuje testów. Żeby nie było, osobiście jestem zadowolony ze specyfikacji nowej malinki. W połączeniu z bardzo dobrym wsparciem uważam, że nie będzie miał konkurencji na rynku. Zresztą już RPI3 nie miało a nawet wcześniejsze wersje. Stawiam orzechy przeciwko kokosom, że teoretycznie dużo lepiej wyposażony RockPi 4 będzie tylko cieniem nowej Malinki. Co do problemów z SD to obecnie to już jest mit, skądinąd zapracowany, z pierwszych wersji malinki. Wiadomo SD nie są mocno odporne na ciężką pracę. Karty SD są jednak coraz lepsze i można kupić dedykowane o lepszej trwałości. Dodatkowo RPI4 ma bootloader w wewnętrznej pamięci SPI flash, w przygotowaniu jest bootloader współpracujący z siecią oraz z pamięcią USB. Niepokoją mnie za to zastrzeżenia Kolegi @deshipu - bo część z nich jest t zupełnie niepoważna. Choćby te o zasilaniu. Jakie drogie zasilanie? Wystarczy przejściówka USBmicro + USB-C za parę złotych i zasilacz 2A. Wg testów RPI4 w szczycie pobiera 1.5 A, nie wiele więcej niż RPI3, zatem markowy zasilacz 2-2,5 A powinien wystarczyć, a takie przecież nie są drogie. Gdzie są te drogie ficzery? Chyba w RockPi4 , który "będzie kwiczał" jak wsparcie się skończy za pół roku. Takie są niestety doświadczenia z Rockchipami, jak choćby niesławny RK3368 Octa Core. Osiem rdzeni - śmiech na sali Gdzie jest to super wsparcie dla tego chipu? RK3399 podzieli jego los, tak stawiam, ale obym się mylił. Dodatkowo w RPI4 już jest wbudowane POE, gdzie próżno go szukać w konkurencji. Zakładam oczywiście, że nie ma błędu z tym związanego jak w HATach do RPI3 Jak dla mnie RPI4 to interesujący upgrade Malinki - jak tylko Botland przyśle to będę testował.

Korzystałem kilkukrotnie z Elecrow. Koszt przesyłki to ok 8 dolarów najmniej. Co ciekawe zawsze szło DHL'em do granicy, od granicy pocztą. PCB dostawałem po ok 2 tygodniac, łącznie z produkcją, żaden podatek vat nie był doliczany. Obecna promocja to niestety tylko 1 zakup do koszyka za .99 centów. Można dorzucić kolejne zamówienia, ale już w wyższych cenach. Zatem za ok 14 dolarów z przesyłką można zamówić 20 płytek PCB - uważam, że warto.

Twoje problemy wynikają prawdopodobnie z tego, że nie korzystasz z pinu reset do programowania. Taki pin ma każdy programator ST-link, niestety te tanie nie korzystają z niego. Należy zatem przy programowaniu i debugowaniu korzystać z programowego resetu. Żeby wymusić takie działanie w System Workbench należy zmodyfikować skrypt debuggera. Gdy skompilujesz źródła i uruchomisz Run lub Debug automatycznie tworzony jest plik konfiguracyjny "xxxxx.cfg". Znajdziesz go w głównym katalogu projektu. Musisz go wyedytować i zakomentować linię: "reset_config srst_only srst_nogate connect_assert_srst" wpisując # na początku linii. Uwaga!. Wcześniej należy wejść do: Menu->Run->Run Configurations, w zakładce Debugger opcja Configuration Script i zmienić na User Defined w przeciwnym razie zmiany w pliku zawsze będą nadpisywane. Co do samego ST-link Utlity i konieczności "długiego trzymania resetu" to prawdopodobnie masz stary firmware w ST-link, warto go zaktualizować. Dla zasady czysty Blue Pill powinien dać się zaprogramować przez ST-Link bez żadnych dodatkowych działań. Warto posprawdzać kabelki, sterowniki i firmware. Dla pewności należy sprawdzić, czy zworki bootloadera są dobrze ustawione. Generalnie pisząc korzystanie z BluePill bywa upierdliwe. Żeby pozbyć się "upierdliwości" warto zainwestować w jakieś Nucleo albo Discovery, gdzie na pokładzie już jest wbudowany ST-link i to bez ułomności, co zwykle ułatwia pracę.

Warto doczytać o tym problemie tutaj: http://cpp0x.pl/kursy/Kurs-C++/Poziom-1/Warunek-wielokrotnego-wyboru-switch-case/17 W akapicie: "Tworzenie zmiennych wewnątrz switch'a" jest dokładnie opisane jak korzystać w takim wypadku z case. Ten problem powinien wyłapać kompilator, ale być może masz "zbyt luźno" skonfigurowany.