Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki

KURS HOME ASSISTANT

Chcesz zautomatyzować swój dom bez skomplikowanego kodowania?
Zastanawiasz się nad wyborem sprzętu, oprogramowania i aplikacji?
Od czego zacząć przygodę z HA? Co będzie najlepsze na start?

Nasz kurs Home Assistant nauczy Cię krok po kroku, jak łatwo zautomatyzować swój dom i oszczędzić na rachunkach za prąd i ogrzewanie. Bez chmur, bez zbędnych abonamentów. Twoja przygoda z Home Assistant zaczyna się tutaj!

↓↓↓

    Szanujemy Twoją prywatność. Możesz wypisać się w dowolnym momencie.




    Teraz jest 11 lip 2025, o 12:10


    Strefa czasowa: UTC + 1





    Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 4 ] 
    Autor Wiadomość
    PostNapisane: 13 wrz 2014, o 18:32 
    Offline
    Nowy

    Dołączył(a): 27 sie 2014
    Posty: 13
    Pomógł: 0

    Witam
    Mam płytkę na etapie montażu i uruchamiania na której póki co znajduje się procesor (ATmega64), linie zasilania, kondensatory filtrujące, rezonator kwarcowy 16MHz, przycisk reset, złącze do ISP i "testowa" dioda LED podłączona do jednego z pinów procesora.
    Na etapie testów polegających na pisaniu prostych programów (różne sekwencje świecenia diody LED) pojawił się pewien problem
    Problem ten polega na tym, że przy programowaniu (Eclipse + USBasp) pojawia się problem przy weryfikacji zawartości pamięci flash.
    Poniższy obrazek pokazuje efekt wydania w konsoli polecenia dla avrdude mającego dokonać weryfikacji pamięci flash (dokładnie ten sam komunikat zwraca Eclipse w trakcie programowania):

    Obrazek

    Próbowałem programów o różnej objętości i problem zawsze pojawia się przy bajcie 0x0100. Dlatego stwierdziłem, że w ramach sprawdzenia za pomocą avrdude odczytam zawartość pamięci flash do pliku *.hex i dokonam porównania z plikiem *.hex otrzymanym po kompilacji programu (sam do końca nie jestem pewien na ile jest to sensowny pomysł)
    W każdym razie efekt porównania pokazuje poniższy obrazek:

    Obrazek

    Jeśli dobrze rozumiem to w bajtach o adresach 0x0100 i 0x0101 jest różnica między plikiem *.hex po kompilacji (0x80 i 0x40) a tym co znajduje się w pamięci procesora (0xFF i 0xFF) . Pozostała elementy o odpowiadających sobie adresach w obu plikach są takie same. (czy na tych komórkach pamięci nie przeprowadzono operacji programowania? zostały one pominięte?)

    Co teraz? Procesor jest uszkodzony?
    Pozdrawiam



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 13 wrz 2014, o 19:05 
    Offline
    Użytkownik
    Avatar użytkownika

    Dołączył(a): 03 kwi 2014
    Posty: 85
    Pomógł: 4

    Ja pamiętam, że opcja weryfikacji zapisu sprawiała różne problemy i to w różnych nakładkach na avrdude.



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 14 wrz 2014, o 12:17 
    Offline
    Użytkownik
    Avatar użytkownika

    Dołączył(a): 17 lip 2013
    Posty: 208
    Lokalizacja: Kielce
    Pomógł: 15

    goose napisał(a):
    Jeśli dobrze rozumiem to w bajtach o adresach 0x0100 i 0x0101 jest różnica między plikiem *.hex po kompilacji (0x80 i 0x40) a tym co znajduje się w pamięci procesora (0xFF i 0xFF) . Pozostała elementy o odpowiadających sobie adresach w obu plikach są takie same.



    Witam

    Nie tylko te 2 bajty, które kolega zaznaczył się różnią:

    Obrazek

    Na pewno Kolega weryfikuje ten sam wsad hex/ tą samą kompilację?

    Jak działa sama opcja ERASE w avrdude? Jaka jest wtedy u Kolegi zawartość flash po odczycie?

    Pozdrawiam

    Daniel



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 14 wrz 2014, o 15:15 
    Offline
    Nowy

    Dołączył(a): 27 sie 2014
    Posty: 13
    Pomógł: 0

    po wywołaniu avrdude z parametrem -e plik *.hex do którego pobieram zawartość pamięci flash składa się tylko z jedej linii: :00000001FF

    Ponadto dzisiaj zauważyłem coś takiego:

    Obrazek

    Polecenia wywołałem w niewielkim odstępie czasu jedno po drugim. Kiedy odłaczyłem programator od komputera i podłączyłem ponownie to za pierwszym razem inicjalizacja przebiegła pomyślnie a później znowu pojawiał się błąd. Po ustawieniu programatora w tryb SlowCk problem z inicjalizacją nie występuje jednak dalej pojawia się błąd przy weryfikacji w trakcie programowania. Żeby sprawdzić programator podłączyłem go pod inny procesor (ATmega 8) i tam nie występowały problemy z inicjalizacją (czy to w trybie normalnym czy SlowCK).

    Dzisiaj sprawdziłem też połączenia i luty na płytce. Wizualnie wszystko wydaje się OK, pomiary multimetrem również nie wykazały niepożądanych przerw czy zwarć.

    Poniżej umieszczam fragment schematu, pokazujący elementy które są obecnie przylutowane na płytce PCB

    Obrazek



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    Wyświetl posty nie starsze niż:  Sortuj wg  
    Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 4 ] 

    Strefa czasowa: UTC + 1


    Kto przegląda forum

    Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 2 gości


    Nie możesz rozpoczynać nowych wątków
    Nie możesz odpowiadać w wątkach
    Nie możesz edytować swoich postów
    Nie możesz usuwać swoich postów
    Nie możesz dodawać załączników

    Szukaj:
    Skocz do:  
    cron
    Sitemap
    Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
    phpBB SEO