[PierwszyWolnyLogin]

Procesor jednocześnie tylko jedno zadanie na raz może wykonywać,  żeby wykonać drugie zadanie musisz zwolnić/wstrzymać pierwsze.

Przestań, przecież nie o taki poziom chodzi. Zaraz zejdziemy do asemblera

PWL

[es2]

Procesor jednocześnie tylko jedno zadanie na raz może wykonywać,  żeby wykonać drugie zadanie musisz zwolnić/wstrzymać pierwsze.

Przestań, przecież nie o taki poziom chodzi. Zaraz zejdziemy do asemblera

W AVR czasem musiałem używać ASM, konkretnie w projekcie WS2812 via DMX. Innej opcji nie było, bo AVR gubił znaki z USART.
W ARM jeszcze nigdy nie musiałem (i pewnie nie będzie potrzeby) sięgać po ASM. Mało tego, jest na tyle szybki, że jeszcze nie miałem potrzeby używania wielopoziomowego systemu przerwań.

Co do poziomu, teraz realizuję prosty projekt, w którym pliki BMP wczytywane z karty SD wyświetlam na LCD 128x128 16-bit SPI 15MHz. Muszę uzyskać co najmniej 10 klatek na sekundę, zrobisz to na AVR bez DMA?
Niemożliwe abyś równocześnie czytał kartę SD i wyświetlał obrazki na LCD 128x128. RTOS tu NIC NIE POMOŻE, a projekt jest banalny! Nic wydumanego!
W tym projekcie nie użyłem RTOS, bo nie ma takiej potrzeby, natomiast DMA musi być, inaczej nie da się tego zrealizować, chyba, że ARM będzie taktowany kilkoma GHz, wtedy zamiast DMA użyje przerwań. Gdy mam DMA, zadowalam się 36MHz.


PS
W ogóle kiedykolwiek używałeś DMA? Np na Z-80? Wiesz jak to działa? Na ile spowalnia CPU?

PS2
Większość projektów, które realizuję na ARM, da się zrealizować na AVR, ale:
1) Wymaga to większego nakładu pracy (czasu), więc jak klient zapiera się przy AVR, cenę za zlecenie typowo mnożę przez 2 (jak w Arduino IDE, ze względu na brak debugera, przez 4).
2) AVR przeważnie są droższe niż ARM, więc przy produkcji daje to oszczędności. Ten argument najczęściej trafi do zleceniodawcy, jeśli jednak jest zatwardziałym AVR-owcem i ma zamiar później na własną rękę wprowadzać zmiany w kodzie (dlaczego daje zlecenie skoro sam potrafi pisać programy?), trafia argument pierwszy.
3) Przy bardziej wymagających projektach (wspomniany WS2812 via DMX) nie mam rezerwy mocy i dodanie kolejnej funkcjonalności może być niemożliwe, w konsekwencji zmiana projektu, zarówno od strony sprzętu jak gruntowna modyfikacja programu (modyfikacja to koszty 70..90% wartości projektu na AVR).

[es2]

Zastanawiałem się, jak to możliwe, aby w kilka godzin z lamera, nie mającego pojęcia o RTOS

użyłeś dwie nie kończące się pętle to już twój zły tok rozumowania, bo pierwsza pętla nie pozwala uruchomić drugiej,

Stać się ekspertem? Świadczą o tym wypowiedzi, np:

W systemie FreeRTOS istnieje także możliwość pracy bez wywłaszczania W takim wypadku to aktualnie wykonywane zadanie decyduje kiedy chce oddać kontrolę schedulerowi i umożliwić realizację innego. Wymaga to większego zaangażowania programisty – musi on tak zaimplementować wszystkie zadania, aby każde z nich otrzymało odpowiednią ilość czasu procesora.

czy

Kawałek kodu z biblioteki esp32 ROTS

Kod:

unsigned long IRAM_ATTR millis()
{
    return (unsigned long) (esp_timer_get_time() / 1000ULL);
}

void delay(uint32_t ms)
{
    vTaskDelay(ms / portTICK_PERIOD_MS);
}

