_delay_ms() vs delay()

[Belferek]

Wiadomo, że wszelkie blokujące delay-e to nie najlepszy wybór. Eksperymentując okazuje się, że programując Arduino Uno w dedykowanym IDE możemy oprócz standardowego delay() użyć _delay_ms(). Różnica jest od razu widoczna w wielkości kodu wynikowego. Kod z _delay_ms() jest wyraźnie mniejszy. Wiem, że to różne funkcje i zastanawiam się dlaczego we wszystkich źródłach dot. programowania w Arduino IDE preferuje się delay(), które generuje bardziej obszerny kod wynikowy. Pytanie więc do doświadczonych kolegów kiedy (a kiedy nie) możemy użyć _delay_ms()?

Edytowano Luty 11, 2020 przez Belferek

[Matthew11]

Szukając przez chwilę u wujka Google, _delay_ms() odnosi mnie do funkcji z bibliotek AVR. Natomiast delay() to funkcja z API (myślę że można nazwać to API) które stworzyło Arduino (lub Wiring jeśli tam było pierwsze). 

23 minuty temu, Belferek napisał:

Wiem, że to różne funkcje i zastanawiam się dlaczego we wszystkich źródłach dot. programowania w Arduino IDE preferuje się delay(), które generuje bardziej obszerny kod wynikowy.

We wszystkim spod parasola Arduino będzie używane właśnie delay(), dlatego że nieważne jaką płytkę weźmiesz, delay() i kod napisany za pomocą API Arduino, będzie działać funkcjonalnie (przynajmniej powinien) tak samo. A postarać się muszą o to twórcy konkretnej implementacji. I teraz jeśli _delay_ms() jest funkcją z biblioteki AVR, to niekoniecznie użyjemy ją dla płytek na procesorach ARM itp.

23 minuty temu, Belferek napisał:

Pytanie więc do doświadczonych kolegów kiedy (a kiedy nie) możemy użyć _delay_ms()?

Jak piszesz kod do konkretnego zadania i będzie tam tylko wspomniana 328P (lub inna z rodziny, dla której działa _delay_ms()), to używaj zoptymalizowanych funkcji. Natomiast jeśli piszesz "multiplatformowy" kod to używaj funkcji i metod z API Arduino.

Edytowano Luty 11, 2020 przez Matthew11

[ethanak]

Jeszcze jedno: delay() to funkcja, która zawiesza działanie programu na określony czas. W tym czasie możliwe jest wykonywanie przez procesor innych czynności (taki sztandarowy przykład to obsługa WiFi w ESP8266), przy czym do czasu zawieszenia nie dolicza się czas spędzony na obsłudze przerwań. Na odmianę _delay_ms() polega na odliczeniu iluś tam cykli procesora (przeliczonych z milisekund), realizowana jest po prostu przez pętlę wykonującą n obrotów. Procesor jest cały czas zajęty, a czas spędzony w przerwaniach będzie doliczony do czasu zawieszenia działania (w końcu pętla nie wie, że coś ją przerwało i wznowiło). Przy okazji - __delay_ms() nie potrzebuje żadnych timerów.

Obie funkcje są niedokładne i nie powinny być stosowane do odmierzania czasu.

A objętość kodu nie ma nic wspólnego z zastosowaniem danej funkcji. Z dokładnością do stwierdzenia, że w pewnych implementacjach kod delay() może być baaaaaardzo krótki - coś w stylu:
 

void delay(uint32_t parametr)
{
	extern volatile uint32_t millis_counter; 
  	uint32_t t=millis_counter;
	while (millis_counter - t > parametr);
}

gdzie millis_counter jest po prostu zwiększany w przerwaniu co milisekundę.

 

 

[Belferek]

1 minutę temu, ethanak napisał:

A objętość kodu nie ma nic wspólnego z zastosowaniem danej funkcji

Powiem jak Ferdek -" jak nie ma jak ma":

Skompilowany programik z 3 wywołaniami delay():

Szkic używa 2990 bajtów (9%) pamięci programu. Maksimum to 32256 bajtów.

I to samo kiedy zamieniam delay() na _delay_ms()

Szkic używa 2828 bajtów (8%) pamięci programu. Maksimum to 32256 bajtów.

Ja tu widzę różnicę 162 bajtów, a to już trochę jest.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

Z zastosowaniem - czyli z tym, do czego służy dana funkcja, a nie z tym że sobie ją wywołasz w programie 3 razy.

Rozumiem, że kompilując te testowe programy wyłączyłeś optymalizację?

 

Edytowano Luty 11, 2020 przez ethanak

[Belferek]

8 minut temu, ethanak napisał:

Rozumiem, że kompilując te testowe programy wyłączyłeś optymalizację?

Nie, kompiluję z domyślnymi ustawieniami świeżo zainstalowanego IDE 1.8.11

Gdzie w Arduino IDE mogę włączyć (wyłączyć) optymalizację, o której piszesz?

