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

[Rozwiązano] Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

AttA91 19 Mar 2022 11:13 1149 33
  • #1 19938332
    AttA91
    Poziom 7  
    Witam.
    Potrzebuje kilku porad co do avr. Rozwikłania kilku zagwozdek.

    Zestaw:
    -podstawka TEXTOOL, DIP-40
    -programator chiny, usbasp (bez slow sck)
    -eclipse
    -atmega16A - PU
    -brak zew. kwarcu

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


    czyli czyste miganie diodą. I teraz tak:
    -nie dotykałem fusebitów
    -mogłem jakiś czas temu (lekko ponad rok) na odwrót wsadzić AVR do podstawki, czego oznaką była wysoka temperatura procesora.

    Zacząłem działać znów. Udało mi się nawiązać połączenie z programatorem i procesorem. Są odczytywane. Nie do końca jednak rozumiem zależności częstotliwości, do tego ten slow sck... Nie ważne. Program jakby się wgrywa, ale w ogóle nie reaguje na komendę 'delay'. Jakiej wartości bym nie wpisywał to dioda mruga tak samo (raczej przypadek, że w ogóle działa miganie. Na porcie PA0, kompilowałem i wgrywałem taki sam kod, ale reakcja jest 'stała', podaje napięcie cały czas. PA2 i wyżej nie działają w ogóle.

    I teraz jestem w stanie zmieniać częstotliwość świecenia diody, kiedy przy wybieraniu project>properties>avr>target hardware i zmiana MCU clock freq na inną wartość zmienia działanie diody na porcie PA1.

    Morał taki, że programator reaguje, procesor jakoś też reaguje, ale kompletnie nie dzieje się tak jakbym chciał.

    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

    Pozdrawiam.
  • #2 19938624
    StaryVirus_e_Wiarus
    Poziom 21  
    Cześć
    Jak twierdzisz, że fusów nie ruszałeś i coś się wgrało do procesora, to spróbuj:
    1. W Eclipse we właściwościach projektu, zmień częstotliwość MCU na wartość : 1000000. (1MHz) Na tę częstotliwość najczęściej są ustawione fabrycznie.
    2. Skompiluj ponownie projekt i wgraj go do procesora.
  • #3 19938663
    AttA91
    Poziom 7  
    Tak, wiem, że fabrycznie przeważnie jest 1MHz (jak wspomniałem, zamiana ta, działa na diodę, miga w innej częstotliwości). Również próbowałem. Układ nie reaguje na zmianę delay'a.

    A to jest odpowiedź na kod (uruchomienie PA2):
    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

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


    Układ nie uruchamia diody na PA2.
  • #4 19938701
    StaryVirus_e_Wiarus
    Poziom 21  
    Przy prawidłowym ustawieniu fusów (1MHz) i częstotliwości MCU na 1MHz, zastosowana LEDa z rezystorem szeregowo, na porcie PA1 (wg programu, post #1) powinna mrugać co 5 sekund.
    Miernika nie ma co używać (mierząc napięcie), bo on przetwarza z opóźnieniem i ciężko coś porównać.
    Częstotliwość MCU jest sercem. Powinna być ustawiona na stałe. Zmieniać tylko wartości _delay _ms(XXXXXX).
    Warto spróbować przy tym samym ustawieniu delaya, zmienić częstotliwości MCU na 2MHz, 8MHz. Może procesor miał zmieniane fusy?
    I oczywiście za każdym razem koniecznie skompilować i wgrać program do procesora.

    Dodano po 2 [minuty]:

    Przy 100ms nie zauważysz migania diody LED
  • #5 19938741
    AttA91
    Poziom 7  
    Dochodzę do wniosku, że nie obędzie się chyba bez kupna nowego AVR. Przy okazji kupiłbym atmege8, bo odblokowana jest na mkavrcalculator.

    StaryVirus_e_Wiarus napisał:
    Przy prawidłowym ustawieniu fusów (1MHz) i częstotliwości MCU na 1MHz, zastosowana LEDa z rezystorem szeregowo, na porcie PA1 (wg programu, post #1) powinna mrugać co 5 sekund.

    Jak ustawie MCU na 5MHz to świeci co 5s.
    StaryVirus_e_Wiarus napisał:
    Częstotliwość MCU jest sercem. Powinna być ustawiona na stałe. Zmieniać tylko wartości _delay _ms(XXXXXX).

    Dlatego napisałem na forum. Wiem, że nie o to chodzi żeby ustawiać częstotliwość migania diody w MCU. Doświadczeni może coś zobaczą więcej niż ja.
    StaryVirus_e_Wiarus napisał:
    Warto spróbować przy tym samym ustawieniu delaya, zmienić częstotliwości MCU na 2MHz, 8MHz.

    Próbowałem.
    StaryVirus_e_Wiarus napisał:
    Może procesor miał zmieniane fusy?

    Raczej nie. Ja tego nie robiłem (chyba, nie pamiętam co w nim grzebałem jak i tak nie udało mi się uzyskać efektów), a procesor na 100% kupiony był w jakimś sklepie internetowym. Albo elektronicznym w okolicy.
    StaryVirus_e_Wiarus napisał:
    I oczywiście za każdym razem koniecznie skompilować i wgrać program do procesora.

    Pilnuje tego.
    StaryVirus_e_Wiarus napisał:
    Przy 100ms nie zauważysz migania diody LED

    Poprawione na 1000ms. Brak świecenia diody. Przypominam, że programując port PA1, delay równiez nie działa.
  • Pomocny post
    #6 19938753
    tmf
    VIP Zasłużony dla elektroda
    Jeśli program reaguje na zmiany F_CPU, a nie reaguje na zmianę parametru _Delay_ms to jest to mega dziwne. Jesteś pewien, że kompilujesz właściwy plik?
    Ustawienia fusebitów nie mają znaczenia, bo jeśli program działa, to niezależnie od wybranego zegara zmiana parametru delay musi wpłynąć na okres świecenia diody.
    Natomiast mnie niepokoi pewna niespójność twojej relacji:
    AttA91 napisał:
    Brak świecenia diody. Przypominam, że programując port PA1, delay również nie działa.

    To w końcu to działa, czy nie?
    AttA91 napisał:
    Dochodzę do wniosku, że nie obędzie się chyba bez kupna nowego AVR. Przy okazji kupiłbym atmege8, bo odblokowana jest na mkavrcalculator.

    Kupno nowego MCU niezależnie, czy uda ci się to odpalić, czy nie i tak jest najlepszym pomysłem. Jeśli się przegrzał, bo mu odwrotnie podłączyłeś zasilanie to kompletnie nie ma gwarancji co z nim dalej będzie. IMHO szkoda tracić czas i lepiej go wyrzucić.
    Tak BTW, jeśli nie masz ciągotek muzealnych, to dlaczego nie kupisz jakiegoś nowszego AVR? Zamiast korzystać z jakiegoś AVR dude kup sobie płytkę eXplained mini, albo curiosity nano - będziesz miał nowszy procesor i w dodatku wbudowany programator/debugger. Ten drugi od razu by pozwolił ci ustalić co jest grane.
  • #7 19938772
    AttA91
    Poziom 7  
    tmf napisał:
    Jeśli program reaguje na zmiany F_CPU, a nie reaguje na zmianę parametru _Delay_ms to jest to mega dziwne.

    Zawsze mam takie szczęście :D.
    tmf napisał:
    AttA91 napisał:
    Brak świecenia diody. Przypominam, że programując port PA1, delay również nie działa.

    To w końcu to działa, czy nie?

    delay_ms nie działa, natomiast zmiana MCU reaguje na częstotliwość migania diody. Sama dioda miga. Chodziło o to, że PA2, w ogóle nie da się zaprogramować, czyli tak jak ten delay nie reaguje na PA1.
    tmf napisał:
    Tak BTW, jeśli nie masz ciągotek muzealnych, to dlaczego nie kupisz jakiegoś nowszego AVR?

    Mam arduino i maline - nie korzystałem. Nie wiem, mam ochotę ugryźć temat od samego dna. Nie wiem po co. Sądze, że "po coś" to może mi się przydać, choćby zrozumieć avr'y od początku. Czytam, oglądam filmiki nt. avr (rejestry, budowa, działanie). Żeby to zrozumieć, chce mieć dostęp do avr do każdej nóżki i osobno znać zasade działania każdej z nich (od znaczenia, opisu, po działanie komunikacyjne). Mam solidne podstawy żeby w końcu to wszystko "pojąć". Poza tym również interesuje się cyberbezpieczeństwem. Może mi ta wiedza w jakiś sposób pomóc. Już zakładając temat i czytając odpowiedzi wnioskuje, na przykład to:
    StaryVirus_e_Wiarus napisał:
    Przy prawidłowym ustawieniu fusów (1MHz) i częstotliwości MCU na 1MHz

    Już budzi się pewne upewnienie w części, która nie do końca jest jasna dla mnie, czyli "częstotliwości" w tym przypadku wewnętrznego taktowania procesora (czyli 1MHz na fusach). MCU to programowe ustawienie częstotliwości programatora. Chyba dobrze to rozumiem? Tak przy okazji się upewniam :P.

    Czy taka "ATmega-8535-16PU DIP-40" atmega8 podejdzie mi pod podstawkę. Pytanie czy z reguły programy czytają taki model jako 8, czy n'tą osobną odmianę? czy potrzebne raczej coś w stylu "ATmega-8-16PU DIL-28W" i płytka stykowa?
  • Pomocny post
    #8 19938812
    StaryVirus_e_Wiarus
    Poziom 21  
    Ustawienia MCU nie dotyczą programatora, jego lepiej nie ruszaj. Częstotliwość MCU to ustawiona wartość we właściwościach projektu(F_CPU), by wskazać na podstawie ustawionych fusów, jaką częstotliwość ma przyjąć Twój program i procesorek (nie programator) do działania. Stąd ma między innymi dane do właściwego działania delay.
    Zapomnij o ATmega8535, to starocie i jeszcze więcej kłopotów.
    Zapomnij o życiowej porażce MK.

    Dodano po 1 [minuty]:

    Eclipse posiada wszystko co Ci potrzeba
  • #9 19939074
    AttA91
    Poziom 7  
    Dobrze, dziękuję Panowie za odpowiedzi. W poniedziałek kupie nową atmege16. Dam znać jakie efekty.
  • #10 19940430
    Janusz_kk
    Poziom 38  
    Ja cały czas podejrzewam że ci nie chodzi to f_cpu, wpisz w program taką linię, tu masz całość
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    A delay-a wystarczy dać na sekundę. Zobacz jak teraz ten program Ci pójdzie
  • #11 19940565
    AttA91
    Poziom 7  
    Niestety. Nic to nie zmieniło. Zmiana wartości w _delay_ms(x) nie zmienia częstotliwości migania diody. Niezależnie czy to 100ms, 500, 5000, 10k, 100k.
  • #12 19940646
    gps79
    Poziom 35  
    źle.
    #define F_CPU 1000000UL
    musi być ustalone przed linią
    #include <util/delay.h>
    bo inaczej dostałbyś warning kompilatora:
    # warning "F_CPU not defined for <util/delay.h>"

    Spójrz w źródła pliku WinAVR\avr\include\util\delay.h, aby się przekonać, że makro F_CPU musi być zdefiniowane:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    Jeśli jednak nie ustaliłeś ręcznie F_CPU i ten warning nie występował, to oznacza, że gdzieś indziej F_CPU zostało zdefiniowane (może w IDE?).
    Gdy robisz testy i zmieniasz częstotliwość, zmień nieco również algorytm (np. 1s świeci, 2s zgaszona). Będziesz miał pewność, że wgrałeś najnowszy HEX.
    No i F_CPU powinno być takie samo, jak rzeczywisty zegar (ustawiony fusebitami czy zewnętrznym oscylatorem/kwarcem).
  • #13 19940659
    Janusz_kk
    Poziom 38  
    gps79 napisał:
    #define F_CPU 1000000UL
    musi być ustalone przed linią
    #include <util/delay.h>

    Nie musi, biblioteka jest ładowana dopiero w momencie wywołania funkcji.
    Może do programowania użyj SinaProg 2.1, działa na avrdude i działa dobrze.
    https://sinaprog.software.informer.com/2.1/
  • #14 19940691
    gps79
    Poziom 35  
    Janusz_kk napisał:
    Nie musi, biblioteka jest ładowana dopiero w momencie wywołania funkcji.
    to chyba nie w C/C++, czyli nie tu.
  • #15 19940701
    Janusz_kk
    Poziom 38  
    No ok, chyba w 4 tak było.

    Dodano po 1 [minuty]:

    AttA91 napisał:
    Niestety. Nic to nie zmieniło. Zmiana wartości w _delay_ms(x) nie zmienia częstotliwości migania diody. Niezależnie czy to 100ms, 500, 5000, 10k, 100k.

    Spróbuj teraz.

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

    No i sprawdź czy właściwy plik hex ładujesz do programamtora.
  • #16 19940842
    AttA91
    Poziom 7  
    Dlaczego miałbym wskazać zły hex? Wiem, pod jaką nazwą projekt kompiluje i gdzie się on znajduje.

    Próbowałem używać sinaprog, wskazując plik hex i faktycznie coś się podziało. LED zaczął mrugać inaczej. Przy wgrywaniu programu z eclipse z innym delayem, przestał całkowicie mrugać. Co do błędu przy zmianie położenia _delay_ms(x) nie pojawiał się żaden nowy.
    Dodatkowo chyba uszkodziłem flash na atmedze :D .

    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

    Przy okazji jeszcze zadam pytanie, jak odróżnić te częstotliwości, jak są od siebie zależne? trochę ich jest.
    1.F_CPU
    2.Częstotliwość MCU
    3.Częstotliwość fusebitów (domyślam się, że chodzi o wszystkie, czyli High i Low - z tego co widziałem są to rejestry 1 bajtowe.)
    4.Kwestia zewnętrznego kwarcu
  • #17 19940933
    Janusz_kk
    Poziom 38  
    AttA91 napisał:
    Dodatkowo chyba uszkodziłem flash na atmedze .

    Zrób w sinaprog odczyt do pliku, zobacz co przeczytał, jak będzie błąd to wejdź w 'advanced' i zrób chip erase, i spróbuj zaprogramowac.

    Dodano po 2 [minuty]:

    1 i 2 i4 to to samo częstotliwość procesora (mcu) ustawiasz kwarcem lub wybierasz fusami z kilku opcji, potem wg tego ustawiasz stałą w programie F_CPU.
    3 tego sie nie zmienia, ustawia to program zapisujący, domyślne jest dobre.
  • #18 19940981
    AttA91
    Poziom 7  
    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp
    Hex odczytany z flash. Przeszło pomyślnie.
  • #19 19940985
    Janusz_kk
    Poziom 38  
    A programuje się?

    Dodano po 37 [sekundy]:

    Zrób profilaktyczny chip erase.
  • #20 19940994
    AttA91
    Poziom 7  
    Janusz_kk napisał:
    A programuje się?

    LED nie reaguje na nic jeśli o to pytasz. Tak to procesor jest widoczny.
    Janusz_kk napisał:
    Zrób profilaktyczny chip erase.

    Niby robię, ale trwa i trwa...

    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

    Janusz_kk napisał:
    1 i 2 i4 to to samo częstotliwość procesora (mcu) ustawiasz kwarcem lub wybierasz fusami z kilku opcji, potem wg tego ustawiasz stałą w programie F_CPU.
    3 tego sie nie zmienia, ustawia to program zapisujący, domyślne jest dobre.


    Jeszcze jest:
    5.Slow sck
    6.SCK frequency
  • #21 19941037
    Janusz_kk
    Poziom 38  
    Wyłącz załącz i spróbuj jeszcze raz skasować.
  • #22 19941063
    AttA91
    Poziom 7  
    Resetowanie/wlaczenie/wylaczenie zasilania nie zmienia efektu. Trwa i trwa...

    Przy wyłączeniu procesu sinaprog:
    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp

    EDIT: Jutro kupię nowy. Postaram się nic nie zepsuć na starcie :D. Dziękuję za chęci i w zasadzie sporą dawkę wiedzy.
  • Pomocny post
    #23 19941085
    Janusz_kk
    Poziom 38  
    Czyli masz procek uszkodzony.
  • #24 19941215
    StaryVirus_e_Wiarus
    Poziom 21  
    Z fusów jakie są ustawione (fot. post #20) wynika, że powinno być F_CPU = 1000000. Nie potrzebny w tej sytuacji kwarc.
    Slow SCK i SCK to częstotliwość (prędkość) z jaką programator ładuje *.hex'a do Twojej Atmegi. Skoro masz fusy ustawione na 1MHz, to musisz obniżyć tę prędkość i robisz to parametrem " -B xx ".
    Prawidłowe ustawienie F_CPU na obrazku
    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp
    Chyba tak robiłeś, to dla przypomnienia.
    Z obrazka, post #18, wynika, że odczytałeś pusty procesorek mimo prawidłowego załadowania 142 Bajtów ??? Coś nie tak. Wskazuje to na uszkodzenie ATmegi.
    Kalkulator Fusów tutaj : https://www.engbedded.com/fusecalc/
    I wreszcie zrezygnuj z avrdude z atnela i pobierz stąd : http://download.savannah.gnu.org/releases/avrdude/ najlepiej możliwie najnowsze. Rozpakuj i używaj w Eclipse.
  • #25 19942779
    AttA91
    Poziom 7  
    AttA91 napisał:

    Atmega16A - PU: Brak reakcji na komendę 'delay' przy miganie diody, DIP-40, USBasp


    Panowie, wymiękam. Kupiłem wczoraj nową atmege. Żeby czasem nic nie zepsuć... nic więcej na pierwszy strzał nie zrobiłem, niż wymieniłem procek w podstawce, skompilowałem (błąd identyczny jak pod koniec testów ostatniej atmegi) z tym verification. Przez dłuższą chwilę jeszcze próbowałem. W sinaprog "Erase" też nie działa, weryfikacja tak samo. Wyskakuje błąd. Identycznie jak w poprzednim AVR. Flasha czyta i zapisuje do pliku (sporo więcej danych niż w poprzednim AVR).

    W jakimś programie (nazwy nie pamiętam dokładnie, coś w stylu 'ISPprog'), dziwnie wygląda. Dziwne napisy się pojawiają w nim, ale 'erase' wykonał.

    W ogólnym rozrachunku nowy procek działa gorzej, trudniej niż poprzedni.

    Może programator kijowy? Programator mam z 'gotronika'. Co więcej, od samego początku jak zwierałem na nim slow_sck to przestawał działać. Dioda oznaczająca zasilanie programatora - gasła.

    Te 25zł, 30zł to niby nie dużo, ale teraz jakbym kupował programator to łącznie już będę miał 60zł wydane, a nie wiadomo czy mi się uda. Potem kolejne 60zł bo procek uszkadzał podstawkę albo na odwrót :).
  • #26 19942961
    Janusz_kk
    Poziom 38  
    Zrób zdjęcia płytki i połączeń, ten slow sck zostaw w spokoju, to musi chodzić na standardowym.
  • #28 19943471
    Janusz_kk
    Poziom 38  
    Myślałem ze to na płytce stykowej łączyłeś :) piny atmegi ci dobrze łączą w podstawce? lupą trzeba się im dobrze przyjrzeć. albo omomierzem przemierzyć.

    Dodano po 48 [sekundy]:

    A w ogóle co to za przejściówka, daj jakiegoś linka.
  • #30 19943898
    Janusz_kk
    Poziom 38  
    A jakie napięcie masz wybrane w programatorze czy w ogóle z niego zasilasz atmegę?

Podsumowanie tematu

Użytkownik ma problemy z programowaniem mikrokontrolera ATmega16A przy użyciu programatora USBasp. Kod do migania diodą nie reaguje na zmiany wartości opóźnienia w funkcji _delay_ms, mimo że dioda miga. Użytkownik nie dotykał fusebitów, ale podejrzewa, że mogło dojść do uszkodzenia procesora po nieprawidłowym włożeniu do podstawki. W odpowiedziach sugerowano sprawdzenie ustawień częstotliwości MCU, kompilację kodu z poprawnym zdefiniowaniem F_CPU oraz użycie innego programatora. Po wymianie procesora i programatora problem został rozwiązany, a dioda zaczęła działać zgodnie z oczekiwaniami.
Podsumowanie wygenerowane przez model językowy.
REKLAMA