Nagły przypływ wiedzy?
Nie, po prostu kopiujesz, bez zrozumienia, teksty z Internetu i zamieszczasz na forum!
   
Dziwnie podobna wypowiedź, bardzo podobna! Nie, nie podobna, to po prostu kopia, nawet pogrubienie chciałeś skopiować ale nie wyszło.
   

[PierwszyWolnyLogin]

PS
W ogóle kiedykolwiek używałeś DMA? Np na Z-80? Wiesz jak to działa? Na ile spowalnia CPU?

Zauważyłeś JEŁOPIE o czym jest ten wątek?
Na pewno nie o twoich problemach, nikogo one nie interesują!

PWL

[Jarewa0606]

Dobrze ze dałeś screna bo wyżej przeczytaj zdanie . Nad tym co wkleiłem z poradnika.

RTOS już parę miesięcy temu ugryzłem i czytałem sporo ale niestety na zagranicznych stronach posiłkowałem się głównie stroną https://www.freertos.org .. Bo sam miałem problem z WDT obsługa WiFi przerwań jak i użyciem dwóch procesorów na ESP32. Jeszce się męczę i czytam bo nie wiem jak ustawić rozmiar "stosu" na prawidłowy.
W tej chwili ma ten sam błąd co ja miałem na przerywaniu z rozjeżdżaniem z początku ok a po czasie wyniki pomniejszone ale ja sobie poradziłem.

Ten kawałek kodu z biblioteki to po prostu dobra obsługa programu w którym pisze bo ma możliwość szybkiego podejrzenia deklaracji/definicji.


Dzis ma problem tylko z dwoma prostymi zadaniami, jak dojdą przerywania to dopiero głowa go zaboli od myślenia.

[es2]

W ogóle kiedykolwiek używałeś DMA? Np na Z-80? Wiesz jak to działa? Na ile spowalnia CPU?

Zauważyłeś JEŁOPIE o czym jest ten wątek?

Zauważyłem JEŁOPIE, że nie masz pojęcia o uC. Tylko jakieś zabawkowe AVR i Arduino IDE.

RTOS nie rozwiąże braku DMA, jeśli natomiast nie potrzebujesz DMA to na 99% i bez RTOS się obędziesz.
Co chcesz zyskać używając DMA? Opisz konkretny przypadek a ja napiszę czy da się to zrobić bez RTOS ale z użyciem DMA.

a pewno nie o twoich problemach, nikogo one nie interesują!

Problem to masz ty, próbując RTOS-em rozwiązać problem, który z dużą dozą prawdopodobieństwa można rozwiązać prościej ale trzeba zapomnieć o AVR i Arduino IDE za to zapoznać się z wielopoziomowym systemem przerwań (pewnie nie używałeś, ja tak: w Z-80 i pseudo na AVR, w ARM nie było potrzeby) i DMA.

Dzis ma problem tylko z dwoma prostymi zadaniami, jak dojdą przerywania to dopiero głowa go zaboli od myślenia.

Aby używac RTOS, trzeba dobrze znać kompilator, uC, biegle używać przerwań, DMA jak jest. Programy (bez RTOS) pisać bez delay itd, ipt o czym pisałem w swojej pierwszej wypowiedzi.
RTOS nie rozwiąże magicznie problemów "braku czasu CPU", którego powodem jest brak DMA czy brak pamięci RAM. RTOS lubi RAM, bo gdzie bufory UART, LCD i inne musi pomieścić. RTOS będzie działał dobrze gdy będzie miał bufory zarówno nadawcze jak i odbiorcze dla peryferii a nie jak w Arduino 64 bajty na bufor odbiorczy UART. Chcesz wysyłać dane do WS2812 to musisz je wszystkie zmieścić w RAM, odpalić DMA (ostatecznie przerwania) i wysłać. Jak RAM jest za mało i wszystkich danych nie zmieścisz, to RTOS niewiele poprawi sytuację w stosunku do tego jakbyś RTOS nie miał a czasem może nawet pogorszyć. To samo z LCD. RTOS wymaga więcej RAM niż programy używające z DMA bo każdy task ma swój stos. Owszem, można to zmienić ale pojawiają się kolejne kłopoty. W RTOS nie należy zawieszać przerwań, bo zwyczajnie przestaje on działać. Mało tego, RTOS rodzi nowe problemy, związane np z synchronizacją tasków, przekazywaniem danych z przerwań do tasków, itp, itd.

