Jak poradzić sobie z dziwną optymalizacją kompilatora przy programowaniu w C dla ATMEGA?

Sun Apr 01, 2007 8:39 pm   

Szanowni poradźcie coś bo szlag jasny trafi.
Znam język C może nie jak haker ale sobie radzę, z tego tez powodu i tego że
C jest uznanym językiem programowania
zdecydowałem się na programowanie uProców (ATMEGA) w C.
Okazuje się że znac język to pikuś, najciekawsze to nauczyć się ( i to
dosłownie) kompilatora.
Ten skurczybyk nie daje mi spokoju.
Co jakiś czas daje o sobie znać jego nieobliczalność.
Jak tu pisać programy jak kompilator swoimi widzimisiami pieprzy (tak
PIEPRZY) mi w kodzie.
Dla przykładu:

while(1)
{
alarm=204;
lcdliczba(alarm);
_delay_ms(200);
lcdliczba(178);
_delay_ms(210);
_delay_ms(230);
beep();
}


Pętla nieskończona,powiem tylko że lcdliczba to procedura z moich
obsługujących LCD 2x16 wyświetlająca liczbę, na końcu buzzer pipczy.
Działa to tak że na LCD-ku dostaję 204 które sobie mruga ( a właściwie
faluje bo przy takich szybkich zmianach tak to wygląda).
i nic więcej.
Więc pytam JAKIM KURCZE PRAWEM !!!
Oczywiście jak wypierniczę optymalizację (domyślne "s" zmianiam na "0") to
leci dwie liczby jedna za drugą i pipczy mi buzzer
więc działa tak jak powinien. Dodam że żadne pośrednie opcje optymalizacji
nie działają - tylko całkowite wyłączenie.
Czy jest jakiś sposób na takie pisanie kodu żeby ten wariat kompilator mi
nie pitolił?
Wyłączenie optymalizacji wiadomo nie wchodzi w grę bo kod się robi w cholerę
duży.
Łatwiej się pisze w C szczególnie coś większego ale widzę że jednak
assembler rządzi.


Rafał

Sun Apr 01, 2007 9:23 pm   

Kacper <elkacper@gazeta.pl> pisze:


Z avr/delay.h

The macro F_CPU is supposed to be defined to a
constant defining the CPU clock frequency (in Hertz).

The maximal possible delay is 262.14 ms / F_CPU in MHz.

Zastąp te _delay_ms(230); na kilka mniejszych delayów
i powinno być git.

--
Pozdrawiam,
Patryk Sielski
http://www.usprawnienia.pl

Mon Apr 02, 2007 7:48 am   

Ano właśnie zapomniałem dodać że Atmel leci na zegarze wew. 1MHz więc
dzielenie nic nie zmieni.
Poza tym dlaczego działałoby bez optymalizacji a przy włączonej już nie.
No i ostatecznie przy błędzie spowodowanym opóżnieniem nie działałby LCD bo
tam też czasy reguluję z delay.h
Zatem to nie opóźnienia.
Jeżeli zmieniając ustawienia optymalizacjiprogram działa albo nie to chyba
tu trzeba szukać przyczyny.


Rafał

Mon Apr 02, 2007 8:31 am   

Zobacz jaki kod assemblera został wygenerowany przez kompilator. Możliwe
że gdzieś zapomniałeś o volatile. Optymalizator zadziałał jak
najbardziej poprawnie: przyspieszył działanie programu .


Jeżeli chcesz aby coś nie zostało zoptymalizowane to musisz dawać volatile.

--
Pozdrawiam
Maksymilian Dutka

Mon Apr 02, 2007 9:31 am   

Czy można jakoś blokować obszary ktorych ma nie optymalizować,
czy dotyczy do tylko zmiennych.
Dotychczas stosowałem volatile do zmiennych, a można jakoś szerzej?

Rafał

PS. A przy okazji jak deklarować zmienne których chcę używać w programie
głównym i podprocedurach?
Sprawdzałem już volatile i działało ale nie wiem czy to poprawnie.




Użytkownik "Maksymilian Dutka" <maxdutka@usunpoczta.onet.pl> napisał w
wiadomości news:euqbp2$soj$1@nemesis.news.tpi.pl...

Mon Apr 02, 2007 1:04 pm   

Kacper napisał(a):

O ile pamiętam można też przed funkcjami dopisywać. Inne metoda to
rozbić projekt na kilka plików "C" i nie wszystkim włączać optymalizację.
Problemy po optymalizacji przeważnie wynikają z tego iż jednak jest coś
nie tak w kodzie, posprawdzaj czy gdzieś nie wychodzisz poza tablice itp.
Kod po optymalizacji wygląda inaczej i czasem dopiero wtedy wychodzą
jakieś błędy zrobione w kodzie.


--
Pozdrawiam
Maksymilian Dutka