Jak już będziesz programował tą Atmegę, to koniecznie poszukaj jak tam ustawić fusebity. Pamiętam, że kiedyś było to opisane na stronie SIO2SD, ale dziś już chyba tej strony nie ma, bo nie mogę znaleźć... Pamiętam natomiast na pewno, że w starszych wersjach SIO2SD fusebity były źle ustawiane, co powodowało właśnie wysypywanie się od czasu do czasu Atmegi. Po aktualizacji oprogramowania do najświeższej wersji ważne było ustawienie tych fusebitów odpowiednio i dopiero wtedy można się cieszyć bezawaryjną pracą. Objaw który pokazałeś może wskazywać rzeczywiście na wysypany soft w Atmedze.
Aha, z tego co piszesz, to nie masz doświadczenia z mikrokontrolerami Atmela, więc bardzo uważaj co robisz programując fusebity, bo jak zrobisz to źle, to możesz sobie skutecznie zablokować mikrokontroler, którego już samodzielnie za pomocą tego samego programatora nie odblokujesz...

Z tymi kilkoma atmelami, to nie przesadzaj, szkoda kasy. Możesz ćwiczyć na tym swoim, tylko przestrzegałem, żeby zachować ostrożność, bo za pomocą fusebitów ustawia się np. takie rzeczy jak zegar, taktowanie, no i jak tam coś nieumiejętnie ustawisz, to może Ci już procek po prostu nie wstać, więc trzeba to robić po prostu ostrożnie i 10x sprawdzić jak wszystko poustawiałeś zanim klikniesz, żeby to zapisać w procku. Poprawne ustawienia fusebitów były podawane dopiero w czasach ostatnich wersji 3.x więc jak miałeś 2.5, to bardzo prawdopodobne, że były źle poustawiane, bo kiedyś ktoś tam źle to podał i była to istna plaga, że się te atmegi wysypywały z tego powodu.
Jak będziesz miał programator, to po prostu odczytasz jak są ustawione fusebity i porównasz z tymi, które podał x_angel, bo on raczej dobre podaje:-) Na 90% okaże się, że są ustawione źle, więc przestawisz na takie jak podał, sprawdzisz 10x czy dobrze ustawiłeś i wtedy je zaprogramujesz. Następnie możesz sobie już nie ruszając nigdy tych fusebitów wrzucać dowolne wersje sio2sd ile razy chcesz i kombinować, tylko nie ruszać już bez potrzeby fusebitów. Samo reprogramowanie softu niczego Ci nie popsuje.

Ostatnio edytowany przez Mq (2018-02-02 19:49:48)

Widzę, że każdy programuje innym softem, jak komu wygodniej i co się komu sprawdza:-)
Dorzucę swoją metodę: ja z kolei używam do programowania wszelkich atmeli Bascom AVR.
Kiedyś dawno temu bawiłem się Bascomem, później przesiadłem się na język C i obecnie programuję wszystko na AVR-y w C w Atmel Studio. Ale Atmel studio wspiera tylko swoje programatory, zwykłego USBasp nie zobaczy, więc z przyzwyczajenia używam ciągle programowania z Bascoma.
W każdym razie mi ten Bascomowy wypalacz pasuje, nigdy nic mi nie uwalił i jest dość wygodny.

Kluczowe są najstarsze bity fusebitu L.
Tam jest ustawione 3F, więc te dwa najstarsze bity mamy mieć ustawione.

Jeden z nich to BODEN, a drugi to BODLEVEL. BODEN włącza wewnętrzny układ kontroli napięcia zasilania w atmedze, który  powoduje, że jeżeli napięcie zasilania odbiegnie od wskazanego, to układ przejdzie w stan reset i nie będzie działał, więc na pewno nie zapisze nic błędnie do pamięci EEPROM. BODLEVEL ustawia poziom zadziałania.

Gdy nie mamy tego włączonego, to może nam się wywalać pamięć EEPROM w atmedze i zapewne tak się dzieje, bo w trakcie zapisu do tej pamięci jeśli nie mamy stabilnego napięcia, to zapisują się krzaki. Na oko w pamięci tej przechowywane są nasze ustawienia i ostatnio wybrany folder/plik/nr stacji czy co tam jeszcze da się zapisać w SIO2SD. Krzaki tam zapisane powodują, że soft nie umie z tym działać i jest "wysypany", bo po prostu wisi nie umiejąc nic zrobić z krzakami odczytanymi zamiast spodziewanych wartości.

Wg mnie niestabilne napięcie zasilania atmega dostaje w trakcie znaczącego chwilowego poboru prądu, kiedy następują "piki" na zasilaniu spowodowane jego znacznym spadkiem na ułamek sekundy. Swoją drogą konstruktor SIO2SD najwyraźniej olał podstawowe zalecenia producenta mikrokontrolera. Poza szeregiem innych zaleceń Atmel wyraźnie podaje dla wszystkich swoich mikrokontrolerów, że bezpośrednio przy zasilaniu mikrokontrolera należy zastosować dwa kondensatory: 100nF blokujący i minimum 100uF - który właśnie by te spadki napięcia nam pięknie wyeliminował, ale na schematach SIO2SD jakoś go nie widzę. Dziwię się temu trochę, bo całe urządzenie to dość zaawansowana konstrukcja, a tu takiej podstawowej pierdoły nie przestrzegł konstruktor?

Tutaj jest snapshot strony Gucia z zeszłego roku: https://web.archive.org/web/20170114143 … iki/Polski

