logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[avr][c]AVR-gcc i uint32_t/uint64_t, jak sobie radzi?

PO. 11 Maj 2010 19:53 4076 19
  • #1 8063736
    PO.
    Poziom 20  
    Tak jak w temacie. Musiałem coś dokładniej policzyć i użyłem uint64_t. Niby wszystko wydaje się w porządku, kompilator nie krzyczy, progam się wykonuje ale boję się czy implementacja nie zawiera jakichś skrótów na, było nie było, 8bitowy procek ;) i czy wszystko jest liczone tak jak chcę (powinno być).
    Drugie, jak wygląda "koszt" czasu wykonywania operacji na tak dużych zmiennych oraz dodatkowego kodu dodanego do obsługi tegoż? Program strasznie mi się rozrósł mimo optymalizacji a wydaje się, że nic w nim nie ma... Bez optymalizacji to w ogóle masakra, 200% flasha.
    Chciałbym poznać "ukryte niebezpieczeństwa" zanim się zbłaźnię.
  • #2 8063814
    markosik20
    Poziom 33  
    PO. napisał:
    Musiałem coś dokładniej policzyć i użyłem uint64_t.


    Mogę się założyć że dało by radę to prościej policzyć bez wykorzystywania 8bitowych zmiennych :wink:. Określenie czasu takich obliczeń oraz zajętości flasha jest mocno uzależnione od tego jakie operacje wykonujesz (dodawania, odejmowania etc). Generalnie wykorzystywanie takich liczb w 8bitowcu jest nieporozumieniem.
  • #3 8063943
    tmf
    VIP Zasłużony dla elektroda
    Niby czemu nieporozumieniem? Jeśli się wyrabia czasowo i pamięciowo to w czym problem?
    Implementacja zmiennych 64-bitowych w gcc jest ok, w końcu skoro to działa na innych procesorach to i na AVR będzie. Miejsce zajmowane przez funkcje łatwo sprawdzić analizując wygenerowany plik map. Co do kosztu - najprościej zapuścić na symulatorze, np. w AVR Studio i popatrzeć ile cykli to zajmuje - będziesz miał ogólne pojęcie na temat obciążenia czasowego wnoszonego przez tego typu operacje. Oczywiście dodawanie i odejmowanie można śmiało przyjąć, że wzrośnie co najwyżej dwukrotnie w stosunku do int16_t, natomiast dosyć masakryczne może być mnożenie (acz nie aż tak bardzo), gorzej z dzieleniem. Ale też bez tragedii, skoro AVR sobie nawet z float radzi...
  • #4 8063967
    Konto nie istnieje
    Poziom 1  
  • #5 8063996
    PO.
    Poziom 20  
    Może by dało, ale nie wnikajmy... Wolałbym wniknąć nawet nie ile to trwa (bo to pojedyncze obliczenia) ale jak to się przekłada na dodatkową zajętość flasha przez procedury do obsługi tego. Jest tam generalnie jakieś mnożenie i dzielenie.

    To może z innej beczki: jak wygląda obsługa floatów w takim razie ;) ? Będzie "taniej"?


    PS: dzięki za poparcie, w epoce marketingowej już dostaję paranoi :P ...
    Właśnie z objętością wsadu jest krucho bo dobiłem do 99% i mało miejsca na zmiany/dodatki na przyszłość - choć bardziej z ciekawości pytam jak to się ogólnie kształtuje, żeby poznać lepiej sprzęt niż z nadziei, że coś zmienię.
  • #6 8064028
    Konto nie istnieje
    Poziom 1  
  • #7 8064054
    markosik20
    Poziom 33  
    No może trochę przesadziłem...ale skoro autor pisze że
    Cytat:
    Program strasznie mi się rozrósł mimo optymalizacji a wydaje się, że nic w nim nie ma
    to musiał ich użyć do dosyć "pamięciożernych" obliczeń :wink:.
  • #8 8064108
    PO.
    Poziom 20  
    markosik20 napisał:
    No może trochę przesadziłem...ale skoro autor pisze że
    Cytat:
    Program strasznie mi się rozrósł mimo optymalizacji a wydaje się, że nic w nim nie ma
    to musiał ich użyć do dosyć "pamięciożernych" obliczeń :wink:.


    No więc właśnie. Później siądę podejrzeć. Program, wydaje się, że nic w nim nie ma, że większe programy zajmowały mi mniej a w pewnym momencie, nawet nie zauważyłem w którym tak spuchł wsad, że nie wiedziałem co ciąć, żeby się zmieścić :/ . Najśmieszniejsze, że pozbywając się wodotrysków, wydawałoby się obciążających flash (typu mapa polskich czcionek, pełne 18 i ich generator, jakieś dodatkowe komunikaty itp) prawie nic nie zyskiwałem ;) .
    No i teraz szukam co może być przyczyną, przychodzą mi do głowy tylko te nieszczęśliwie wielkie zmienne.
  • #9 8064119
    Mat_91
    Poziom 25  
    No ok, 99% flasha... tylko pytanie w jakim to uC?;> któraś z największych atmeg czy może jeden z najmniejszych attiny?
    Bo jak dla mnie 99% to pojęcie względne, może to być 500 bajtów a może być 500kB.

    PO. napisał:

    No i teraz szukam co może być przyczyną, przychodzą mi do głowy tylko te nieszczęśliwie wielkie zmienne.


    W takim razie spróbuj za komentować fragmenty kodu które z nich korzystają i sprawdź jaki będzie efekt.
  • #10 8064137
    PO.
    Poziom 20  
    Mat_91 napisał:
    No ok, 99% flasha... tylko pytanie w jakim to uC?;> któraś z największych atmeg czy może jeden z najmniejszych attiny?
    Bo jak dla mnie 99% to pojęcie względne, może to być 500 bajtów a może być 500kB.


    Zaspokoję Twoją ciekawość, a168 - przewidywałem że w docelowym projekcie a88 wystarczy... Bez optymalizacji to w ogóle ze 32k wychodzi, nie wiem czy jest się czym chwalić...
  • #11 8064143
    Konto nie istnieje
    Poziom 1  
  • #12 8064165
    Mat_91
    Poziom 25  
    PO. napisał:
    Zaspokoję Twoją ciekawość, a168 - przewidywałem że w docelowym projekcie a88 wystarczy... Bez optymalizacji to w ogóle ze 32k wychodzi, nie wiem czy jest się czym chwalić...


    To nie ciekawość tylko próba zejścia "na ziemie" w tym temacie, chodziło mi o to że rozmawiamy o jakiś 99% co tak naprawdę nie daje nam nawet wyobrażenia co możesz mieć w programie i ile może być takich obliczeń na tych dużych liczbach:) Teraz będzie prościej.

    Jak chcesz się dowiedzieć co tak naprawdę jest "słabym ogniwem" twojego programu to musisz sprawdzać. Za komentuj odpowiednie fragmenty kodu (te z tymi obliczeniami) i sprawdź jaki będzie efekt.
  • #13 8064167
    PO.
    Poziom 20  
    Te 99% podałem, bo się czerwona lampka w mózgu zapala ;) . Było już ~105% ale zszedłem (nie pamiętam już na czym) i nawet polskie czcionki wróciły :D .
    To mój pierwszy projekt, który tak wyskoczył, pozostałe mimo że większe się jakoś ładnie mieściły w 10-12kB i po wcześniejszych doświadczeniach myślałem, że spokojnie się w 8kB zmieszczę - dobrze, że nie musiałem ;) .

    PS: do sprawdzania siądę chyba jutro, teraz się odstresowuję intelektualnie :E .

    PS2: musi być niestety dość dokładny pomiar i wynik i taki mi wyszedł zakres z kartki, potem jeszcze "przesunięcie" przecinka żeby to po ludzku wyświetlić i się zebrało... Już nie pamiętam ile jest czego dokładnie, nie mam pod ręką teraz kodu.
  • #14 8064667
    tmf
    VIP Zasłużony dla elektroda
    Nie wiem po co komplikujecie proste sprawy - chcesz się przekonać co ci żre pamięć to przejrzyj plik map - przecież tam masz dokładnie to czego szukasz - adresy i nazwy procedur, z czego możesz policzyć ile one zajmują. A jak to za mało to można sobie wygenerować elegancką listę funkcji posegregowaną od najdłuższej do najkrótszej lub odwrotnie.
  • #15 8065907
    PO.
    Poziom 20  
    Poblokowałem kawałki z użyciem liczb większych niż uint16_t i same deklaracje i jest nieco powyżej 14kB - więc wychodzi niecałe 2kB na obliczenia, ale w tym jest też trochę innego kodu więc można uznać, że nie tak dużo.
    Innymi słowy, śmietnik jest też gdzie indziej.
  • #16 8067254
    Konto nie istnieje
    Poziom 1  
  • #20 8067991
    PO.
    Poziom 20  
    Nie używam printf().

    Mam własną dużą bibliotekę do lcd, dopisuję na bieżąco różne wodotryski.
    Generator mam tylko dla polskich znaków, ale za to komplet wszystkie małe i wielkie, razem wychodzi 18sztuk, wrzuca sobie dynamicznie tyle ile potrzeba - i jak będzie musiał wyświetlić dziewiąty naraz na tym samym ekranie to niestety ale już podmieni najdawniej użyty i będzie krzaczek w tekście.
    W sumie to jest to tak napisane, że mogę zdefiniować dowolne czcionki w tablicy w dowolnej liczbie i w tablicy czcionek jest dodatkowy wiersz na znak pod który podmienia więc mogę dowolne znaki/ikonki w postaci "tekstu" wyświetlać zamiast danego standardowego znaku z pamięci wyświetlacza. Tylko dalej jest to 8pól więc osiem różnych własnych znaków naraz na wyświetlaczu - czyli pilnujemy się przy układaniu komunikatów ;) - no ale tego ograniczenie nie ma jak przeskoczyć, żadną inną metodą także.
    Polskich znaków używam we wszystkich projektach standardowo i dopiero jeśli się nie mieszczą to kombinuję - po prostu prostszą funkcję wyświetlania wtedy stosuję i komunikaty bez ogonków - ale "cena" w pamięci okazała się niewysoka więc nie ma co sępić ;) .

    Poza tym w bibliotece obecnie są cyfry podwójnej wysokości w kilku krojach, różne ikonki, automatycznie przełączanie linii e jeśli jest kilka kontrolerów, zawijanie tekstu to chyba standard :) z pilnowaniem pozycji znaku ;) . Wyświetlanie różnych liczb w różny sposób. Przełączanie kilku wyświetlaczy jeśli są po i2c (każdy może mieć inną wielkość), choć to ostatnie niedopracowane.
    Więcej nie pamiętam :P , dopisuję sobie w miarę potrzeby i biblioteka się rozrasta, jest wspólna dla wszystkich projektów (oczywiście includuję tylko te fragmenty które potrzeba i w takiej wersji jak potrzeba, np warstwa fizyczna jest oddzielona od warstwy "konfiguracyjnej" pośredniej i od wspólnej warstwy zewnętrznych procedur wykonawczych).

    Dobra, dość lansowania ;) .
REKLAMA