Elvis

Nie wiem ile czasu startuje bootloader arduino i nie wiem jak dokładnie działa - ale nie jest dużym wyzwaniem napisać program, przetestować, a na koniec wywalić bootloader. To można zrobić nawet nie mając programatora ISP. W każdym razie da się tak uruchamiać program w czasie rzędu setek milisekund (program wcale nie uruchamia się od razu), jeśli to jest za mało, budzenie procesora może działać szybciej. Zaproponowałem takie rozwiązanie, bo znam je z modułu działającego z czujnikiem PIR i pracującego latami na baterii cr2032. Więc na pewno się da i na pewno będzie działać - a jak to zrobić to już szczegół

Skoro ktoś przechodzi przez korytarz w czasie rzędu milisekund to ok. W każdym razie rozwiązanie z odcinaniem zasilania mikrokontrolera jest całkiem ciekawe i potrafi ograniczyć pobór pradu do mikroamper. Ale są też inne rozwiązania, każde ma swoje plusy i minusy.

Jest jeszcze jedno proste rozwiązanie. Można dać jeden tranzystor, który będzie odcinał zasilanie od wszystkiego poza PIRem. Jak pojawi się ruch to zasilanie mikrokontrolera zostanie załączone i może sobie nawet 50mA brać. Jak już program zrobi co ma zrobić, wyłączy zasilanie i po sprawie. Wtedy można użyć zwykłego Arduino, bez kombinowania usypiania itd.

Google podpowiada coś takiego https://stackoverflow.com/questions/5459868/concatenate-int-to-string-using-c-preprocessor/5459929 Chwilowo nie mam jak przetestować, ale wygląda sensownie Edit: w sumie to dokładnie to samo, na telefonie kiepsko się czyta, a jeszcze gorzej pisze

Ja tylko podpowiem, że nawet jeśli sam kurs jest dla początkujących to micro:bit jako platforma może być używana przez o wiele bardziej zaawansowanych użytkowników. Na micro:bit można uruchomić pythona, pisać programy za pomocą bibliotek Arduino, albo wyrzucić to wszystko i pisać programy w samym C/C++ (a nawet asemblerze) odwołując się bezpośrednio do rejestrów. Mamy wtedy całkiem ciekawy mikrokontroler nRF51822 z obsługą BT w wersji low-energy, akcelerometr LSM303, matrycę 5x5 led, drugi mikrokontroler do obsługi USB oraz możliwość podłączania modułów tak samo jak opisano w kursie.

Podobno jeden obraz jest wart tysiąca słów: A jak chodzi o to widzenie w ciemności, to NOIR cudów nie robi, oświetlenie nadal jest potrzebne, ale może być w podczerwieni.

Wyniki są jak najbardziej poprawne. W tym zadaniu chodziło o pokazanie jak dużo czasu może zajmować obsługa przerwań jeśli nie zadbamy o optymalizację.

Moim zdaniem wysyłanie niewielkiej liczby zapytań, czy to będzie co minutę, czy co 30s nie podpada nawet w najmniejszym stopniu w "użycie systemu teleinformatycznego w sposób niezgodny z przeznaczeniem" - w końcu serwer www jest właśnie po to, żeby takie zapytania realizować. A że nie są wykonywane przez przeglądarkę, tylko przez skrypt to już szczegół techniczny. Oczywiście administrator może w takiej sytuacji zablokować IP, może nawet dodać regułę, która będzie takie zapytania odrzucała z automatu.

@ethanak możesz podać o jakie nadużycie ostarżyć można kogoś kto co np. 1 minutę wysyła zwykłe zapytanie do ogólnodostępnego serwera? Pytam ze zwykłej ciekawości, bo to nie atak, nawet próba DoS, po prostu zwykłe zapytania, w dodatku niezbyt częste. Więc ciekaw jestem jaka ustawa coś takiego reguluje.

@jackg Rozwiązanie, które podałeś wygląda poprawnie, chociaż zawsze warto byłoby sprawdzić na prawdziwej płytce (to praca domowa 6.1B). Jedyne co można się przyczepić to zaokrąglenia: Dla pierwszej wersji kursu mamy jak napisałeś Fcpu = 64MHz, dzielnik 6 i poprawnie policzone Tconv = 84. Obliczając fconv mamy więc: fconv = Fcpu / div / Tconv = 64MHz / 6 / 84 = 126.98 kHz Różnica nie jest duża, ale warto zwrócić uwagę, że wynik to nie "okrągłe" 128kHz, ale trochę poniżej 127 kHz. Czasem potrzebujemy faktycznie okrągłych wartości i wtedy trzeba dopasować Fcpu do możliwości przetwornika. W przykładach z kursu ta wartość akurat nie miała znaczenia. W nowej wersji mamy Fcpu = 8MHz, dzielnik 2 i Tconv = 26, czyli: fconv = Fcpu / div / Tconv = 153.85 kHz

@LN7 Nic nie powinieneś, ani nie musisz robić Chciałem tylko podpowiedzieć, że nawet jeśli zapiszesz na tej karcie cokolwiek innego (np. raspbiana, albo zdjęcia z imprezy) - to zawsze możesz wgrać ponownie Noobs-a i mieć to samo co teraz, albo nawet lepiej bo w najnowszej wersji. Więc nie musisz się obawiać kasowania domyślnej zawartości karty.

@LN7 Noobs-a możesz w każdej chwili ponownie wgrać na kartę - wystarczy pobrać plik ze strony https://www.raspberrypi.org/downloads/noobs/ nagrać i gotowe. Będzie działał nawet lepiej niż ten oryginalny, bo możesz pobrać najnowszą wersję, a na karcie prawdopodobnie jest coś starszego.

Mając switcha też można, nie potrzeba wymieniać sprzętu.

@malkos chyba najprościej będzie zainstalować wireshark na raspberry i sprawdzić jak wygląda komunikacja. Możesz oczywiście "podsłuchać" co jest przesyłane między stm32, a rpi używając PC, ale to już jest nieco trudniejsze. Switch "uczy się" adresów MAC podłączonych urządzeń i wysyła pakiety tylko do odpowiednich kart - dlatego na PC nie widzisz komunikacji między pozostałymi.

@Emerid możesz do typu zmiennej będącej licznikiem pętli dodać volatile, wtedy optymalizator nie będzie mógł całkiem wyrzucić tej pętli. Natomiast co do drugiego pytania, to chyba chodzi Ci po prostu o zmienną globalną, wtedy zarówno callback, jak i funkcja main będą miały do niej dostęp. Tutaj podobnie jak w przypadku pętli użycie volatile może być potrzebne.

Takie są plusy i minusy szybko rozwijanych narzędzi - jak zaczynałem pisać ten artykuł to najnowsza wersja była 1.3.x, a teraz już jest dostępna 1.4.x. Ciężko nadążyć

Masz już dość irytujących buzzerów? Pora pójść krok dalej! Mikrokontrolery, takie jak STM32, bez problemu mogą odtwarzać muzykę. W tym celu konieczne jest jednak opanowanie podstaw I2S. Oto praktyczny poradnik, który omawia krok po kroku, jak generować pojedyncze tony, a nawet odtwarzać gotowe melodie pobrane z Internetu. [blog]https://forbot.pl/blog/co-warto-wiedziec-o-odtwarzaniu-dzwiekow-na-stm32-id43313[/blog]

Proponuję jednak trochę poczytać o wpływie częstotliwości PWM na moment, przykładowy link: https://www.precisionmicrodrives.com/content/ab-022-pwm-frequency-for-linear-motion-control/

