[Jarewa0606]

Kawałek kodu z biblioteki esp32 ROTS

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

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

[es2]

Kawałek kodu z biblioteki esp32 ROTS

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

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

I co z tego kawałka wynika?
Nie ma gwarancji, że delay == vTaskDelay w RTOS, którego użył autor tematu.

[kaczakat]

Kurs po polsku znajdziesz tu: http://www.embeddeddev.pl/kurs-freertos-wprowadzenie/, zasada działania będzie taka sama w Arduino AVR czy ESP.

[PierwszyWolnyLogin]

Nie znam się bo też jestem początkujący ale w przykładzie 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,...

Na pewno dobrze piszesz? Te pętle (jak i inne) mają działać "jednocześnie" i nigdy się nie kończyć.
W końcu to jest RTOS a nie głupia pętla loop()
PWL

[PierwszyWolnyLogin]

Tak z ciekawości, jak chcesz "pożenić" Arduino i RTOS?
Nie twierdzę, że się nie da, pamiętaj jednak, ze bez debugera będziesz długo walczył, a Arduino IDE nie wspiera debugera. Twórcy Arduino,m założyli, że Arduinowcy są nieomylni i debuger jest zbędny.
...
...
......
- Biegle posługujesz się przerwaniami od każdego możliwego układu peryferyjnego zarówno podczas nadawania jak i odbioru.
- Nie masz delay i pętli oczekującej na zdarzenie np

Ty musisz być chyba sparaliżowany od szyi w dół, że masz czas pierdolić takie bzdury...
Wypuściłem Cię na chwile z KF, ale widzę że to był błąd. Wracasz na miejsce - do niepoczytania filozofie...
PWL

[PierwszyWolnyLogin]

Znalazłem kolejna ciekawostkę.
Zadanie "RPMengine" z wstawionym delay(0) zwalnia...
Początkowo wykonywane jest <> 70000x/s po 30 minutach już tylko 8500x/s.
Sprawdze vTaskDelay(1), chociaz tu nie ma z czego zwalniac - odrazu dziala wolno

Ps. Wersja z vTaskDelay(1) początkowo dochodzi do 100x/s potem spada i stabilizuje sie na 55x/s

PWL

[Jarewa0606]

 Te pętle (jak i inne) mają działać "jednocześnie" i nigdy się nie kończyć.

Kod:

void RPMengine(void *pvParameters)  // This is a task.
{
  (void) pvParameters;

  for (;;) // A Task shall never return or exit.
  {
    RPM=RPM+1;

  }
}

Te zadanie nie ma końca a z poradnika co podał ci kolega 

W systemie FreeRTOS istnieje także możliwość pracy [b]bez wywłaszczania[/b]. 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.

[PierwszyWolnyLogin]

'Te zadanie nie ma końca a z poradnika co podał ci kolega'

I tak ma przecież być. Ma nie mieć końca

W takim wypadku to aktualnie wykonywane zadanie decyduje kiedy chce oddać kontrolę schedulerowi i umożliwić realizację innego.

No tak, ale po co? To są na razie proste przykłady i niech OS dba o to jak zadania
płyną. Po to w zasadzie jest Gdybym chciał ręcznie tym sterować używałbym \
niewygodnych millisów() i dłubał ręcznie...

PWL

[Jarewa0606]

I tak ma przecież być. Ma nie mieć końca

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

[es2]

Ps. Wersja z vTaskDelay(1) początkowo dochodzi do 100x/s potem spada i stabilizuje sie na 55x/s

RTOS+AVR = stabilność Window$ firmy Mikro$oft.
Walcz z AVR, jak masz zdrowie. Jak już stwierdzisz, że nie ma to sensu sięgniesz po ARM, gdzie takich cudów jak opisujesz nie ma. AVR-GCC jest kiepki, czego nie można powiedzieć o GCC na inne uC.:
- argument w sprintf, scanf itp nie jest ograniczony do 16-bit int lecz do 32-bit.
- przesuwane bitu (w lewo) nie jest ograniczone do 16 bitów.
- odkładanie na stos w przerwaniu rejestrów, które czasem nie sa używane (R0, R1, RAMPZ).
- W AVR nie ma typu double, ma taki sam zakres jak float. I tak dobrze, ze w którejś tam wersji, typ lolg long ma 64-bity a nie jeak wcześniej 32- tak samo jak long.
Jak już coś poważniejszego zrobisz, to zauważysz, że na uC z DMA (np Xmega, które niestety z reguły jest droższa od ARM a nadal wolna i 8-bit) wydajność znacznie wzrasta.
Spróbuj na AVRmega obsłużyć kilka długich (po 1000) gałęzi LED WS2812 odświeżanych co30ms, LCD o dużej rozdzielczości bez akceleratora graficznego odświażanie ok 390ms, dekodować DMX i rejestrować dane z portu 8-bit kilka Mega próbek na sekundę. Nie ma szans aby to zadziałało równocześnie, każda z tych operacji osobno tak, razem NIE! To samo na Xmega, z DMA zadziała!

Może chcesz używać RTOS do migania ledami, wtedy będzie ok (ale do tego nie trzeba RTOS), choć jak zauważyłeś po pewnym czasie coś się sypie.

Pożyjemy, zobaczymy. Prędzej czy później sięgniesz po ARM, bo nie będziesz miał wyjścia, a ja nie przejdę na AVR.