Ostatnio edytowany przez voy (2018-02-03 14:48:29)

A po co Ci 2.5? Załaduj mu od razu najnowszy 3.1RC2. Tam wszystko w nim działa elegancko.

Zajrzałem teraz do swoich archiwów, bo kiedyś miałem wersję 2.x w swoim SIO2SD i podobnie mi się wywaliło jak u Ciebie. I wtedy to naprawiałem. Teraz w moich archiwach znalazłem notatki swoje z tamtego czasu. W pliku tekstowym miałem zapisane, że właśnie te fusebity, o których pisałem wcześniej ktoś w tym moim egzemplarzu źle poustawiał. Jest też zapisek, że ustawiłem HI na C3, i LO na 3F, więc tak jak pisał x_angel.

W archiwach mam też wsad, którym programowałem Atmegę 3.1RC2 oraz configurator 3.5. Jak by co, to gdyby tam linki nie działały, albo był nie taki jak trzeba, to wyślij mi swój adres mailowy na PM, wtedy podeślę Ci mailem te dwa pliki.

Co do programowania, to również w zapiskach sprawdziłem, że złącze na SIO2SD sześciopinowe ma taką samą kolejność pinów jak ta przejściówka, którą zamówiłeś, więc podłączasz przez tą przejściówkę do programatora i programujesz.
Musisz doczytać czy ten Twój programator ma możliwość zasilania programowanego układu z siebie, wtedy nie podłączasz SIO2SD do Atarki, w przeciwnym razie musisz podać zasilanie, więc np. tak jak to napisano podłączyć do Atarki i włączyć.

@pajero są dwa "standardowe standardy":-) złącz programowania do Atmela. Kanda IDC10 i drugi mniejszy IDC6. Kanda jest bez sensu o tyle, że zajmuje więcej miejsca na płytkach, a nie ma nic dodatkowo, tylko powielone masy na pinach. Dlatego najczęściej dziś stosuje się ten standard 6-pin. W SIO2SD został zastosowany właśnie taki standard.

Natomiast druga sprawa, to programatory ISP - to skrót od In System Programming - czyli programowanie mikrokontrolera w systemie, w układzie. Krótko mówiąc o to właśnie w tych programatorach chodziło, żeby można było bez wyciągania, bez wylutowywania przeprogramowywać mikrokontroler bezpośrednio w działającym układzie. Dodatkowo na złączu programatora mamy zasilanie i masę, więc można w czasie programowania cały układ tędy zasilać.

Koncepcja taka bardzo się przydaje. Ja np. w moim projekcie (S)NESctrl tak zaprojektowałem układ, że złącze służące do podłączania pada jest jednocześnie złączem programatora:-) Do komunikacji z padem sprytnie wykorzystałem te same piny mikrokontrolera, które są wykorzystywane do jego programowania. Dzięki temu nie potrzebuję dodatkowego złącza programatora na płytce, a mogę łatwo zmieniać firmware:-) http://www.atari.org.pl/forum/viewtopic.php?id=14670

Sorry. Słabo, ale widać że to 14MHz. Nie było tematu

No tak, z tego wynika, że układ jest zasilany bezpośrednio z programatora, więc nic więcej do tego nie podłączaj. Musisz zainstalować jakiś sterownik do tego programatora, a następnie odpalić program, który wybrałeś do programatora i powinien zobaczyć/wykryć atmegę. Jak dojdziesz do tego stanu, to następnie bierzesz się za programowanie.Najpierw odczytujesz fusebity, żeby sprawdzić jak były ustawione i jeśli inaczej niż pisano tutaj w wątku, to ustawiasz je/zaprogramowujesz tak jak mają być. Na koniec zaprogramowujesz nowy wsad, odłączasz wszystko od kompa, podłączasz do Atarynki i grasz w River Raida:-)

Edit: aha, zawsze programuj wszystko z weryfikacją, lub rób weryfikację zawartości układu z zawartością bufora. Może się zdarzyć i zdarza się czasem, że wszystko przebiegnie pomyślnie, ale gdzieś tam coś się nie zgadza, jest mały błąd, którego nie zauważysz na początku, a który wyjdzie przy jakiejś tam okazji w przyszłości i się zdziwisz.

Ostatnio edytowany przez Mq (2018-02-06 21:10:34)

No widzisz: masz odpowiedź dlaczego ATmega się wywaliła: skoro było FF zamiast 3F, to właśnie te dwa bity, które powinny być ustawione (opisywałem wcześniej) nie były. Teraz jak zmieniłeś i zapisałeś, to na koniec po wszystkim jeszcze raz sprawdź czy na pewno są dobre zapisane (odczytaj na koniec jeszcze raz na wszelki wypadek).

Do EEPROMU nic nie zapisujesz. Plik bin musisz zapisać do FLASH. Jeżeli tam widać tylko hex, to zrób tak jak mówisz all files i wybierz tego bin. Będzie dobrze. Aha, najpierw wykasuj zarówno FLASH jak i EEPROM w tej atmedze, żeby była czysta, lub chyba wystarczy że zaznaczysz przy programowaniu tam widzę na screenshocie checkbox "Erase flash and EEPROM".

Jeszcze uwaga ogólna: jak programujesz to zawsze się upewnij, że masz stabilne zasilanie i wszystkie kabelki dobrze podłączone (w sensie stabilnie) i nie ruszaj nic w tym czasie żadnym kabelkiem, bo jak coś zaniekontaktuje, to się może też uwalić procek...

Ostatnio edytowany przez Mq (2018-02-06 21:59:13)