Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[AVR|C] agresywna optymalizacja gcc - co pominąłem

02 Lip 2012 22:36 1168 5
  • Poziom 24  
    Mam sobie
    Cytat:
    sulfur@sulfur-lenovo:~$ avr-gcc --version
    avr-gcc (GCC) 4.7.0
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    I do tego taki kod (wklejam istotne fragmenty)
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Kod: c
    Zaloguj się, aby zobaczyć kod
    Jeśli w kodzie są lcd_puthex(res); wszystko działa w 100%. Jeśli je usunę, to pojawiają się schody w postaci faktu, że funkcja wraca z kodem różnym od zera. W różnym czasie w różnej częstotliwości, więc nie ma, że nie działa w ogóle. Niech mnie ktoś oświeci, co pominąłem lub o czym zapomniałem. Dziękuję.
  • VIP Zasłużony dla elektroda
    Prawdopodobnie lcd_puthex(res); wprowadza opóźnienie... ;)
  • Poziom 32  
    W jakim celu dajesz volatile w parametrze funkcji? Przewidujesz, że wartość parametru się zmieni w trakcie wykonania takiej funkcji w sposób nie wynikający z kodu samej funkcji?
  • Poziom 24  
    Nie. Kiedyś funkcja była jako static inline z atrybutem always_inline, no i kompilator skracał sobie bezpośrednie wywołania. Bez tego volatile komunikacja częściej zawodzi.
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    Nie analizując kodu - gcc 4.7.0 ze wsparciem dla AVR to wersja nie do użytku produkcyjnego. To wersja testowa dla developerów gcc. Do użycia jako tako nadaje się wersja 4.7.1, a i tak z zastrzeżeniami. Skompiluj swój program wersjami 4.4 z WinAVR lub z toolchaina (nowego) Atmela i napisz czy błąd jest nadal. Jeśli tak to się zobaczy kod.
  • Poziom 24  
    Dziękuję za sugestie. Zmusiłem się do pomiarów. Kod pomiarowy.
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Funkcja wysyłająca bez volatile, bez udziwnień, wynik: 4300BC
    Funkcja wysyłająca z volatile, bez udziwnień, wynik: A60059
    Funkcja wysyłająca z volatile, GamePad_Process z optymalizacją 0, wynik: A70058
    Generalnie zastanawiam się też nad problemem sprzętowym. Przy 4MHz wszystko wydawało się działać poprawnie (lub odsetek błędów był pomijalnie mały). Niestety nie da się już zwolnić źródła zegarowego w SPI, co jak myślę rozwiązałoby problem.
    Jak ktoś ma jakieś uwagi to chętnie posłucham.