Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

przeniesienie programu z at90s2313 na attiny13

kukiz100 18 Sep 2006 12:04 3369 20
  • #1
    kukiz100
    Level 14  
    Witam. Napisałem program na at90s2313 (pilot do centralki alarmowej) i aby sprawdzić czy zawartość wszystkich zmiennych przy kodowaniu się zgadza wykorzystałem wbudowany uart. Kiedy wszystko się zgadzało wyłączyłem RS-a i przystosowałem program do attiny13 i... na tym skończyło się prawidłowe działanie programu. Czy ktoś wie czy w BASCOM-ie trzeba dodać jakieś dodatkowe instrukcje aby program działał na tym mikroprocku?? ustawiłem wewnętrzny rezonator 4.8Mhz, reset zewnętrzny działa, nie jest portem.
  • #2
    Bęben
    Level 16  
    W bascomie powinnes wybrac z listy swoj procesor, lub uzyc instrukcji do okreslenia typu procesora.
    Bo mysle ze uzadzenia zewnetrzne podlaczyles dobrze do pinow ukontrolera, i uwzgledniles to w programie
  • #3
    kukiz100
    Level 14  
    Wszystkie elementy zewnętrzne są podłączone prawidłowo. Najgorsze jest to, że typ procesora też jest w bascomie dobrze wybrany. Mimo wszystko program nie działa:(
  • #4
    bobbyAIR
    Level 20  
    widzisz w attiny jest maly kruczek dotyczacy dzialania timera ( nie pamietam ktorego ) odpowiedzialnego za dwa kanaly PWM - otoz nie jest prawda ze moga pracowac niezaleznie. A dokladniej drugi sterowany jes bitami sterujacymi od pierwszego czyi dwa piny zawsze pracuja identycznie. Zauwazylem to walczac kiedys nad wygenerowniem sobie sygnalow o okreslonej czesotliwosci ale przesunieych o 90 stopni. Skonczylo sie zmiana koncepcji
  • #5
    zbig_wwl
    Level 17  
    Z bascomem i attiny13 może być ciężko. Poczytaj https://www.elektroda.pl/rtvforum/topic579095-0.html

    Do bobbyAIR:
    akurat tiny13 ma 1 timer, a zrobienie tego o czym piszesz - dwa przebiegi o jednakowej częstotliwości przesunięte o 90 stopni to pięć linijek kodu w C i pewnie z 10 z asemblerze. Warunek - 50% wypełnienie przebiegu.
  • #6
    ucy74
    Level 20  
    Przestańcie pisać o timerach i PWM. Przecież autor nie podaje że ich używa w programie. Ja bym stawiał na stos programowy. Warto by go obadać w Bascomie dla ATtiny13
  • #7
    zbig_wwl
    Level 17  
    ucy74 wrote:
    Przestańcie pisać o timerach i PWM. Przecież autor nie podaje że ich używa w programie.

    Autor też nic nie pisze, że ich w programie nie używa :D , a chodzi o wykazanie różnic pomiędzy uC, bo tam czają się potencjalne problemy.

    ucy74 wrote:
    Ja bym stawiał na stos programowy. Warto by go obadać w Bascomie dla ATtiny13

    W linku, który podałem rozwiązanie polegało właśnie na odpowiednim ustawieniu parametrów związanych ze stosem.
    Problem polega właśnie na tym, że w at90s2313 było 128 bajtów sram'u a w attiny13 jest tylko 64. Domyślnie to bascom chyba 56 bajtów używa na stos i ramkę, więc zostaje 8 bajtów na dane :!: . W at 90s2313 zostawało jeszcze 72. Bascom dość rozrzutnie poczyna sobie ze sram'em i stąd te problemy.
    Uruchom sobie symulator w bascomie i popatrz, czy podczas symulacji nie wyświetla ci się komunikat "stack overlap" lub "frame overlap" czy cos takiego. Jeżeli się wyświetla, to znaczy, że właśnie wjechałeś z danymi na obszar zarezerwowany w sram'ie na stos i ramkę, a to właśnie powoduje, że program po wgraniu do uC nie działa.

    No i napisz, czy są jakieś postępy/nowe problemy :D przy uruchamianiu aplikacji i czy jeszcze potrzebujesz jakichś wskazówek :?:
  • #8
    kukiz100
    Level 14  
    Dzięki zbig_wwl. Pokombinuje z tym stosem. A co do PWM to faktycznie nie używam go bo i po co:) Pilot ma następujące zadanie: Po uruchomieniu włączone zostaje przerwanie int0. Po wciśnięciu przycisku zewnętrznego (dodane obwody eliminujące drgania styków) program wyłącza przerwanie int0, generuje zmienne na podstawie zawartości timera0. Następnie odblokowywane jest przerwanie od timera. Kiedy timer się przepełni, program wystawia na portb.4 uC kolejne bity zmiennych. Kiedy skończy to robić blokuje przerwanie od timera0 i odblokowuje int0 oraz przechodzi w tryb powerdown. Program działa poprawnie na większym uC jakim jest at90s2313. Muszę sprawdzić jeszcze czy działa na attiny 2313 ale myślę że są one tak podobne że to musi chodzić. Dzięki za każdą informację.
  • #9
    zbig_wwl
    Level 17  
    No cóż - właśnie przerwania i procedury niestety używają stosu. Jeżeli kod programu nie jest tajemnicą (ciąg generujący szyfr wstawisz i tak swój :D ) to wstaw go tutaj - łatwiej będzie coś przeanalizować.
    A tak poza tematem - nie polecam stosowania w alarmach stałego kodu - nigdy nie wiadomo, kiedy ktoś zainteresuje się naszą własnością :D
  • #10
    kukiz100
    Level 14  
    !!!Szok!!! przerwania zajmują AŻ 54 bajty ramu!!!. Muszę troche zmienić program i wszystko się ładnie zmieści ale musze przyznać, że byłem nieźle zaskoczony. Jutro sprawdzę czy wszystko działa. A co do kodu to nie jest on stały, wg moich obliczeń może wygenerować paredziesiąt tysięcy kombinacji:D Jeśli i ustawienie stosu nie pomoże to wrzucę listing na forum. Dzięki zbig_wwl
  • #11
    zbig_wwl
    Level 17  
    Z tym poprawianiem kodu to trzeba bardzo rozsądnie - tak naprawdę to im więcej masz zmiennych w pętli głównej programu, tym więcej zajmujesz sram'u przy wejściu do przerwania. Już dokładnie nie pamiętam, ale bascom przy wchodzeniu do obsługi przerwania "zapobiegawczo" odkłada zmienne na stos (w bascomie to jeszcze dodatkowo oprócz "prawdziwego" stosu występuje programowy i tzw. ramka). Jeżeli ten stos zajmuje ci 54 bajty, a w instrukcjach, które masz w przerwaniu też wykorzystywany jest sram (a w bascomie to na 99.9% jest :D ), to kłopot gotowy.

    Na małych AVR'ach da się naprawdę sporo zrobić - niestety nie w bascomie :cry: . Popatrz chociażby na moje projekty na http://elfly.pl/various/rainbow/rainbow.htm i http://elfly.pl/brush/brush.htm . Zrobiłem na nich jeszcze kilka innych i wszystko ładnie pracuje. attiny15 to nawet wogóle sramu nie ma a ten regulator silnika jak widzisz wykonuje jednocześnie sporo funkcji :-).
  • #12
    kukiz100
    Level 14  
    Nadal nie działa. Zmieniłem rozmiar stosu, symulator nie wskazuje problemów ale...stos zajmuje 54 bajty, zmienne kolejne 10-mam pełną pamięć ram. Najgorsze jest to, że pętla główna praktycznie nic nie robi. Sprawda tylko, czy dane zostały wysłane i wysyła procek do trybu powerdown (i to właśnie zajmuje 54 bajty:/ ). Co zrobić żeby bacom nie zajmował tyle ramu? Czy jest to jednoznaczne ze zmianą języka/kompilatora??Tak jak mówiłem dodaje plik z listingiem programu. Aha zapomniałem dodać, że program sprawdzałem przed chwilą na at90s2313 i tam nawet po zmianie rozmiaru stosu problemu nie ma.
  • #13
    kukiz100
    Level 14  
    Wpadłem na pewien pomysł a mianowicie dodałem klauzule NOSAVE przy definicji nazw procedur przerwania. Stos zmniejszył się znacznie ale mój program sam w sobie jest chyba "ramożerny" bo nadal nie działa (choć na większym bracie działa bez zarzutów:)
  • #14
    zbig_wwl
    Level 17  
    Po kolei:
    1. Jak używasz nosave, to musisz sam zadbać o odłożenie odpowiednich rejestrów na stos. Stos musi mieć wymiar ilości odkładanych bajtów +2 na program counter. W załączonym pliku dopisałem ci odpowiednie komendy. Sam musisz sprawdzić (symulator się kłania :D ), czy jeszcze coś powinno być odłożone. Z tego co pamiętam to bascom standardowo używa rejestrów indeksowych X,Y,Z i r4 oraz r24. Ponieważ w twojej pętli głównej prawie nic się nie dzieje, to może inne nie są używane :?:
    2. W tiny13 jest kilka trybów uśpienia. Domyślnie to jest tryb IDLE. jeżeli chodziło ci o inny tryb uśpienia, to zajrzyj do dokumentacji i ustaw odpowiednie bity w rejestrze MCUCR.
    3. Poprawiłem na szybko kilka linijek, żeby uprościć program - sam zobaczysz. Sprawdź, czy przypadkiem nie zmieniłem logiki programu.
  • #15
    ucy74
    Level 20  
    Jakim sygnałem wywołujesz przerwanie, zboczem czy poziomem?
    Nie masz skonfigurowanego przerwania więc jest default'owo wywoływane niskim poziomem. To dobrze, bo tylko taki poziom wybudzi Ci µC z powerdown.
    Nie pakuj wszystkich obliczeń w przerwania, raczej ustawiaj flagę, która powoduje wykonanie obliczeń w głównej pętli, przed uśpieniem µC.

    To takie pierwsze uwagi o kodzie.

    BTW jaki jest algorytm programu?
  • #16
    kukiz100
    Level 14  
    Tak wiem że musi być wywołane stanem niskim. A co do zmienionego programu to po co dodawać dodatkowe dyrektywy dla kompilatora? Przecież te informacje o rozmiarze stosu czy typie procesora ustawia się w oknie Bascoma? Nigdy nie bawiłem się w takie ręczne ustawienia dlatego mam jeszcze kilka pytań: Dlaczego zamiast komend "config port." odwołałeś się do rejestrów tych portów?? Czyżby te komendy czasem nie działały? Co znaczy "sei" przy konfiguracji timera? Dlaczego mam zmieniać rejestr MCUCR? Nie wystarczy wpisać powerdown? Wpisanie "SLEEP" ustawia bit MCUCR.5 jako 1? bo nie wiem za bardzo jak interpretować ten zapis?
  • #17
    zbig_wwl
    Level 17  
    To taki nawyk z C i asemblera :D . A poza tym to łatwiej manipulować rozmiarem stosu mając te informacje w programie, zamiast cały czas wchodzić w to okienko, gdzie to się zmienia. Jak podasz te informacje w programie to mają one priorytet nad tymi z okienka i tyle.
    Wgrywałeś ten program z moimi poprawkami do uC :?: Czy coś jest generowane na porcie wyjściowym :?: Jeżeli nie, to na początek w obsłudze przerwania INT0 wpisz tylko:
    
    do
       toogle portb.4
       wait 1
    loop 
    

    i zobaczysz, czy program wchodzi w obsługę i czy co sekundę zmienia się stan portu wyjściowego.
    ps. sprawdź składnię tego co napisałem, bo post piszę z komputera, na którym nie mam bascoma i napisałem z pamięci.

    To jeszcze dopiszę odpowiedzi na twoje pytania:
    1. Dlaczego zamiast komend "config port." - dla mnie po prostu prostszy i bardziej przejrzysty jest zapis ddrb i portb a poza tym wtedy wykonuje się to szybciej i mniej kodu generuje kompilator.
    2. Czyżby te komendy czasem nie działały? - zaprzestałem pisania w bascomie, bo aby jakiś większy program działał, to program w bascomie coraz bardziej upodabniał się do asemblera. Po prostu te dyrektywy bascomowe nie zawsze działają tak, jak sobie myślimy, że powinny :D
    3. sei to akurat to samo co enable interrupts
    4. Z tych samych powodów co podane w punkcie 2. Normalnie kompilator bascoma powinien tłumaczyć powerdown - sleep. oszczędziłem mu pracy :D.
    5. Dlaczego mam zmieniać rejestr MCUCR? W bascomie nie ma chyba ustawiania trybów uśpienia - domyślnie jest to idle. tinny13 ma jeszcze ADC noise canceler i powerdown. Co który faktycznie oznacza - odsyłam do dokumentacji uC. Jak nie ustawisz MCUCR to zostanie ustawienie domyślne, czyli IDLE. Nie jest to tryb, który najbardziej oszczędza energię.
    6. odnośnie MCUCR.5 to fakt - wisanie MCUCR.5=1 (lub=0 - trzeba zajrzeć do dokumentacji, który stan wyzwala przejście w stan uśpienia) lub powerdown lub sleep powinno powodować takie samo działanie
    Pozdrawiam
  • #18
    kukiz100
    Level 14  
    Jeszcze nie wgrywałem ale działać na pewno nie będzie bo ustawiłeś zewnętrzny zegar timera:D. Czyli mogę zostawić te komendy typu config port czy config timer0?? czy lepiej operować na rejestrach??
  • #19
    zbig_wwl
    Level 17  
    kukiz100 wrote:
    na pewno nie będzie bo ustawiłeś zewnętrzny zegar timera:D.

    :?: wydaje mi się, że ustawiłem clk/64 :?: - mógłbyś wyjaśnić swoją tezę :D

    kukiz100 wrote:
    Czyli mogę zostawić te komendy typu config port czy config timer0?? czy lepiej operować na rejestrach??

    Dla mnie na rejestrach jest wygodniej, ale to kwestia gustu po części, więc się nie upieram :D
  • #20
    kukiz100
    Level 14  
    Sprawdziłem i miałeś rację :) źle przeliczyłem wartoś (faktycznie jest kwarc/64) a co do rejestrów to okazuje się, że potrzeba wrzucić na stos rejesrtry: r0, r4, r17, r20, r24, r25, r26, r28 i r30. Niektóre np: r27 nie są używane (wg symulatora). Przy okazji odkryłem że jeśli ostatnim rejestrem odłożonym na stos jest np. r5 a zdejmowanie ze stosu zacznie się od innego to symulator wskazuje na przepełnienie stosu. Chciałbym mieć jeszcze jasność co do jednej rzeczy. Na stos muszę wrzucić wszystkie rejestry które mają jakąś wartość (czyli nie 0) w pętli głównej tak?? A co do trybu powerdown to myślę że komenda "powerdown" w bascomie działa :) i tego trybu nie trzeba ustawiać na rejestrach.

    Dodano po 44 [minuty]:

    lipa :/ Twój program nie działa, dodałem również tą pętlę sprawdzającą czy uC wchodzi w przerwanie i okazało się, że nie!!. Ustawiłem czas wait 2 żeby multimert pokazywał dokładniejsze stany portów i okazało się, że ciągle jest tam napięcie rzędu 0,2V czyli coś jest nadal nie tak;/ heh zaczyna mi odchodzić chęć pisania tego programu. Poza tym jak zwykle program na 90s2313 działa ;(
  • Helpful post
    #21
    zbig_wwl
    Level 17  
    Coś masz popsuty uC, bo właśnie wgrałem tę moją wersję do procka (do tiny13 dla jasności :D ) i dioda podpięta do pb.4 miga. Jak spowolniłem zegar do 128kHz to wyraźnie widać, że to mignięcie to w rzeczywistości jakiś kod, bo składa się chyba z ośmiu mrugnięć i przerw między nimi.
    Jak będzie działać i u ciebie, to jesteś mi winien piwo, przynajmniej wirtualne :D.
    Sciągnij z mojej strony (link wyżej) hex do sterowania diodą RGB i wrzuć go do uC. Podłącz miernik lub diodę pod jedno z wyjść i zobacz, czy modulowane jest napięcie/jasność diody. Ten program jest sprawdzony, więc jeżeli nie będzie u ciebie działał, to winny hardware.
    Odnośnie stanu uśpienia uC - zajrzałem do dokumentacji i jest tak, że dopóki nie ustawisz tego bitu SE (właśnie bit nr 5) w rejestrze MCUCR, to żadne tryby uśpienia nie działają. Nie sądzę, że bascom sam to robi, skoro nie ustawia się w nim trybu uśpienia.
    Algorytm generacji kodu sam opracowałeś, czy jest to jakiś ogólnie znany sposób :?: Jeżeli to ten drugi przypadek, to poproszę o jakiś namiar na inforamcje (tak z wrodzonej nieszkodliwej dla bliźnich ciekawości :D )
    Pozdrawiam

    ps. do skompilowania użyłem świeżo sciągniętego bascoma - zapomniałem zapytać jakiego ty używasz :?: