Zealota

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.

U mnie adapter (podejrzewam, że taki sam lub podobny) wygląda jak na zdjęciu. Musiałem dolutować zworkę, która założona pozwala programować ESP, zdjęta umożliwia pracę z komendami AT. W takiej konfiguracji działa wszystko poprawnie. Ciekawostka jest tak, że do programowania można używać dowolnej prędkości - moduł w trybie wgrywania sam sobie dobiera baudrate. Natomiast w trybie komend AT prędkość jest na sztywno. Wszystkie moje moduły, a jest ich kilka, działają z prędkością 115200. Druga ciekawostka to taka, że przy wgrywaniu nowego softu trzeba dobrać właściwy, taki który pozwala pracować z komendami AT - a nie jest to takie oczywiste.

Nic dodać nic ująć. Trafny komentarz, od razu sobie o tym pomyślałem

Zastanawiam się skąd bierzesz plik hex i po co go używasz. W domyślnych ustawieniach System Workbench nie ma możliwości generowania pliku w tym formacie. Używasz jakiegoś dodatkowego pluginu, czy jeszcze jakoś inaczej go generujesz? W SW jest przecież przycisk "Run", który z poziomu Eclipse wgrywa plik elf do procesora, nie ma potrzeby używania ST link utility. Na początku jest trudność z takim sposobem, ale w projekcie należy zmodyfikować opcje debuggera i bez problemu z każdego projektu można wgrywać wsady do mikrokontrolera. Wszystko wskazuje, że używamy tej samej wersji SW.

Niezależnie od tego czy producent ma podgląd gerberów czy nie, to i tak warto korzystać z zewnętrznej przeglądarki, np. prosto z KiCada albo tej: https://pl.zofzpcb.com

Warto zaznaczyć, że konkurencja ma takie narzędzia już od dawna, nie mniej jednak całość ułatwia proces zamówienia.

Jak właśnie widzę te rockchipy to od razu czerwona lampka się zapala. Pisałem wcześniej o mediateku, ale pomyliłem się chodziło mi o rockchipa. Mam takiego 8 rdzeniowego z RK3368 - GeekBox i to nawet nie jest dobry przycisk do papieru, bo lekki. Wsparcia obecnie żadnego, to co się pojawiło to zwykła ściema. Radzę się trzymać z daleka. Oczywiście tego 3399 nie próbowałem, domyślam się tylko, że to będzie dokładnie takie same "badziewie". Silne rdzenie, ale poprzez brak sensownego wsparcia, braku aktualizacji a co najważniejsze stabilnych sterowników czy też nowoczesnego kernela skończy jak każde tego typu urządzenie? Czy ktoś na temat rockchipa to w ogóle słyszał dobre opinie?

To bardzo ciekawe co Kolega wypisuje, ale co to ma wspólnego z tematem artykułu. Tu chodzi o tanie płytki w budżecie do ok 200 zł, a mamy wypis możliwości telefonu za 3 do 5 tys zł. Mam u siebie całą szufladę płytek od 50 do 500 zł i one wszystkie właściwie to do niczego się nie nadają. Są intele jak LattePanda czy ośmiordzeniowe mediateki. Cała ta szuflada nie ma takiego wsparcia jak RPI i pewnie OrangePi 3 tak samo skończy . Można zwykle zrobić sobie jakiś serwerek, ale znowu kłopot z szybkością ETH, które to zwykle jest na USB, jak chcemy zrobić media center to znowu trzeba rzeźbić sterowniki z akceleracją itd. itd. Powstaje coraz więcej kickstarterów, ale tylko chyba po to żeby wyciągnąć kasę, a potem pościemniać z supportem. Pewnie było kilka lepszych urządzeń, zachwalają niektóre Odroidy, ale jakby przeglądnąć fora to i tak więcej jest narzekania niż zadowolenia. Najsensowniejsze wydają się płytki na Intelach jak ta LattePanda, ale ta pierwsza, którą mam w szufladzie nadal się nie doczekała obsługi dźwięku passthrough po HDM w linuksie. Można oczywiście odpalić Windows 10, ale przy 2GB ramu to mordęga. Są oczywiście nowe LattePAnda, ale ceny to tam chyba zaczynają się dopiero od 600 zł lub więcej. W mojej ocenie nadal są najlepsze płyty mini ITX choćby z procesorami J1900 lub j4200. Od dłuższego czasu już się wyleczyłem z tych wynalazków, choć mała nadzieja, że powstania atrakcyjna alternatywa do RPI jeszcze się tli