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

[Atmega8] [Atmega8][C] PWM nie działa na PB3, brak sygnału na porcie, kod w C

z3ro 06 Kwi 2012 16:45 2707 27
  • #1 10764053
    z3ro
    Poziom 10  
    Witam, napisałem prosty kod do generowania częstotliwości i niestety na porcie głucha cisza, przeleciałem wiele tematów ale nie potrafię sobie z tym poradzić. Bardzo proszę o waszą pomoc.
    Kod C

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Pozdrawiam
  • #2 10764425
    mirekk36
    Poziom 42  
    No tak pomyliły mi się procki jakoś spojrzałem na ATmega32 zamiast na ATmega8 o którą pytasz - ale już moderator ciachnął to.

    W takim razie co to znaczy że ci nie działa - może napisz coś więcej.....

    Poza tym zmniejsz preskaler i to znacznie - bo może po prostu miga ci ta dioda podłączona do PWM

    aha - no i czy zmieniłeś ustawienia Fusebitów z Fabrycznego taktowania 1MHz na zewn kwarc 12MHz - jak wynika (z błędnego zresztą) wpisu w twoim kodzie #define F_CPU

    Tzn sam wpis jest prawidłowo zrobiony - ale tak się tego nie stosuje :(
  • #3 10764691
    z3ro
    Poziom 10  
    Nie działa wcale, fuse są zmienione na 12MHz, do kompilacji dodana jest opcja -D12000000UL a w kodzie tylko po to żeby żeby się biblioteka <util/delay.h>, pwm na timerze2 nie działa wcale, znaczy na wyjściu jest poprostu 0. Preskaler też jest ok bo chodziło i niewielką częstotliwość żeby buzzerek do testu wysterować. tam wychodzi niecałe 400Hz. 12Mhz/(64*510). gdzie 64 to preskaler
  • #4 10764824
    xamrex
    Poziom 28  
    Nie wiem czy to cały kod, ale brakuje chyba sei(); ?
  • #5 10764853
    gaskoin
    Poziom 38  
    Po grzyba sei jak nie ma nigdzie przerwań.
  • #6 10764985
    z3ro
    Poziom 10  
    Dodam jeszcze że na timerze 1 PWM działa ok.
  • #7 10765243
    mirekk36
    Poziom 42  
    z3ro napisał:
    Nie działa wcale, fuse są zmienione na 12MHz, do kompilacji dodana jest opcja -D12000000UL


    No to błąd - bo ma być -DF_CPU 12000000

    a nie jakieś -D12000000UL

    to po pierwsze, i dlatego właśnie w kodzie źle działa ci to delay i dlatego bez sensu dopisujesz w kodzie to #define F_CPU .... wiem co mówię.... Gdybyś zrobił tak jak wyżej napisałem to w kodzie nie trzeba robić #define F_CPU

    z3ro napisał:
    Preskaler też jest ok bo chodziło i niewielką częstotliwość żeby buzzerek do testu wysterować. tam wychodzi niecałe 400Hz. 12Mhz/(64*510). gdzie 64 to preskaler



    no ciekawe a w kodzie masz ustawiane 3 bity: (1<<CS20)|(1<<CS21)|(0<<CS22) czyli preskaler 1024

    a skoro tyle błędów to jeszcze może gdzieś jest jakiś - np w połączeniach ? albo coś
  • #8 10765666
    sulfur
    Poziom 24  
    No właśnie nie. Zauważ mirekk36, że przy CS22 jest zero. Czy autor tematu jest w stanie sprawdzić na oscyloskopie, że pin mikrokontrolera w trybie PWM nie działa na prawdę za pomocą oscyloskopu ?
  • #9 10765699
    mirekk36
    Poziom 42  
    sulfur napisał:
    No właśnie nie. Zauważ mirekk36, że przy CS22 jest zero. Czy autor tematu jest w stanie sprawdzić na oscyloskopie, że pin mikrokontrolera w trybie PWM nie działa na prawdę za pomocą oscyloskopu ?


    No tak! i nie tylko przy CS22 jest zero ale także przy WGM jest zero - no tego się nie spodziewałem bo tak się nie pisze ;) nawet tam moje oko nie poleciało ;)

    Dodano po 2 [minuty]:

    Łeeee no teraz to ja jeszcze więcej tych DZIWNYCH - ZER zobaczyłem - bingo kolego Sulfur ;)

    Przecież nawet tryb FastPWM nie jest ustawiony tylko CTC

    więc jak ma działać PWM na OC2 ????

    Tak to jest jak się w ten sposób pisze programy :( ..... ta dziwna linijka:

    TCCR2|=(1<<WGM20)|(0<<WGM21)|(1<<CS20)|(1<<CS21)|(0<<CS22)|(0<<COM20)|(1<<COM21);

    powinna w kodzie wyglądać tak:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #10 10766516
    z3ro
    Poziom 10  
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Specjalnie dla kolegi mirka zapisałem tą linijkę w sposób dla niego czytelny, nie jest to jak widać tryb CTC tylko PWM z phase correct. I mogę spradzić na oscyloskopie i pin jest głuchy, a zera są dlatego że próbowałem różnych trybów i szybciej było mi zmieniać "0" na "1" i na odwrót niż dopisywać za każdym razem kilka nowych znaków. Nie wiedziałem że będą takie problemy z zauważeniem tych zer;p
  • #11 10766590
    sulfur
    Poziom 24  
    A odłączasz programator po zaprogramowaniu układu ?
  • #13 10766771
    z3ro
    Poziom 10  
    Mikrokontroler działa prawidłowo, znaczy nie zauważyłem problemów nie licząc tego PWM, a jeżeli chodzi o programator to będzie to kłopotliwe bo programator zasila mi układ. Ale spróbuję coś pokombinować
  • #14 10766785
    mirekk36
    Poziom 42  
    z3ro napisał:
    Specjalnie dla kolegi mirka zapisałem tą linijkę w sposób dla niego czytelny, nie jest to jak widać tryb CTC tylko PWM z phase correct.


    Bardzo dziękuję, i przepraszam że jestem takim dyslektykiem wzrokowym .... teraz łatwiej mi czytać....

    No więc jeśli teraz twój kod wygląda tak?:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    to powinien PWM ładnie śmigać ..... chyba że coś jest źle podłączone ?
  • #15 10766802
    gaskoin
    Poziom 38  
    mirekk36 napisał:

    powinna w kodzie wyglądać tak:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Dla oszczędzenia kilku bajtów można też tak:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #16 10766811
    sulfur
    Poziom 24  
    Chodzi o to, że na PB3 razem z OC2 jest MOSI. Teraz pozostaje tylko pytanie, czy problem z generowaniem impulsu, a w zasadzie ze zmianą poziomu na porcie wynika z tego, że programator wymusza inna stan i układ. Koledzy mirekk36 i dondu mają większe doświadczenie, może coś podpowiedzą.
  • #17 10766824
    dondu
    Moderator na urlopie...
    sulfur napisał:
    Chodzi o to, że na PB3 razem z OC2 jest MOSI. Teraz pozostaje tylko pytanie, czy problem z generowaniem impulsu, a w zasadzie ze zmianą poziomu na porcie wynika z tego, że programator wymusza inna stan i układ. Koledzy mirekk36 i dondu mają większe doświadczenie, może coś podpowiedzą.

    Twoja uwaga dot. programatora może być bardzo istotna.
  • #18 10766941
    z3ro
    Poziom 10  
    Oczywiście mirekk bez urazy:) Trochę poprostu męczące jest jak kilka razy wytykasz mi błąd którego nie ma:P
  • #19 10767050
    mirekk36
    Poziom 42  
    z3ro napisał:
    Oczywiście mirekk bez urazy:) Trochę poprostu męczące jest jak kilka razy wytykasz mi błąd którego nie ma:P


    No jeśli dla ciebie przejrzyste pisanie kodu to nie błąd, to jeszcze raz bardzo przepraszam i już nie będę w tym zakresie (stylu pisania kodu) nic podpowiadał żeby nie męczyć.

    Dodano po 6 [minuty]:

    sulfur napisał:
    Chodzi o to, że na PB3 razem z OC2 jest MOSI. Teraz pozostaje tylko pytanie, czy problem z generowaniem impulsu, a w zasadzie ze zmianą poziomu na porcie wynika z tego, że programator wymusza inna stan i układ. .


    Wprawdzie nie wiemy jaki programator ma autor, ale generalnie programatory powinny i w zasadzie wszystkie to robią, czyli pozostawiają linię MOSI w stanie Hi-Z po zakończeniu operacji programowania. Poniżej pokażę jak wygląda to w kodzie np programatora USBASP, więc z takim programatorem to na 100% nie powinno być problemem to że jest MOSI podpięte do układu:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    ale myślę że w innych programatorach też .... bo nawet jeśli maja bufory na wyjściu to także 3-stanowe i z wymuszonym trzecim stanem wysokiej impedancji na wyjściu po zakończeniu programowania ....
  • #20 10767580
    z3ro
    Poziom 10  
    Mam właśnie USBAsp więc nie powinno być problemu... wymienię jeszcze proca, może jest sam w sobie uszkodzony... Dziękuję za poświęcenie czasu.
  • #21 10767602
    mirekk36
    Poziom 42  
    z3ro napisał:
    Mam właśnie USBAsp więc nie powinno być problemu... wymienię jeszcze proca, może jest sam w sobie uszkodzony... ....


    Ja mogę się założyć, że nie jest uszkodzony ;)
  • #22 10781704
    Ostry23
    Poziom 18  
    mirekk36 napisał:
    Ja mogę się założyć, że nie jest uszkodzony

    A ja bym nie był taki pewien, bo upalenie portów się zdarza... rzadko, ale może.
    Zdarzyło mi się raz parę lat temu przy skonfigurowaniu jakiegoś pinu jako wyjście i podpięcie go do wyjścia czegoś innego. Szczegółów nie pamiętam, dopiero zaczynałem programować uC wtedy... pamiętam tylko, że zdziwiło mnie że padło bodajże pół portu a nie cały albo tylko 1 pin.
    Tzn. sam CPU działał poprawnie i wszystkie peryferia oprócz tego portu też, ale przestawianie linii tego portu już nie.
    Jeśli z3r0 miał coś wcześniej źle skonfigurowane na sąsiednich pinach, to może jego PORTB już nie żyje.
    Zgadzam się, że to mało prawdopodobne... i najprościej to sprawdzić komentując na szybko kod od PWM i po prostu wystawiając stan na linie portu B.

    No tak, po namyśle stwierdzam, że uszkodzenie portu jest faktycznie b. mało prawdopodobne, bo koledze działa programowanie uC, które przecież wykorzystuje te same piny.
    Ja w kodzie kolegi z3r0 też żadnego błędu nie widzę.
  • #23 10781824
    mirekk36
    Poziom 42  
    Ostry23 napisał:
    mirekk36 napisał:
    Ja mogę się założyć, że nie jest uszkodzony

    A ja bym nie był taki pewien, bo upalenie portów się zdarza... rzadko, ale może.


    Może to się wszystko zdarzyć..... Tylko doszukiwanie się na samym początku fizycznego uszkodzenia procka albo co lepsze jego wady lub niedopatrzenia producenta - zamiast swojego błędu - to takie typowe. 99,99% tego typu przypadków, jak poczytać sobie to forum kończy się zwykle tak samo, np:

    Cytat:
    "wczoraj poskładałem, układ od nowa i wszystko zaczęło działać - nawet nie wiem dlaczego"


    albo:

    Cytat:
    "okazało się, że podstawka w której siedział układ nie stykała w płytce stykowej, piszę to dla potomnych żeby wiedzieli co zrobić w takiej sytuacji"


    I tego typu porad dla potomnych jest najwięcej niestety :(

    Ostry23 napisał:
    i najprościej to sprawdzić komentując na szybko kod od PWM i po prostu wystawiając stan na linie portu B.


    Od tego trzeba było zacząć....

    bo niestety opowieści o tym co to mi się kiedyś dawno temu przydarzyło - właśnie powodują wśród początkujących od razu takie odruchy. Jak coś nie działa to pewnie pin upalony, albo procek, albo wadliwy procek - bo ktoś na forum pisał że też coś takiego miał.

    Dodano po 6 [minuty]:

    Ostry23 napisał:

    Zdarzyło mi się raz parę lat temu przy skonfigurowaniu jakiegoś pinu jako wyjście i podpięcie go do wyjścia czegoś innego. Szczegółów nie pamiętam, dopiero zaczynałem programować uC wtedy... pamiętam tylko, że zdziwiło mnie że padło bodajże pół portu a nie cały albo tylko 1 pin.


    Pewnie, że w taki sposób można załatwić pojedyncze piny - to nie dziwne i masz rację.... Tylko zauważ że tu o czym innym mowa - nie wspominając już jak szybko sam doszedłeś w trakcie pisania postu, że mowa o pinie wykorzystywanym chociażby do programowania - nie mówiąc już o prostej metodzie sprawdzenia tego czy działa czy nie - nawet jeśli byłby to inny pin.
  • #24 10781852
    Ostry23
    Poziom 18  
    Mirek, napisałeś
    mirekk36 napisał:
    Ja mogę się założyć, że nie jest uszkodzony
    a mi chodziło o to, że ja bym się tak kategorycznie nie zakładał. Bo się zdarza. Po czym zresztą napisałem, że to mało prawdopodobne. Chodziło mi tylko o to, że stuprocentowo pewien nie możesz być. I to jest fakt.
    Ale skoro wszyscy tu szukaliście błędu w kodzie kilkulinijkowym i nikt nic nie znalazł, to znaczy, że albo jest to zbiorowe zamroczenie i jakiś głupi błąd, który umyka, albo nam autor wątku wszystkiego nie mówi, albo rzeczywiście jest to błąd sprzętu (było już zresztą podejrzenie, że może programator nie zwalnia linii MOSI po skończeniu programowania i zdjęciu resetu). I tyle.

    Wiem, że temat uświadamiania początkujących w kwestii zasilania uC a także wkładania im do głowy, że to nie procek ani kompilator ma błąd, to twój konik, bo co drugi twój post jest na ten temat, ale pozwól czasem wypowiedzieć się w innym duchu... zwłaszcza, że to nie neguje wagi dobrego zrobienia zasilania ani konieczności szukania błędu w pierwszej kolejności w swoim programie, schemacie czy layoucie.

    mirekk36 napisał:
    bo niestety opowieści o tym co to mi się kiedyś dawno temu przydarzyło - właśnie powodują wśród początkujących od razu takie odruchy. Jak coś nie działa to pewnie pin upalony, albo procek, albo wadliwy procek - bo ktoś na forum pisał że też coś takiego miał


    Niemniej jednak uszkodzić port nie uszkadzając samego CPU można. I to jest fakt, a z faktami kłócić się nie należy :).
    Ja nie wiem jakie odruchy to co napisałem powoduje u początkujących, nie jestem w ich głowach, nie mam szerokasmowego łącza do ich mózgów. Staram się pisać o faktach a nie o domysłach.

    Dodano po 11 [minuty]:

    mirekk36 napisał:

    Ostry23 napisał:
    i najprościej to sprawdzić komentując na szybko kod od PWM i po prostu wystawiając stan na linie portu B.


    Od tego trzeba było zacząć....


    No właśnie. Może poczekajmy na autora i proponuję, żeby się wprost wypowiedział jaką metodą stwierdza, że PWM nie działa. Niby w którymś poście był wspomniany oscyloskop, ale jakoś nie mam jasności.
    Jak stwierdzasz, że na porcie nic się nie dzieje?
  • #25 10781986
    mirekk36
    Poziom 42  
    Pewnie , że można uszkodzić piny - pisałem że się z tym zgadzam ;) ..... tylko jeszcze raz powtarzam, jestem gotów się zakładać w takich przypadkach a szczególnie w tym przypadku i to tyle .... (nikomu swoim zakładem nie miałem zamiaru udowadniać tego czego nie powiedziałem, czyli tego że do takich udzkodzeń może dojść - tyle że one są zbyt oczywiste żeby tyle czasu ich szukać ;)

    Dodano po 4 [minuty]:

    Ostry23 napisał:

    Wiem, że temat uświadamiania początkujących w kwestii zasilania uC a także wkładania im do głowy, że to nie procek ani kompilator ma błąd, to twój konik, bo co drugi twój post jest na ten temat, ale pozwól czasem wypowiedzieć się w innym duchu...


    Hej hej a komu ja tu mogę czegoś nie pozwalać ? ;) .... przesadzasz i to mocno. Jeśli nie podoba ci się mój co drugi post jak mówisz - to sam pisz ich więcej - nie wiem co cię gryzie - sorry :(

    A co - nie wypowiedziałeś się w innym duchu ? A co - ja nie mogę się wypowiedzieć ?

    Tym bardziej, że też nie neguję twoich wypowiedzi - po prostu dyskutuję .... to wszystko.
  • #26 10782077
    Ostry23
    Poziom 18  
    Ostry23 napisał:
    Wiem, że temat uświadamiania początkujących w kwestii zasilania uC a także wkładania im do głowy, że to nie procek ani kompilator ma błąd, to twój konik, bo co drugi twój post jest na ten temat, ale pozwól czasem wypowiedzieć się w innym duchu... zwłaszcza, że to nie neguje wagi dobrego zrobienia zasilania ani konieczności szukania błędu w pierwszej kolejności w swoim programie, schemacie czy layoucie


    mirekk36 napisał:
    przesadzasz i to mocno. Jeśli nie podoba ci się mój co drugi post jak mówisz - to sam pisz ich więcej


    Błąd interpretacji. Czy gdziekolwiek napisałem, że nie podoba mi się twój co drugi post? Napisałem coś zgoła innego :). Zresztą, nie wiem jak ty, ale ja nie chcę brnąć w żadne flame-wars. Szkoda czasu, wolę się skupić na merytoryce.
  • #27 10782181
    mirekk36
    Poziom 42  
    Ostry23 napisał:

    Błąd interpretacji. Czy gdziekolwiek napisałem, że nie podoba mi się twój co drugi post? ...... Zresztą, nie wiem jak ty, ale ja nie chcę brnąć w żadne flame-wars.


    Ja wprawdzie nie wiem co to te flame- coś tam - ale się domyślam - i też nie chcę. Tak czy inaczej wystarczy, że autor skorzysta właśnie z twojej słusznej porady - jak sprawdzić sobie ten pin - czy jest uszkodzony czy nie - i już będzie miał odpowiedź ;)
  • #28 10782422
    Ostry23
    Poziom 18  
    mirekk36 napisał:
    Ja wprawdzie nie wiem co to te flame- coś tam - ale się domyślam - i też nie chcę

    No to mamy zgodę :). A co do flame-wars: http://pl.wikipedia.org/wiki/K%C5%82%C3%B3tnia_internetowa

    A tu na wesoło: http://www.collegehumor.com/video/3980096/we-didnt-start-the-flame-war

    z3r0, teraz czekamy na twoją odpowiedź.
REKLAMA