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

[ATmega88][avr-gcc] - niezrozumiałe skoki programu

x-fly 17 Sty 2014 11:34 1440 10
  • #1 17 Sty 2014 11:34
    x-fly
    Poziom 9  

    Kłaniam się, no zostałem zmuszony i proszę o rozwikłanie "zagadki", przypuszczam że to banał, już wyjaśniam.
    Piszę w AtmelStudio6.1 program na atmege88 do obsługi silnika krokowego. W opcjach projektu mam z listy wybrany mikrokontroler. Zużywam na obsługę 6 nóg portu C. Kwestia rozchodzi sie o sam kompilator. Korzystam z symulatora (start debuging and break) i jade po kolei linia po linii (step into) i natrafiam na coś takiego:
    - kompilator nie reaguje na definicje zmiennej POS i wpisanie do niej 0
    - dopiero kiedy w switchu wpiszę (POS=0) lub (POS=1) to reaguje
    - LUB dopiero kiedy przeniosę definicję do funkcji głównej main to jest ok.

    Kiedy int POS=0 (lub=1) jest tuż za #define a przed 'main' to program skacze po ustawieniu DDRC do warunków if co dla mnie jest kompletnie niezrozumiałe. Sądziłem że jeśli definiuje zmienne poza funkcją 'main' to mają one zakres globalny widoczny dla całego pliku projektu a jeśli w funkcji 'main' to zakres lokalny widoczny tylko w 'main'.
    Bardzo proszę o wyrozumiałość, pewnie to banał jak nie wiem co :D

    Tu jest kod asemblera gdzie po ustawieniu DDRC przechodzi do warunków IF :?: :?: a dopiero później do sprawdzania SWITCH

    Kod: asm
    Zaloguj się, aby zobaczyć kod


    Kod: c
    Zaloguj się, aby zobaczyć kod
    »

    0 10
  • #2 17 Sty 2014 12:04
    BlueDraco
    Specjalista - Mikrokontrolery

    Po pierwsze - to, co piszesz o kodzei asemblerowym, nie jest prawdą - tam jest tylko ładowanie wartości, a nie ewaluacja warunku pod if().
    Po drugie - bez odstępu czasowego pomiędzy krokami silnik raczej nie ma szans ruszyć. Jak sprawdzasz ten kod i skąd wiesz, że on nie działa/działa źle?

    0
  • #3 17 Sty 2014 12:20
    x-fly
    Poziom 9  

    Dobrze. Zmieniłem w treści że program nie sprawdza warunku tylko do niego przechodzi (do linii z warunkiem).
    A pomijając kod ASM, a biorąc pod uwagę kod C to:
    - dlaczego program po DDRC skacze do if'ów jeśli definicja POS jest poza 'main' ?
    wygląda to tak jakby sobie losowo skakał, pomimo że POS=0 to on skacze do if'a który jest zawarty w 'case' dla POS=1
    - dlaczego program po DDRC przechodzi (prawidłowo) do switch'a jesli definicja POS jest w 'main' ?

    Póki co definicje zmiennych przeniosłem do 'main', deklaracja funkcji jest dalej przed 'main'. W takiej konfiguracji program wydaje się działać OK.

    Co do kroków to będzie to zrealizowane na przerwaniu wewnętrznym tzn będzie czytana wartość POS z pamięci i po wystąpieniu przerwania będzie realizowany 'switch'.
    Oczywiście przerwanie będzie co np 50msek, póki co sprawdzam wszystko symulatorem.

    0
  • #4 17 Sty 2014 13:57
    BlueDraco
    Specjalista - Mikrokontrolery

    Kompilator wie, że zmienna POS jest stałą, więc eliminuje zbędny kod - żaden switch nie jest mu w tym programie potrzebny. Uruchamiasz program w sztucznym środowisku i oczekuesz, że program będzie reagował na to, czego w nim nie ma, czyli na ręczne zmiany wartości stałych?

    0
  • #5 17 Sty 2014 14:15
    x-fly
    Poziom 9  

    Ano fakt, to prawda, ale jedna rzecz nie daje mi spokoju. Dlaczego program inaczej zachowuje się kiedy definicja int POS=1; jest przed 'main' a inaczej kiedy wewnątrz 'main' tzn.:

    założenie: int POS=2;
    - kiedy definicja POS jest za #define ale przed 'main' (zasięg globalny) to program przechodzi (pokazuje to podświetleniem linii) do 'switch' i dalej do 'case 2'
    - kiedy definicja POS jest w środku 'main' (zasięg lokalny) program skacze od razu do 'case 2'.

    Należy tłumaczyć to tylko zachowaniem się kompilatora wobec zmiennej o z góry zdefiniowanej wartości ?

    SKĄD taka różnica w działaniu programu w zależności od miejsca definicji POS :?:

    0
  • #6 17 Sty 2014 14:30
    BlueDraco
    Specjalista - Mikrokontrolery

    I tak sobie gdybasz zamiast robić prawdziwy projekt. Kompilator inaczej traktuje zmienną lokalną, niż statyczną. Wolno mu.

    0
  • #8 17 Sty 2014 14:43
    x-fly
    Poziom 9  

    Wychodzi na to że ten kompilator "nienajgorzej" ;) jest napisany.

    Dziękuję Ci BlueDraco za pomoc, wszystkiego dobrego życzę

    A projekt jest w drodze. Że to pierwsze moje kroki w programowaniu avr to nie bardzo odnajduję się który proc wybrac stąd testuje moje wypociny na symulatorze. Sprawdzam ile pamięci zajmie program. Że tak powiem "przygotowuje się". Wybrałem Atmege88 bo można go puścic na 20MHz co zrekompensuje mój nieudolny czyli niezbyt szybko działający program (żeby ten silniczek jakoś w miarę się kręcił).

    A jeśli mogę spytać bo może będziesz wiedział... Potrzebuje podłączyć do Atmegi zewnętrzną pamięć 1MBajt w której będę przechowywał właśnie wartości "POS" i z której Atmega będzie sobie te dane w przerwaniach pobierała. Zastosowanie obsługi kartySD jest tu raczej nieodpowiednie. Kojarzysz czy można to jakoś zrealizować ?

    ...o proszę, i Pan Dondu się odezwał, a od Pana (i reszty zespołu) się zaczęło, tzn ja zacząłem od przeczytania prawie wszystkiego z blogu. Może nikt mnie za to nie zgani że pochwalę treść i sposób jej przekazywania i cierpliwość w odpowiadaniu na komentarze (na blogu oczywiscie). Co do tematu to bardzo dziękuję za krótkie treściwe odpowiedzi, bywam mocno dociekliwy stąd te pytania..

    0
  • #9 17 Sty 2014 14:59
    BlueDraco
    Specjalista - Mikrokontrolery

    Jeśli to pierwsze kroki w AVR, to może zmień atchitekturę na coś współczesnego. Taki np. STM32F0 "można puścić" na 50 MHz, ma znacznie mądrzejsze peryferiale i jest tańszy od ATmega.

    0
  • #10 17 Sty 2014 15:17
    x-fly
    Poziom 9  

    Wszedłem już w te avr za mocno. Przygotowalem sie psychicznie mentalnie i jakkolwiek zeby sprostac temu wszystkiemu :) Troche czasu juz im poswiecilem. Wymagający nie jestem aż nadto jeśli chodzi o różnorodność dołączanych peryferii.
    Dodatkowo "daje rade" pisać w Delphi i już się pod tym kątem przygotowałem i ciągle przygotowuję żeby połączyć Delphi i AVR. Mam (i nawet go zdradzę) jeden całkiem nienajgłupszy myśle projekt: zawór turbiny w dieslu (czyli cisnienie doładowania) sterowany nie śrubką tylko silnikiem krokowym, dodatkowo położenie nastawnika pompy wtryskowej także sterowane przez atmege, a w silnikach wiadomo: paliwo+powietrze=moc, jak bedzie mozna tym sterować i dodatkowo bedzie można przeprogramowywać całość laptopem za pomocą programu (w delphi) to bedzie już pełen wypas. Np powiadomienie o przeładowaniu, czy niedoładowaniu przy określonych prędkościach obrotowych silnika. Mozna dorzucić czujnik temp (PT100) i badać temp turbiny i powiadamiać o jej przegrzewaniu. Coś tam jeszcze można dorzucić. Można podłączyć się pod czujnik temperatury silnika i jeśli jest zbyt zimny to atmega będzie otwierał zawór turbiny na maxa co uniemożliwi rozkrecenie się łopatek wirnika CZYLI zadbam w tym momencie o żywotność ułożyskowania takiego turba i takie tam duperele ;)

    PS
    Co do projektu to nie ma on na stałe zwiększać wartości cisnienia powietrza i paliwa a tylko w określonych okolicznościach czyli np po "żądaniu" kierowcy za pomocą przycisku. Sprawa jasna - chwilowy boost. W żadnym wypadku nie ma mowy o permamentnym ingerowaniu w oryginalne nastawy komputera auta. Auto ma służyć nie na ćwierć mili a tysiące kilometrów :)

    Co do tych STM'ów to pewnie spoko ale realia, czas, tzn brak czasu, wszystko na szybko, chyba wiemy o co chodzi :)

    Dobra, nie ma co bo wyszły z tego pogaduszki. Bardzo dziękuję za odpowiedzi. Temat można zamknąć chociaż pewnie trafi się kolejny dociekliwy któremu bedzie można kubełek zimnej wody wylać na głowę w dwóch zdaniach :D

    0