RTOS jest wygodny, ale aby spełniał swoje zadanie, musi dysponować dużą ilością RAM i na max wykorzystywać sprzęt, więc należy zapomnieć o obsłudze 1-Wire czy WS2812 przez "machanie" GPIO tylko użyć np UART.
Co da RTOS w AVR, gdy na czas obsługi 1-Wire czy WS2812 (np na 30ms) trzeba zawiesić przerwania? Taski mają być przełączane co najmniej co 1ms, WS2812 blokuje przerwania na 30ms. Co to oznacza? Ze co najmniej 30 tasków nie wykona się albo 2 taski nie wykonają się po 15 razy.
Jaka korzyść z RTOS? ŻADNA!
Trzeba więc najpierw biegle posługiwać się sprzętem peryferyjnym w uC a co za tym idzie, zapomnieć o Arduino.

W pierwszej wypowiedzi pokazałem porównanie obsługi TFT z DMA i bez. Widać wyraźnie, że dziesiątki razy szybszy ARM nic nie dał gdy nie używałem DMA, Czy w takiej sytuacji, RTOS rozwiąże problem wolnej animacji na wyświetlaczu? Nie, wręcz ją pogorszy, nieznacznie ale pogorszy!

[Jarewa0606]

Podpowiedz jak ugryźć rozmiar stosu dla zadania bez Deburgera?

[es2]

Podpowiedz jak ugryźć rozmiar stosu dla zadania  bez Deburgera?

Bez debugera do roboty nie podchodzę ale dawano, dawno, temu, za górami, za lasami, debugerów nie było lub były bardzo drogie (np do Z-80 $4000 i to za PRL więc majątek). Jakoś trzeba było sobie radzić.
Zadeklaruj przesadnie duży stos, wypełnij stos jakąś wartością, później co jakiś czas sprawdzaj w jakim obszarze nie było modyfikacji.

Rozwiązanie jest jeszcze inne, użyć uC z dużą ilością RAM - pisałem już, RTOS lubi RAM.
Co do debugera, nie wyobrażam sobie pracy bez niego. W początkowej fazie pisania softu jest używany bardzo, bardzo często. W pewnym momencie nie jest już potrzebny, jak wszelkie "drivery" działają poprawnie.

Bez debugera da się pracować, ale trzeba poświęcić dużo czasu mieć wolne zasoby (np UART). Co do UART, w każdym projekcie rezerwuję jeden UART lub sprzętowe USB na cele wspomagania debugowania. Tak jak w ARN raczej nie ma z tym kłopotu, tak w AVR już niekoniecznie (1, 2 max 4 UART). Można się ratować I2C i mostkiem USB (np FT201) lub SPI (FT220). Jak by nie było, takie dodatkowe debugowanie, to "koszt" nie tylko sprzętowy (wolny UART, dodatkowy układ SPI, "zajęcie czasu" magistrali I2C) ale także programowy (FLASH, której w AVR jest często mało, RAM, której jest bardzo mało, czau na wysłanie danych, bo nie ma tyle RAM aby zrobić bufor na dane i wysłać w przerwaniach).
Zanim zrealizowałem projekt emulatora DS18B20, DS2431 (overdirive) i podobnych na Tiny85, najpierw zrealizowałem go na Mega1281. Praca od razu na tiny, trwała by pewnie do dziś.

Jak mi się klient zapiera na Arduino IDE, to piszę w AS, używając debugera, później przenoszę to na Arduino. Metoda szybsza niż pisanie tylko w Arduino ale i tak czasochłonna przez to kosztowna. Na szczęście, takich klientów mam niewielu, przeważnie patrzą przez pryzmat kieszeni i wybierają ARM.