ATNEL tech-forum

Re: Timery programowe - próba "uproszczenia kodu"

2015-04-12T16:10:04+01:00

Dziękuje Wam koledzy za solidne wyjaśnienie tematu.
Myślę, że wyprostowaliście moje błędne pojęcie o uproszczeniach w kodzie i pseudo-optymalizacji oraz naprowadziliście na dobre tory:)
Wniosek jest taki, że lepiej jednak przesadnie nie oszczędzać na pamięci i mieć szybciej działający program (oczywiście to zależy od założeń projektu).
Najlepsza jest zasada "złotego środka" żeby ani pięty, ani nos zbytnio nie zmarzły:)

Jeszcze raz Wielkie Dzięki

Statystyki: Napisane przez gordon10 — 12 kwi 2015, o 16:10

Re: Timery programowe - próba "uproszczenia kodu"

2015-04-12T13:05:36+01:00

gordon10 napisał(a):

Dlaczego tak się dzieje (że zajmuje więcej FLASH-a)?

Widzisz pan - tu przydaje się znajomość asemblera, mówię o nim w kilku swoich poradnikach o łączeniu C z ASM i warto by chociaż je sobie obejrzeć to już by ci dużo dało .... masz po kompilacji plik *.lss właśnie w asm i możesz tam zajrzeć do procedury obsługi przerwania po swojej niestety "nieudanej" optymalizacji i zobaczyć czym to się różni ....

gordon10 napisał(a):

Czy moje rozwiązanie wykonuje się wolniej niż "Mirkowe" z BlueBooka?

To nie jest tylko twój pomysł, mnóstwo osób wpada na taką "ala optymalizację" i ten temat był i jest często wałkowany nawet na tym forum, czasem warto poszukać - ale przypominam ze stoickim spokojem - że działa to co zrobiłeś wolniej i to TYM wolniej im więcej takich timerów programowych sobie utworzysz, a to rozwiązanie z BB działa wiele szybciej a ma to SZCZEGÓLNE znaczenie w mechanizmie napędzania timerów programowych szczególnie gdy chcesz uzyskać jak najkrótsze czasy.

gordon10 napisał(a):

Czy można przyjąć taką (prostą) zależność, że im program zajmuje mniej FLASH-a, tym jest bardziej zoptymalizowany (i szybciej się wykonuje)?

Absolutnie nie można globalnie takiego założenia przyjąć i co gorsza NIE ZAWSZE słowo OPTYMALIZACJA oznacz to samo. Czasem zależy nam na optymalizacji czasu i robimy to np KOSZTEM pamięci FLASH (co dokładnie opisuję na fajnym wydaje mi się przykładzie w Greenbooku - gdy pokazuję jak zrobić programową obsługę magistrali audio I2S), ale podobnie w poradnikach video na YT o magic LED'ach.

Innym razem potrzebujemy optymalizacji pamięci FLASH czy RAM nawet kosztem czasu, który może nie być najważniejszy w tych aspektach projektu itp itd

Statystyki: Napisane przez mirekk36 — 12 kwi 2015, o 13:05

Timery programowe - próba "uproszczenia kodu"

2015-04-12T12:23:33+01:00

Witam,

Ostatnio testowałem timery programowe z BlueBooka i wpadłem na pomysł, że może wprowadzę pewne uproszczenie (tak jakby optymalizację) kodu w przerwaniu ISR(TIMER2 COMP vect)

Zamiast kodu:
[syntax=c]ISR(TIMER2_COMP_vect) {
uint16_t x;
x = Timer1;
if (x) Timer1 = --x;
x = Timer2;
if (x) Timer2 = --x
/*...itd...*/
}[/syntax]

Zastosowałem taki zapis:
[syntax=c]ISR(TIMER2_COMP_vect) {
if (Timer1) --Timer1;
if (Timer2) --Timer2;
/*...itd...*/
}[/syntax]

Kod działa poprawnie. Myślałem, że pozbycie się dodatkowej zmiennej uint16_t x; zmniejszy kod wynikowy (i bardziej zoptymalizuje działanie Timerów programowych). Jednak okazało się, że przy tym rozwiązaniu program zajmuje więcej pamięci FLASH. Stąd moje pytania:
Dlaczego tak się dzieje (że zajmuje więcej FLASH-a)?
Czy moje rozwiązanie wykonuje się wolniej niż "Mirkowe" z BlueBooka?

Dodatkowo przy tej okazji chciałem spytać: Czy można przyjąć taką (prostą) zależność, że im program zajmuje mniej FLASH-a, tym jest bardziej zoptymalizowany (i szybciej się wykonuje)?

Statystyki: Napisane przez gordon10 — 12 kwi 2015, o 12:23