Edytowano Luty 11, 2020 przez Belferek

[ethanak]

Przed chwilą, Belferek napisał:

Nie, kompiluję z domyślnymi ustawieniami świeżo zainstalowanego IDE 1.8.11

No to testy możesz sobie obić o kant warsztatu, bo sprawdziłeś właśnie zdolność kompilatora do optymalizacji kodu obu funkcji.

6 minut temu, Belferek napisał:

Gdzie w Arduino IDE mogę włączyć optymalizację, o której piszesz?

W pliku platforms.txt - nie wiem gdzie u Ciebie siedzi, u mnie w ~/arduino-1.8.10/hardware/arduino/avr/platform.txt

 

[Belferek]

Dzięki za wskazówki. Daleki jestem od "testowania kompilatora". Chodziło mi najzwyczajniej o jakby nie było ponad 100 bajtów oszczędności bez wnikania w gąszcz opcji konfiguracyjnych kompilatora.

[Gość]

Wracając do meritum. Różnica w ilości zużytej pamięci w porównaniu pomiędzy obiema funkcjami zmniejsza się wraz z ilością wywołań. Każde wywołanie _delay_ms() generuje kod asm - im więcej wywołań tym więcej pamięci zużywa. Polecam zapoznać się z implementacją tej funkcji bo została ona napisana w sposób dość nietypowy. Natomiast funkcja delay() z arduino odwołuje się do globalnych zmiennych volatile co samo w sobie stanowi narzut na wykorzystanie pamięci. Z doświadczenia wiem, że bardziej optymalnym jest przeliczenie sobie instrukcji asm względem ustawionego taktowania i wielokrotne wywoływanie pętli opóźniającej, niż stosowanie _delay_ms() czy tym bardziej delay() arduino. Niestety taka pętla nie bierze pod uwagę czasu spędzonego w obsłudze przerwań na co zwrócił uwagę @ethanak. Można co prawda dopisać procedurę uwzględniającą wpływ przerwań ale w rezultacie nie będzie to znacząco lepsze rozwiązanie od funkcji delay(). Najlepszym i najdokładniejszym sposobem na precyzyjne odmierzanie odcinków czasu w avr jest zastosowanie RTC z timera 2 w trybie asynchronicznym co z kolei uniemożliwia taktowanie rdzenia szybciej niż pozwala na to wbudowany oscylator czyli 8MHz. Reasumując, jeśli się nie chce komplikować sobie życia najlepszym i uniwersalnym sposobem jest trzymanie się wstępnie wybranej konwencji, jeśli arduino to arduino jeśli AVR lib c to lib c.  Nadmienię jeszcze tylko, że najbardziej optymalna metoda to avr lib c + wstawki asm gdzie różnica z frameworkiem arduino pod względem prędkości działania i użycia pamięci jest tak znaczna w wielu przypadkach, że wykorzystanie arduino wręcz uniemożliwia realizację założonych celów, jest to niestety żmudne i czasochłonne. Na szczęście takich przypadków nie ma zbyt wiele a samo arduino też korzysta z avr lib c.

[marek1707]

42 minuty temu, Belferek napisał:

_delay_ms() dla AVR-ów wydaje się być mniej "zasobożerne

Nie wiem czy nawet to Twoje stwierdzenie jest prawdziwe. Otóż _delay_ms() z biblioteki standardowej ma atrybut inline co oznacza, że tekst tej funkcji będzie "wkompilowany" do Twojego kodu w każdym miejscu gdzie ją wywołasz. Za pierwszym razem to nie boli, ale jeśli w programie masz 100 delay'ów, może byś słabo. Za to pierwsze użycie delay() co prawda od razu pociąga za sobą wstawienie micros() i całego mechanizmu timerowego "zegarka" do odliczania 1ms przerwań , ale za drugim razem to już tylko zwykłe wywołanie funkcji kosztujące parę bajtów kodu. Co więcej, im większy jest argument _delay_ms(), tj. im dłuższe jest żądane opóźnienie tym bardziej rozbudowana pętla opóźniająca musi zostać zbudowana w kodzie, co pociąga za sobą większe zużycie FLASHA. I na koniec: z tego co widzę, wersja _delay_ms() używana w moim Arduino wymaga argumentu degradowalnego do stałej w czasie kompilacji a więc nie możesz wywołać jej z opóźnieniem wyliczanym przez program. Zwykłemu delay()( to oczywiście nie przeszkadza..

Z tego co widzę, to na Arduino mega328 wystarczy 25 wywołań _delay_ms(100000) by (oprócz tego pusty) program był dłuższy niż ten z 25 wywołaniami delay(100000). Mimo początkowej przewagi prawie 200 bajtów przy jednym wywołaniu każdego z opóźnień..

Edytowano Luty 12, 2020 przez marek1707
atMegaTona: Pisaliśmy jednocześnie :)

[Gieneq]

Myślę że ten burzliwy temat został wyczerpany i można go zakończyć 🙂