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:

Ja bym proponował zostawić DMA na moment i zacząć od czegoś prostszego, czyli timera. Niezależnie, czy używając DMA, czy CPU i tak konieczne jest ustalenie prędkości transmisji do wyświetlacza - podejście z liczeniem cykli maszynowych się nie sprawdzi, więc proponuję uruchomić timer i na początek programowo go używać. Czyli to co może zrobić DMA najpierw niech robi drugi rdzeń - jest nawet szansa, że to zadziała i DMA nie będzie niezbędne (chociaż zawsze warto czegoś nowego się nauczyć).

Oczywiście, że taki sposób istnieje. Możesz po prostu wyrzucić FreeRTOS, przejąć pełną kontrolę i wszystko sam zrobić. Będzie to dość trudne, ale jak najbardziej możliwe. Wydaje mi się jednak, że po prostu źle do tego podchodzisz. W przypadku AVR takie sterowanie pinami mając policzone takty zegara działało - w nowszych układach będzie bardzo skomplikowane. O wiele łatwiej i dokładniej byłoby użyć do tego odpowiednich modułów peryferyjnych. Do odmierzania czasu - timer, a do transmisji DMA.

Też mnie to zainteresowało, ale chwilowo trochę brak czasu Jeśli coś przetestujesz to chętnie się dowiem jak to z tym FreeRTOS-em na esp32 jest

Zakładałem że scheduler na ESP32 używa dwóch rdzeni i sam uruchomi zadanie na drugim. Ale możliwe, że to było zbyt optymistyczne założenie. Wydawało mi się, że użycie priorytetów jest mniej "inwazyjne" niż wskazywanie rdzenia, ale oczywiście użycie xTaskCreatePinnedToCore zadziała na pewno, a z priorytetami trzeba byłoby przetestować.

Nie testowałem implementacji FreeRTOS-a na ESP32, ale ogólnie jeśli jest zadanie o wyższym priorytecie to powinno być zawsze wykonywane jako pierwsze. Więc na jednym rdzeniu nic poza nim nie powinno działać. Ale muszę to sprawdzić, bo w sumie ciekawe jak to faktycznie działa na esp.

Moim zdaniem przypisywanie zadania do rdzenia wcale nie jest potrzebne - wystarczy do zadania, które steruje LCD przypisać wyższy priorytet.

Rozdzielczość jest ustawiona na maksymalną wartość, można próbować ją zmienić używając plików /sys, ale chwilowo nie mam podłączonego czujnika żeby to przetestować i napisać jak dokładnie. Natomiast pytanie jest inne - po co zmieniać rozdzielczość?

Może skoro nauka Arduino to nic przyjemnego oraz strata czasu, to warto poszukać gotowego rozwiązania? Nie jestem fanem modelarstwa, ale jakoś mi się nie chce wierzyć, że nie ma gotowych sterowników do makiet - wystarczy poszukać i zamówić z dostawą do domu.

@atMegaTona prosiłem, żebyś powtórzył podstawy języka C (chociaż akurat tutaj jest mój błąd, bo pownniśmy pisać o C++). Ale niezależnie czy to C, czy C++ wskaźniki i tablice to co innego i nie chodzi tutaj tylko o możliwość zmiany wskaźnika. Wszystkich początkujących bardzo proszę o czytanie wypowiedzi kolegi @atMegaTona z zamkniętymi oczami - tablice i wskaźniki to nie to samo, a takie wpisy są tylko przykrym dowodem na to że w internecie znajdziemy mnóstwo bzdur i to jeszcze pisanych jako prawdy objawione A jak już uda się powtórzyć podstawy C oraz C++ to może będzie warto wyjaśnić, czym tablice i wskaźniki się różnią. PS. dla ustalenia uwagi: piszemy o tablicach statycznych, zostawiamy alokowane dynamicznie w spokoju.

Nie mieszajmy innym w głowie, czasem lepiej nic nie pisać niż pisać nieprawdziwe rzeczy. Wskaźnik i tablica to co innego w języku C, więc zapis const char *napis = "jakis napis"; oraz: const char napis[] = "jakis napis"; nie są równoważne, chociaż podobne. Zachęcam do poczytania podstaw języka C oraz sprawdzenia czym się różnią.