Elvis

@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

Napisałeś że niezależnie od mikrokontrolera - i tylko dlatego napisałem że to nieprawda. Są takie i to dość popularne, sam na takie piszesz programy

W każdym razie: to nieprawda. Są takie architektury gdzie oba kody mogą być tak samo wydajne.

Przy okazji warto jeszcze wyjaśnić jak ten pin jest skonfigurowany i jak niby miało działać - bo najpierw używany jest rejestr PORTB, czyli wygląda jakby to miał być pin w trybie wyjścia, ale chwilę później następuje odczyt z rejestru PINB, więc jednak wejście. Jestem bardzo ciekaw jak autor rozumie działanie takiego programu. @ethanak zostawmy te optymalizacje w spokoju, może warto zacząć od poprawności programu. Może nie być różnicy, czy przesunięcie jest wykonywane podczas kompilacji, czy wykonywania.

Niestety nie znam metody na użycie GPS w małym robocie, dlatego zapytałem. Dokładność 2m to bardzo optymistyczne założenie. Filtr Kalmana to dobry pomysł, sprawdza się w nawigacji samochodowej - ale znowu, przy rozmiarze i szybkości reakcji robota raczej nie zadziała poprawnie. Można uzyskać wysoką dokładność w przypadku GPS, taki sprzęt używany jest np. w geodezji - ale ceny są zupełnie inne niż w przypadku opisywanych modułów, czas pomiaru jest dość długi no i konieczny jest abonament na dane dla DGPS.

Robiłeś może jakąś analizę dokładności danych z GPS? Pytam bo to dość mały robot i kilka metrów to dla niego spory dystans, a z moich doświadczeń z odbiornikami GPS otrzymywanie "szumu", który wygląda jak skoki po kilka metrów to normalne działanie. I bardzo mnie ciekawi jak sobie poradziłeś z tym problemem.

I2S to nie format przesyłania dźwięku tylko interfejs. W każdym razie poczytaj to sam zobaczysz, że w przypadku esp32 jednak coś ma i to więcej niż samo DMA.

Nie musisz zaczynać od DMA, możesz wykorzystać sam I2S na początek.

Dobra, z tymi timerami to był zły pomysł - jednak na esp32 jest zupełnie inaczej niż na stm32, a mi się wszystko pomieszało W każdym razie jak chodzi o gotowca to proponuję popatrzeć na kod biblioteki FabGL: https://github.com/fdivitto/FabGL Jest tam kod sterownika VGA, który wykorzystuje DMA, ale zamiast jak myślałem GPIO używane jest I2S - pozostaje przeanalizować kod, a może i przetestować. Tak jako ciekawostka, że ESP32 może faktycznie generować obraz VGA: