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

problem w kompilacji programu w Avrstudio+winAVR

slawek55 21 Lut 2010 19:31 1879 20
  • #1 7730029
    slawek55
    Poziom 23  
    Cześć.
    Zwracam się do Was z prośba o pomoc.
    Otóż pisze bardzo prosty program w języku C na Atiny13 w środowisku AVRStudio4+WinAVR i nie mogę spobie poradzić z czymś takim.
    Deklaruję zmienną globalną uint8_t oraz w samej funkcji main 4 zmienne uint16_t oraz 3 zmienne uint_8t.
    Próbuję skompilować program i otrzymuje taki wynik
    AVR Memory Usage
    ----------------
    Device: attiny13
    
    Program:    2506 bytes (244.7% Full)
    (.text + .data + .bootloader)
    
    Data:        257 bytes (401.6% Full)
    (.data + .bss + .noinit)
    
    Build succeeded with 0 Warnings...
    


    O co tu chodzi, co jest nie tak. Czy mogłem coś źle ustawić w AvrStudio. Tak szczerze mówiąc w opcjach zmieniałem tylko częstotliwośc CPU na 1200Hz oraz ustawiłem optymalizację na -s.

    Może mieliści podobny problem? pomóżcie to rozwiązać.

    Sławek
  • #2 7730130
    baxter007
    Poziom 11  
    Możesz pokazać kod, który kompilujesz ?? sprawdzę jaki bedzie u mnie rezultat.
  • #3 7730247
    Konto nie istnieje
    Poziom 1  
  • #4 7730271
    slawek55
    Poziom 23  
    Chyba nie bo to jest domyślna częstotliwość na wewnętrzym generatorze RC.
    Włśnie sprawdziłem, zmieniając na 10MHz i jest dokładnie to samo. Wiec to nie to
  • #5 7730339
    mirekk36
    Poziom 42  
    Problem leży w twoim kodzie gdzie popełniłeś jakiegoś babola i nawet nie wiesz gdzie ten babol jest. Być może zrobiłeś gdzieś dzielenie w ten sposób, że kompilator dociągnął sobie dodatkowe biblioteki do obsługi liczb zmiennoprzecinkowych - to najczęstszy babol gdy widzę u kogoś taki nagły przyrost pamięci RAM i FLASH

    No chyba że w ogóle kompilujesz wypasiony kdo dla np ATmega8

    albo wywołujesz polecenie _delay_ms() ale z parametrem zamiast ze stałą

    tylko co z tego wszystkiego ? skoro ty na upartego doszukujesz się winy kompilatora, sposobu komilacji a może nawet procka zamiast szukać winy u siebie w kodzie.

    co z tego? skoro kodu nie pokażesz - więc raczej możesz się z tym tylko do wróżki udać , która może ci przepowie prawdę ;)
  • #6 7730400
    slawek55
    Poziom 23  
    Dobrze proszę oto kod. mam nadzieję ze nie nikt nie obrazi (autor) za podesłanie go, mimo że jest on na EdW i było w nr 01/2010. ja tylko wrzuciłem do kompilatora, a autorowi sie udało, wiec dlaczego to ma być nie kompilator? Jesli znajdziesz o co chodzi to bedę bardzo wdzięczny, wiec jak mozesz to popatrz na niego.
  • Pomocny post
    #7 7730477
    mirekk36
    Poziom 42  
    A nie mówiłem ???? przecież pisałem ci że najprawdopodobniej masz zaprzęgnięte liczenie zmiennoprzecinkowe i proszę:

    /* -------------------- STAŁE -------------------- */
    
    #define RC5REF0 0x42		// czas na ustabilizowanie linii (3.52ms)
    #define RC5REF1	0x20*0.75	// ok. 3/4 bita (1.28ms)
    #define RC5REF2 0x20*1.25	// ok. 5/4 bita (~2.13ms)


    co to ma być: 0x20*0.75 albo to: 0x20*1.25 - masakra ;)

    Tak więc kompilator zadziałał całkiem słusznie!
  • #8 7730521
    slawek55
    Poziom 23  
    Dziekuję Ci bardzo. Miałeś racje.
    Byłem pewny, że jak kod jest "teoretycznie" sprawdzony to musi za działać. Ciekawe dlaczgo autorowi to poszło? celowy błąd?
  • #9 7730747
    Konto nie istnieje
    Poziom 1  
  • #10 7730824
    mirekk36
    Poziom 42  
    atom1477 napisał:
    Może jakimś innym kompilatorem to kompilował. Takim który widząc że jest to #define nie dołączał flaotów do kodu tylko policzył to sam.


    eee tam ;) .... zwykle tak to bywa ze sprawdzonymi kodami z netu. Owszem HEX działa ale już skompilowanie źródła nie za bardzo bo autorowi się nie chciało np nanieść poprawek - bo jeszcze coś zmieniał itp itd itp

    jest kilka rozwiązań tego problemu:

    1-sze to wziąć sobie liczbę 0x20 pomnożyć przez 0.75 i taką tam wpisać czyli 24, np tak:
    /* -------------------- STAŁE -------------------- */
    
    #define RC5REF0 0x42		// czas na ustabilizowanie linii (3.52ms)
    #define RC5REF1	24	// ok. 3/4 bita (1.28ms)
    #define RC5REF2 40 	// ok. 5/4 bita (~2.13ms)


    2-gie napisać to tak żeby było jawne rzutowanie typu i już będzie chulać:

    /* -------------------- STAŁE -------------------- */
    
    #define RC5REF0 0x42		// czas na ustabilizowanie linii (3.52ms)
    #define RC5REF1	(uint8_t)(0x20*0.75)	// ok. 3/4 bita (1.28ms)
    #define RC5REF2 (uint8_t)(0x20*1.25)	// ok. 5/4 bita (~2.13ms)
  • #11 7732258
    slawek55
    Poziom 23  
    Hej. Mam do Ciebie jeszcze takie pytanie przy okazji.
    Po kompilacji pokazuje sie komunikat o zajetości SRAM (całkowitej bo tam sa sekcje wypisane) i pokazuje 1 bytes (1,6%).
    Pokazuje 1 bajt mimo że deklarowane jest w sumie 11 bajtów (w tym 4 uint16_t).
    Jak uruchamiam symulacje i dodaje zmienne do "watch" to kazda zmienna jest pod innym adresem.

    Czy to jest prawidłowe że pokazuje tylko 1 bajt? Czy jest jakaś mozliwośc sprawdzenia, gdzie kompilator umieścił zmienne?
  • #12 7732342
    mj_2000
    Poziom 15  
    Pamiętaj, że do przechowywania zmiennych masz też (a może przede wszystkim) rejestry.
  • #13 7732351
    slawek55
    Poziom 23  
    No tak, ale czy jest jakas mozliwośc sprawdzenia gdzie kompilator umieścił zmienne. Jesli po kompilacji dostaje informacje że zajety jest 1 bajt SRAM a po przełączeniu na symulację i dodaniu zmiennych do "watch" widzę że one jednak są w SRAM pod róznymi adresami (co zgadzało by się z deklaracją) to gdzies jest błąd, albo kompilator mi xle pokazuje zajętośc ramu, albo symulator cos nie tak stwierdza.
    Jest jakis spis gdzie sa zmienne?
  • #14 7732384
    mirekk36
    Poziom 42  
    slawek55 ---> twoje pytanie wynika z dużej niewiedzy na temat działania języka C .... warto poczytać dokładniej na te tematy. Ale jak jeszcze raz napiszesz, że gdzieś w kompilatorze czy symulatorze jest błąd - to ja ci już więcej nie pomogę ;) .... bo zawsze uważam to za jakąś masakrę, że ludzie zamiast poczytać, doczytać i poszukać błędów w swoim działaniu czy toku myślenia to doszukują się o wiele szybciej błędów w kompilatorach albo nawet o zgrozo w samych procesorach!

    W skrócie żeby ci to wyjaśnić - to wszystko jest z tym 1,6% jak najbardziej w porządku.

    Otóż tylko jedną zmienną masz zdefiniowaną jako globalną:

    volatile int8_t tik=0;


    a reszta jak np te zmienne:

    	uint16_t bufor;
    	uint16_t rozkazPrzelacz=0x0000;
    	uint16_t rozkazMinutnik=0x0000;
    	uint16_t minutnik=0;
    	uint8_t opozniacz=0;	// zapobiega zbyt czÄ™stemu przełączaniu lampy
    	uint8_t sygnal=0;		// robi biiip! jak jest > 0 i nieparzyste
    	int8_t uczenie=8*4;		// czekamy 4s na naukÄ™ kodĂłw


    są zdeklarowane w ciele funkcji main prawda? A co oznacza, gdy deklarujesz w taki zwykły sposób zmienne w funkcji (w tym także w main) ? ... ano to, że są one deklarowane dynamiczne tylko na czas życia funkcji na stosie. A że akurat funkcja main żyje przez cały czas to i te zmienne żyją cały czas niechcąco ;)

    Spróbuj sobie całą to sekcję deklaracji zmiennych wywalić przed ciałem funkcji main - wtedy staną się one globalnymi i dla każdej z nich od razu zostanie zarezerowana komórka czy komórki pamięci i zobaczysz to właśnie jako większy procent zajętości RAM i ilości komórek ;)

    Ale poczytaj sobie też o zmiennych statycznych i w ogóle o innych fiuczersach języka C bo warto. Dzięki temu można później robić niesamowite rzeczy w swoich programach ;)

    A najważniejsze, żeby po poczytaniu i praktyce - wiedzieć później kiedy to lepiej robić zmienne i które jako globalne, kiedy jako dynamiczne na stosie , a kiedy jako np statyczne - plus wiele innych rzeczy, które wpływają m.inn na twoją optymalizację programu
  • #15 7732811
    slawek55
    Poziom 23  
    Masz rację, nie mam za dużej wiedzy i przyznaję się do tego, ale chciałbym ja mieć.
    Jeśli możesz to poleć mi dobrą lekturę na ten temat, bo faktycznie ciekawi mnie to.
    Przy takich sprawach wychodzi brak mojego doświadczenia.
    Mam nadzieję że Cię nie uraziłem, bo stwierdzenie "błąd kompilatora" było rzeczywiście nie na miejscu i przepraszam.

    Z wielkim szacunkiem dla Ciebie, Sławek
  • #16 7732929
    Konto nie istnieje
    Poziom 1  
  • #17 7732954
    slawek55
    Poziom 23  
    Czytałem, jest b. dobry, choć brakuje mi w nim kilku spraw.
  • #18 7732989
    Konto nie istnieje
    Poziom 1  
  • #19 7733248
    slawek55
    Poziom 23  
    A co myślisz że wszyskto było w kursie co powinno być? Brakowalo mi np pewnych sztuczek z C, z którymi spotkalem się przegladając niektóre listingi, ale nie jestem w stanie teraz z pamięci podać. Wybacz.
  • #20 7733271
    mirekk36
    Poziom 42  
    Wszelkiej maści kursy języka C na necie - uczą co najwyżej jak się poruszać w środowisku AVR za pomocą języka C a nie programowania tak ogólnie. Rzeczywiście akurat ten kurs z EdW jest chyba najlepszy.

    Ale żaden kurs z tych, które widziałem niestety nie nauczy tak całościowo technik dobrego programowania oraz wszystkich aspektów związanych z możliwościami języka C . Dobrej literatury w odniesieniu do języka C i mikrokontrolerów C tak na prawdę to w ogóle nie ma - i dlatego jest taki ból :( z nauką programowania w nim . Ale chodzi mi programowanie strukturalne oparte o zdarzenia, pseudo wątki, timery programowe itp. Jest wprawdzie namiastka tego w kursie z EdW ale początkującemu strasznie trudno się w tym połapać niestety, bo pomimo najszczerszych chęci autora tego kursu - zawsze występuje jakieś ograniczenie w takiej formie przekazu wiedzy. Dobra, obszerna książka byłaby o wiele lepsza ale takie brak.

    Dlatego trzeba się posiłkować czytaniem książek w ogóle na temat języka C nawt takich w oderwaniu od mikrokontrolerów bo jest to język uniwersalny a tutaj książek jest na szczęście i nieszczęście bardzo dużo. Czyli znowu problem bo nie wiadomo co wybrać żeby dobrze zacząć - trzeba więc kombinować sporo ;)

    Inną alternatywą jest zapisanie się na jakieś dobre kursy tego języka ;) to gorąco polecam...
  • #21 7733332
    slawek55
    Poziom 23  
    Powiem szczerze że z chęcią poszedłbym na taki kurs, zwłaszcza że w moim mieście też widzałem że jest organizowany, lecz jest tu jedno ale...
    Samemu trochę głupio, bo to hobby, a z drugiej strony mając materiały napisane np jako skrypt mogę często wracać do nich i wiecej mi zostanie w głowie.
REKLAMA