@Nikto0 spróbuj może wykonać następujący eksperyment myślowy: weź baterię, np. 9V i zmierz napięcie gdy nic nie jest do niej podłączone (to możesz zrobić nawet nie tylko myślowo). Otrzymasz jakiś wynik, pewnie nie 9V, ale pewną konkretną wartość. Masz więc napięcie U = <wartość zmierzona>, a prąd w obwodzie nie płynie, więc I = 0 A. Teraz druga część, już raczej tylko teoretyczna. Wyobraź sobie, że robisz zwarcie idealnym przewodnikiem, czyli takim, który ma rezystancję zerową. I teraz pytanie - jaki popłynie prąd? Gdyby R=0 podstawić do wzoru na rezystancję, czyli R = U/I to po przekształceniu mielibyśmy I = U/R, ale R=0, czyli I = 9 / 0 - a tego nie lubią matematycy. Nawet jeśli R nie będzie idealnie zerem, ale wartością bliską zeru, to i tak teoretycznie prąd będzie prawie nieskończony... Jak pewnie się domyślasz w takim eksperymencie nie uzyskasz nieskończonego prądu, tylko znowu jakąś konkretną wartość. W przypadku baterii 9V będzie to w dodatku zaskakująco mała wartość. Tym co ogranicza płynący prąd i sprawia że nie następuje koniec świata jest właśnie opór wewnętrzny - możesz go nawet zmierzyć, ale robienie zwarcia raczej nie jest dobrym pomysłem, więc można zrobić takie "prawie" zwarcie i zamiast R=0 użyć rezystora o większej wartości. I wtedy dostaniesz układ o którym pisał kolega @Gieneq Ale najprościej wyobrazić sobie opór wewnętrzny jako taki niechciany rezystor, który mieszka w każdej baterii. Z drugiej strony to dzięki niemu nie uzyskamy nieskończonych prądów gdy niechcący zrobimy zwarcie.

To jakiś konkurs na największą ilość kodu która nic nie robi? Może chociaż spróbuj wyjaśnić co starasz się osiągnąć - bo jeszcze niechcący ktoś początkujący kiedyś znajdzie ten wątek i zacznie się z tego uczyć...

Chyba najłatwiej odpowiedzieć na ostatnie pytanie - niestety to zupełnie nierealne.

W tym co napisałem nie ma nic sprzecznego z notą katalogową. PINx zwaca faktyczny stan pinów wybranego portu - zapis od PORTx jedynie próbuje zapisać określoną wartość. Jeśli zapis się uda, to po pewnym czasie np. 0.5-1.5 cyklu masz taki wynik jak chciałeś. Więc szybciej (optymalniej) będzie działało użycie zmiennej - a inna sprawa, że w zależności od konfiguracji pinu i tego co do niego jest podłączone ten kod może po prostu nie działać tak jak oczekujesz.

Zacznijmy od nieporozumienia - PORTB i PINB to nie są zmienne. To rejestry i chociaż czasem zachowują się podobnie do zmiennych to zupełnie co innego. Z rejestru PORTB możesz odczytać to co niego zapisałeś - więc zamiast sprawdzać PINB lepiej sprawdzać bit PORTB. Ale w niektórych mikrokontrolerach, np. stm32 jest tak, że dostęp do rejestru zajmuje o wiele więcej czasu niż odczyt ze zmiennej, czy rejestru procesora. Natomiast to co odczytujesz z PINB to faktyczny stan piny PB5. Okazuje się, że może być on inny niż wynikałoby z zapisu do PORTB - dlatego to może zupełnie nie działać. Jeśli wyjście jest typu push-pull to na 99% będzie działało, ale już mając wyjście open-drain, zapis do PORTB może nie mieć wpływu na wartość w PINB. Wystarczy, że zewnętrzny układ zewrze do masy i PINB zwróci 0 nawet jeśli PORTB zapisywał 1. Czegoś takiego mniej więcej się spodziewałem, stąd było moje pytanie.

Ok, teraz rozumiem o co chodziło W każdym razie używanie PINB jako zmiennej jest mocno mylące, może być mało wydajne, albo i zupełnie nie działać. Nie wiem jak jest na AVR, ale na ARM dostęp do rejestrów może być o wiele wolniejszy niż do pamięci. Poza tym PINB może zwrócić inną wartość niż wpisałeś do PORTB... Proponuję po prostu dodać zmienną, która będzie przechowywała stan diody i odpowiednio do jej stanu sterować programem. Będzie prościej, szybciej i czytelniej.

Tak dla wyjaśnienia i zamknięcia offtopu - w przypadku większości mikrokontrolerów i mikroprocesorów z rdzeniem ARM, dostępny jest tzn. barrel-shifter. Dzięki niemu wczytując wartość instrukcją LDR można jednocześnie i niejako "za darmo" wykonać przesunięcie bitowe. Oczywiście nie mamy gwarancji że kompilator wygeneruje akurat taki kod i nie powinno się takich optymalizacji wprowadzać bez potrzeby. Ale tak jako ciekawostkę warto wiedzieć, że ARM to niby RISC, a potrafi mieć zaskakująco skomplikowane instrukcje asemblera