Witam.
Wykonałem układ według twojego projektu i działa znakomicie.
mam tylko pytanie czy licznik który liczy naprawione mikrokontrolery daje jakieś ograniczenia czy to tylko taka informacja dodatkowa.
Tzn jakie ograniczenia? Nie ma żadnych ogranicznień, to po prostu licznik, po każdej prawidłowej naprawie zwiększa się o 1, po dojściu do 65535 po prostu zacznie od zera. O ile dobrze pamiętam to jego wartość jest przechowywana w dwóch ostatnich komórkach pamięci eeprom.
szymanczuk wrote:
Na szybko zbudowałem pająka żeby przetestować i przy okazji odblokować kilka AVR, u mnie pomogło z ATMEGA644p ATMEGA16, ATMEGA8, i tiny2313, więc projekt godny polecenia.
Dzięki, proszę zgłaszać co się udało naprawić a co nie, listę będe uzupełniał i ewentualnie powstaną jakieś poprawki w razie problemów
Duch__ wrote:
No to poproszę pod atmegę 168. Nic nie mam do staracenia, a mogę odzyskać zablokowane procesorki.
W załączniku kod wynikowy, daj znać czy działa...
A na stronce faktycznie miałem literówkę, oczywiście powinno być 38400, już poprawione
Przepraszam autora wątku że wpierdzielam się tak z swoimi kodami (jeśli będzie przeszkadzało to wyedytuje i stworze osobny wątek) lecz piszę apropo aktualnego tematu naprawy mikroprocesorów z poziomu procesora innego niż Atmega8.
Mam dwie zablokowane sztuki AT8 i aby je odblokować musiał bym kupić 3 i zbudować twój układ co dla mnie jest raczej nieopłacalne, mimo wszystko gratulacje za pierwszoplanowy projekt wśród fusedoctorów.
W związku z powyższym postanowiłem zgodnie z aplikacją atmega8 odblokować je za pomocą attiny 2313 i tak powstał kod który udostępniam na dole, całość połączona na płytkach stykowych (co widać na dołączonym zdjęciu TUTAJ), schematu nie rysowałem bo myślę że wystarczą same opisy połączeń. A wyglądają one tak:
Attiny 2313(doktor) <> Atmega8(pacjent)
Sygnały sterujące
PD0 <> BS1 (PD4)
PD1 <> BS2 (PC2)
PD2 <> XA0 (PD5)
PD3 <> XA1 (PD6)
PD4 <> XTAL1 (PB6)
PD5 <> do LED przez rezystor do GND
PD6 <> WR (PD3)
-Dodatkowo w Atmega8(pacjent) OE(PD2) oraz PAGEL(PD7) odrazu do GND
-Port RDY/BSY (PD1) można połączyć przez rezystor do led, sygnalizuj ona wejście w tryb programowania czyli praktycznie cały czas świeci.
-Zasilanie obu układów 5V i przygotowane zasilanie 12V potrzebne do wejścia w stan programowania
-Zasilanie przygotowane ta aby dopiero po włączeniu doktora(attiny) można było ręcznie włączyć zasilanie do pacjenta 5V do VCC i AVCC oraz 12v do RST
-Oba układy bez kwarców
Wszystko zrobione według aplikacji Atmega8 (memory programming) i powinno działać i co ??
NIE DZIAŁA, albo gdzieś popełniłem błąd albo moje AT8 są zablokowane na amen, choć wchodzą w stan programowania. Więc zwracam się z prośbą jeśli ktoś miałby ochotę sprawdzić z grubsza w czym tkwi problem, to będę bardzo wdzięczny, kod mimo że trochę nieelegancki to jest w większości opisany komentarzami tak aby nie trzeba było zbyt wiele kombinować.
W załączniku oprócz kodu znajdują się już dwa skompilowane hexy, to nic innego jak dwa sposoby wchodzenia w stan programowania (aplikacja s228):
-AT8N_init1.hex sposób pierwszy:
Czyli po włączeniu układów gdy dioda(podpięta do attiny) świeci należy reset pacjenta(at8) przyłączyć do gnd
Gdy dioda zacznie migać należy przełączyć reset na 12V
Pamiętając że na obie operacje mamy około 10 sekund (w ramach świecenia/migania diody)
? Między tymi czynnościami attiny musi zmienić sygnał XTALL parę razy dlatego tak to wygląda.
AT8N_init2.hex sposób drugi:
Czyli najpierw włączamy do 5V lekarza(attiny) który ustawia odpowiednie stany na nóżkach, gdy dioda (podłączona do attiny) zacznie migać(praktycznie odrazu) włączamy pacjenta VCC i AVCC(at8) do 5V oraz RST do 12V.
-nie gryzmolić się z tym włączaniem , należy zmieścić się w (czas migania led)
ps. z ewentualnymi pretensjami dotyczącymi zaśmiecania wątku pisać nie krępować się, tak jak powiedziałem, zrozumiem i założę własny, tym tylko chciałem się wstrzelić w aktualny temat.
Tak na szybko: po komendzie write fuse dla low byte powienieneś zerować xa1 i xa0 a je zamieniasz - chyba że w a8 jest inaczej (podglądam swój od a16), fuse high tak samo.
Ja u siebie mam ustawiony bit EESAVE, pamięć danych (flash) i pamięć EEPROM mam wgraną. Jednak w dalszym ciągu przez RS232 wywala mi krzaki, włąśnie przy prędkości 38400. A jeszcze takie pytanie do autora projektu. Co oznacza zapalenie zielonej diody? Czy tylko odczytanie sygnatury, czy również sprawdzenie poprawności zaprogramowania nowych fusebitów?
C. Load Data Low byte
1. Set XA1, XA0 to "01". This enables data loading.
2. Set DATA = Data Low byte (0x00 - 0xFF).
3. Give XTAL1 a positive pulse. This loads the data byte.
Zerowanie jest przy Load Address Low byte ale adresu przy fuskach (chyba ?) nie musimy wysyłać, przynajmniej nic takiego nie widziałem w aplikacji.
No nic, będzie trzeba poczekać parę miesięcy na nową i (tanią) serie at8 od atmela i zbudować główny układ tego wątku, z ciekawości czy on odblokuje te kostki.
Aaa, bo widzisz, w datasheecie od a16 jest ładny rysunek 131 na którym przebiegi nie zgadzają się z opisem. Właśnie się przegryzam dalej .
PS: Dobra, takie moje obserwacje:
nie czekasz na rdy/bsy tylko jedziesz po delayu z miganiem - powinien być dłuższy ale nie wiesz czy się coś dzieje czy nie...
jak dajesz impuls na wr czy xtal to daj kilka nopów, niech się zdąży pin przeładować.
Porównuję sobie datsheety od a8 i od a168 i w jednym każą machnąć 6x xtal a w drugim czekać 20us np... A niby powinny się programować tak samo...
Jest dodatkowa procedura awaryjna:
Quote:
Note, if the RESET pin is disabled by programming the RSTDISBL Fuse, it may not be possible
to follow the proposed algorithm above. The same may apply when External Crystal or External
RC configuration is selected because it is not possible to apply qualified XTAL1 pulses. In such
cases, the following algorithm should be followed:
1. Set Prog_enable pins listed in Table 92 on page 227 to “0000”.
2. Apply 4.5 - 5.5V between VCC and GND simultaneously as 11.5 - 12.5V is applied to
RESET.
3. Wait 100 ns.
4. Re-program the fuses to ensure that External Clock is selected as clock source
(CKSEL3:0 = 0’b0000) and RESET pin is activated (RSTDISBL unprogrammed). If Lock
Bits are programmed, a chip erase command must be executed before changing the
fuses.
5. Exit Programming mode by power the device down or by bringing RESET pin to 0’b0.
6. Entering Programming mode with the original algorithm, as described above
W zwykłej procedurze nie musisz robić chip erase, zrobisz to sobie z isp.
Nie wiem jak szybkie masz ręce z tym podłączeniem resetu i zasilania , dla a8 każą to robić "simultanously" a dla 168 w przedziale 20-60us więc pogratulować .
Rozumiem, że tak samo wychodzisz z trybu programowania, przez wyciągnięcie wtyczki.
Podłącz się przez tranzystory i steruj sobie z programu jedno i drugie, będziesz wiedział, że na pewno robi to co ma robić.
Aha, nie ma sensu podawać zmiennych w hexie skoro i tak rozpisujesz sobie na bity obok, podawaj binarnie, 0b zamiast 0x.
Nie liczę Ci fusów, sprawdziłeś że ustawiasz to co chcesz? 0 programuje, 1 kasuje bit więc wrzucasz negatyw tego co chcesz mieć ustawione.
Tyle mi w oko wpadło, staram się znaleźć wszystko co może być nie tak , jakoś najpradopodobniejsze wydają mi się te opóźnienia.
No to poproszę pod atmegę 168. Nic nie mam do staracenia, a mogę odzyskać zablokowane procesorki.
W załączniku kod wynikowy, daj znać czy działa...
Niestety nie działa. Ale nie wiem czy przypadkiem nie jest to wina mojego układu który przerobiłem na SMD (może gdzieś się palnąłem przy lutowaniu). Tak więc wykonał układ jeszcze raz ale metodą przewlekaną.
Aha, co zauważyłem. Ja programuje układ przez AVR-Burn-O-Mat. Zdziwiło mnie to że na Atmegę8 twój wsad zajmuje 8kb, a na atmegę168 aż 10kb, a nie powinno być tak dużej różnicy przy zmianie w programie sygnatury urządzenia. Zmieniałeś coś jeszcze?
Czym ty wrzucasz wsad na procka? Możesz przy okazji zrobić screena z ustawieniami fusebitów?
Wszystko zrobione według aplikacji Atmega8 (memory programming) i powinno działać i co ??
NIE DZIAŁA
Błąd w połączeniach, nie bez powodu u siebie każdą linię łączyłem poprzez rezystor. Nawet napisane jest o tym w nocie, że gdyby pacjent nie wszedł w tryb programowania lub pojawiły się inne problemy, a doktor będzie robił swoje, to mamy piękny konflikt stanów na liniach i popalone porty.
Tak samo linie "prog enable" należy zwolnić zaraz po tym gdy pacjent wejdzie w tryb programowania, bo tutaj również może wystąpic konflikt na liniach (w którejś nocie wyczytałem) - u Ciebie PAGEL jest na stałe do GND.
Największy BYK... OE to linia Output Enable - czyli ściągając ją w dół, szyna danych pacjenta pracuje w roli wyjścia - u Ciebie cały czas do GND więc jakim cudem chcesz cokolwiek przesłać do pacjenta skoro jego piny są wyjściami? Sprawdź czy nie popaliłeś tych portów już
Kolejna rzecz, załączanie resetu. Powinno się to raczej odbywać wg tego co podano w nocie, czyli zasilanie, 100us, prog enable, 100ns, reset, 100ns. To są czasy minimalne, ja dawałem dwa razy więcej. U Ciebie reset załącza się ręcznie, nie wiem jak procek na to zareaguje. Być może stan wysoki na RDY może być przypadkowy, może wykonuje się jakiś kod - a procek nie wszedł w ogóle w tryb programowania.
Dodatkowo, tak jak napisał PO., W różnych notach te sekwencje odpalania trybu programowania wyglądają nieco inaczej. Inne są czasy, inna kolejność, a w starszych prockach NIBY trzeba machnąć kilka razy zegarem przed rozpoczęciem czegokolwiek - nie trzeba Tak że chyba znalazłem aż 4 różne, ale zastosowałem tylko jeden bo wszystkie testowane procki ładnie się uruchamiały. O ten:
1. Set Prog_enable pins listed in Table 27-12 on page 291 to “0000”, RESET pin to 0V and
VCC to 0V.
2. Apply 4.5 - 5.5V between VCC and GND.
(Ensure that VCC reaches at least 1.8V within the next 20 µs.) - //nie koniecznie, nie mamy jak tego sprawdzić//
3. Wait 20 - 60 µs, and apply 11.5 - 12.5V to RESET.
4. Keep the Prog_enable pins unchanged for at least 10µs after the High-voltage has been
applied to ensure the Prog_enable Signature has been latched.
5. Wait at least 300 µs before giving any parallel programming commands.
Troszkę te czasy zwiększyłem i chodzi bardzo ładnie. To tyle z samego hardwaru, do kodu nie zaglądałem bo w C nie siedzę, niestety. Jak dla mnie nie przeszkadza tutaj Twój post, cieszę się że ktoś w ogóle zagląda w noty i próbuje własnych sił
PO. wrote:
W zwykłej procedurze nie musisz robić chip erase, zrobisz to sobie z isp.
Akurat Chip Erase to chyba najprostsza rzecz jaką można sobie dodać na samym początku. Po tym obserwujemy stan na pinie RDY i jeśli pójdzie w górę to znaczy że komenda wykonała się prawidłowo i mamy już porządek z pinami Action i Byte Select - a z tymi sam miałem niezłe problemy. Dodam że bez jakiegoś wyświetlacza czy UARTa cienko widzę uruchamianie takiego czegoś
Duch__ wrote:
Niestety nie działa.
Jakie objawy?
Co do rozmiaru wsadu... Kod kompilowany pod M8 zajmuje 99% jej pamięci, a kompilowany (bez zmian) na M168 zajmuje 60% jej pamięci - bascom żyje własnym życiem Dodatkowo w kodzie na M168 masz już wszystkie nazwy procków po RSie które nie weszły w M8.
Nie wiem skąd takie problemy z fuskami, przecież wystarczy ustawić wewnętrzny generator i włączyć EESAVE. Reszta bez znaczenia.
Programuję przez avrdude poprzez bascom. Używam też AVR-BURN-O-MAT, fuski:
Używam też mkAVR Calculator, polecam ściągnąć i wypróbować, fuski:
Na szczęście tylko w opisie, oczywiście że OE na 1.
Quote:
Tak samo linie "prog enable" należy zwolnić zaraz po tym gdy pacjent wejdzie w tryb programowania, bo tutaj również może wystąpic konflikt na liniach (w którejś nocie wyczytałem) - u Ciebie PAGEL jest na stałe do GND.
Racja, niestety brakło mi pinów na malutkim attiny2313 myślałem że nie będzie to robiło aż takiego problemu.
Quote:
Nie wiem jak szybkie masz ręce z tym podłączeniem resetu i zasilania Smile , dla a8 każą to robić "simultanously" a dla 168 w przedziale 20-60us więc pogratulować
Quote:
Kolejna rzecz, załączanie resetu. Powinno się to raczej odbywać wg tego co podano w nocie, czyli zasilanie, 100us, prog enable, 100ns, reset, 100ns. To są czasy minimalne, ja dawałem dwa razy więcej. U Ciebie reset załącza się ręcznie, nie wiem jak procek na to zareaguje.
Jak wyżej sterowanie zasilaniem wymaga dodatkowych pinów (doktora) których niemiałem dlatego próbowałem ręcznie, a jak widać jednak czasy przełączeń są ważne w tej operacji.
Wnioski: do sukcesu brakło kilku portów w attiny2313(taki tylko miałem pod ręką) którymi mógłbym sterować zasilanie, reset, oe oraz pagel (pacjenta), a najlepiej gdyby było ich jeszcze więcej na podpięcie lcd tak jak kol ~manekinen zasugerował aby mieć wgląd w cały proces.
Dziękuje kolegą ~manekinen oraz PO. za zainteresowanie się problemem
Pozdrawiam.
Na szczęście tylko w opisie, oczywiście że OE na 1.
No w górę tak, dla samego zapisu. Ale gdy chcesz cokolwiek odczytać z pacjenta, to już musisz kierunkiem sterować ściągając ją w dół na czas odczytu.
Jeśli będą jakieś wątpliwości chętnie pomogę, proszę pytać.
gufim wrote:
Witam wszystkich poskladalem Doktora i udalo mi sie odblokowac moje Atmegi tak wyglada pozyteczny uklad nie tylko dla tych Atmeg ktore udalo mi sie rozblokowac dzis ale bardzo sie przyda w przyszlosci
No to taka wersja partyzancka, radzę dać rezystorki na wszystkie linie - czemu? Czytaj post wyżej. Cieszę się że działa, jak widać może warto zainwestować te kilkanaście złotych w atmegę8 żeby odzyskać inne poblokowane - koszt się zwróci A jeśli układ się podoba, można zagłosować u góry strony
Witam wszystkich poskladalem Doktora i udalo mi sie odblokowac moje Atmegi tak wyglada pozyteczny uklad nie tylko dla tych Atmeg ktore udalo mi sie rozblokowac dzis ale bardzo sie przyda w przyszlosci
No to taka wersja partyzancka, radzę dać rezystorki na wszystkie linie - czemu? Czytaj post wyżej. Cieszę się że działa, jak widać może warto zainwestować te kilkanaście złotych w atmegę8 żeby odzyskać inne poblokowane - koszt się zwróci A jeśli układ się podoba, można zagłosować u góry strony [/quote]
Owszem moze i partyzancka wersja ale dziala co do rezystorow to moze na tym zdjeciu nie widac ale sa wszsystkie zgodnie ze schematem i pozniejszymi poprawkami , a co do glosowania to juz zaglosowalem i fakt warto zainwestowac pare zloty myslac przyszlosciowo
Wykonałem programator równoległy ze strony http://elm-chan.org/works/avrx/report_e.html. Uratowałem 2 szt.m162 i jeden m8. Mam kłopot z drugą m8. Otrzymuję informację, ze nie może odczytac sygnatury i dostep do procka nie jest możliwy. Czy tym "doctorem" jest możiwość naprawienia uszkodzonej sygnatury czy procek jest do kosza. Prawdopodobnie uszkodzenie powstało przez wyciąganie procka z układu typu "pająk" pod napięciem 5V.
gufim - a faktycznie są rezystorki, nie zauważyłem
anko6 - układ leczy fuski, ale cudów niestety nie potrafi. Tej drugiej możesz się pozbyć bo jest martwa. Sygnatury nie da się zmienić, nie ma takiej możliwości.
Witam.
Zrobiłem kopię tego urządzenia.
Działa super od pierwszego uruchomienia.
Odblokowałem sobie ATMEGE16 i ATMEGE32 (ubite przez mój błąd w CODEVISION)
Dzięki.
Ode mnie duży +
W załączniku znajduje się fotka mojej płytki, podstawek nie miałem pod ręką to poskładałem z 2-ch
Pozdrawiam.
Marek
Ach, byłbym zapomniał.
procedura programowania (zapisu)
najpierw ustawiłem ATMEGE8 na wewnętrzny RC 8MHz + 0
następnie zapisałem plik hex do pamięci uC.
potem zapisałem plik EEP.
na koniec zaznaczyłem bit EESAVE
Najważniejsze aby NIE zrobić tak:
1.eeprom
2.flash
3.eesave
Bo bez bitu eesave, przy wgrywaniu flasha, zwartość wcześniej zapisanego eepromu zostanie usunięta. Nie podawałem tego wcześniej bo wydawało mi się że jest to sprawa oczywista, ale skoro jest to układ dla osób które omyłkowo zablokowały procesor przez złe ustawienie fusebitów, to chyba taka informacja się przyda Screeny z fusebitami są nieco wyżej.
W poprzednim poście pisałem że programator równoległy przy każdym wpisywaniu polecenia "avrpp -r" odczytywał inną wartość sygnatury i dalszy dostęp do zmian fusebitów i programowania był zablokowany. Miałem nadzieję że Atmega Fusebit Doctor uratuje mi procka, ale niestety Twórca tego wspaniałego urządzenia rozwiał moje nadzieje. Już miałem wrzucić go do kosza ale zaświtała mi myśl, że do płytki testowej z prockiem podłączę zewnętrzny generator 200kHz. Tak zrobiłem i ku mojemu zdziwieniu ożył. Ustawiłem właściwe fusebity i procek jest OK!. Na przyszłość przestroga NIE WKŁADAĆ I WYCIĄGAĆ PROCKA POD NAPIĘCIEM (5V). Ja tak często robiłem i dobrze było do czasu, ale nie wiadomo kiedy jakiś przypadkowy impuls czy pakiet impulsów podczas wyciągania z podstawki coś nie uszkodzi. W moim przypadku oprogramowanie nie mogło odczytać sygnatury ponieważ jeden z uszkodzonych fusebitów ustawił sie na zewnętrzny RC. Mam nadzieję, że kol Manekinen wybaczy mi, że pisałem nie na temat
Napisałem Ci że jest martwa, bo myślałem że próbowałeś podpinać generator lub rezonator - to chyba najprostsza próba odratowania procka, z resztą pisałem o tym na początku W samoczynne przestawienie się fusków wierzę bo też mi się zdarzyło, przepięcia i zaniki zasilania podczas programowania potrafią zdziałać cuda, w tym zmienić sygnaturkę lub nieodwracalnie zmienić fuski
Może spróbujecie pomóc w mojej sprawie.
Układzik złożony i działa wyśmienicie [ od pierwszego kopa odblokował M8 ] ALE :
Po podłączeniu zasilania układ działa od razu , wciśnięcie guzika tak jakby go wyłączało i ponowne puszczenie włącza ponownie. Mam guzik chwilowy zwierający po wciśnięciu - może tu powinien być odwrotny ?!?. Dalej po włączeniu bez "chorego" układu jeden raz zaświeca się dioda czerwona. Po odłączeniu zasilania i ponownym jego włączeniu następuje martwa cisza, żadna z diodek nie świeci do momentu włożenia jakiegoś układu.
Dzięki za kompilacje pod mega168, ale takie pytanko, czy wyprowadzenia zgodne z oryginałem na mega8, czy zmieniałeś coś jeszcze?
jak znajdę więcej czasu to złożę to na płytce stykowej.
ps. warto by było, gdybyś pomyślał nad taką przejściówką isp-hvsp/hvpp, bo to byłby wspaniały projekt, gdyż dużo osób posiada właśnie ISP, a nie chcą inwestować w cały programator HV, który daje większe możliwości
EDIT: co do optymalizacji, ja pomyślałbym nad drugą wersją sterowaną z komputera, wtedy część operacji jak np. przypisywanie nazwy do sygnaturki itp. można by zrzucić na PC
Na ISP nie można przestawić fusebitu SPIEN więc jak już robić to raczej pełne HVPP . Albo po co pełne, wystarczy reblocker, żeby odpowiednio zabezpieczać swoje projekty, już przez ISP zaprogramowane .
hmm, jesteś pewny, że nie można?? bo wydaje mi się, że to tylko zabezpieczenie Twojego programu, choć pewności w tej kwestii nie mam, a sprawdzać nie mam ochoty a przez SPI nie można zabezpieczyć na lock-bitach?? czy nie po to zostały one stworzone??
hmm, jesteś pewny, że nie można?? bo wydaje mi się, że to tylko zabezpieczenie Twojego programu, choć pewności w tej kwestii nie mam, a sprawdzać nie mam ochoty a przez SPI nie można zabezpieczyć na lock-bitach?? czy nie po to zostały one stworzone??
Datasheet a16, s.160, uwagi pod tab.105:
Quote:
Notes: 1. The SPIEN Fuse is not accessible in SPI Serial Programming mode.
Oczywiście jeśli zrobimy translator to od strony procka on będzie dostępny tylko nie wiem co z oprogramowaniem, czy ono automatycznie też nie pozwala na dostęp do tego bitu bo wie, że i tak nie mamy szans.
Kwestia tego co i jak zabezpieczamy jest indywidualna. Są firmy, które fizycznie upalą Ci cały port od programowania, żebyś nie mógł odblokować procka nieautoryzowanymi metodami .
Po podłączeniu zasilania układ działa od razu , wciśnięcie guzika tak jakby go wyłączało i ponowne puszczenie włącza ponownie.
Przycisk jest podpięty do pinu resetu, który właśnie w ten sposób działa i jest to normalne.
PF wrote:
Dalej po włączeniu bez "chorego" układu jeden raz zaświeca się dioda czerwona. Po odłączeniu zasilania i ponownym jego włączeniu następuje martwa cisza, żadna z diodek nie świeci do momentu włożenia jakiegoś układu.
Po uruchomieniu układ czeka na stan wysoki na pinie RDY, gdy procesor nie jest włożony, to ten stan wysoki jest uzyskiwany przez wewnętrzny pullup i program kontynuuje działanie. To że mignie czerwona i zielona dioda to normalne bo dzielą one piny z liniami adresowymi XA0 oraz XA1. A czemu układ zachowuje się w ten sposób bez włożonego pacjenta - nie wiem - ale to już chyba najmniejszy problem Być może napięcie narasta zbyt wolno i trzeba ustawić większe opóźnienie w fuskach. Układ powinien być resetowany przyciskiem "start" a nie poprzez odcięcie zasilania.
piotrva wrote:
Dzięki za kompilacje pod mega168, ale takie pytanko, czy wyprowadzenia zgodne z oryginałem na mega8, czy zmieniałeś coś jeszcze?
Bez zmian, tylko kompilacja, no i tak jak wspomniałem program ten pokazuje wszystkie nazwy przez uart.
piotrva wrote:
ps. warto by było, gdybyś pomyślał nad taką przejściówką isp-hvsp/hvpp, bo to byłby wspaniały projekt, gdyż dużo osób posiada właśnie ISP, a nie chcą inwestować w cały programator HV, który daje większe możliwości
Nie ma problemu, zrzutka forumowa, biorę trochę urlopu, i będzie układ Kolego bardzo chętnie ale kompletnie nie mam czasu
piotrva wrote:
co do optymalizacji, ja pomyślałbym nad drugą wersją sterowaną z komputera, wtedy część operacji jak np. przypisywanie nazwy do sygnaturki itp. można by zrzucić na PC
Zauważ wolny pin uartu - RX. To taka otwarta furtka pozwalająca na rozwój projektu, jest możliwość zrobienia w ten sposób że fuski będą wysyłane z komputera poprzez terminal Druga strona medalu: konieczność tworzenia przejściówek usb-uart itd, co podnosi koszta i skomplikowanie. Może kiedyś...
A co do możliwości zmniany SPIEN poprzez ISP - producent może pisać co chce, polecam popróbować Albo jak producent wytłumaczy to że sygnatura może się zmienić, skoro w notach pisze że jest to niemożliwe. A co do obsługi przez programy, myślę że nie będzie problemu. W jednej z nakładek na avrdude jest możliwość właśnie zmiany sygnatury a sam avrdude ponoć to umożliwia - nigdy mi to nie działało - ale możliwość jest Tutaj więcej http://www.swiatelka.pl/viewtopic.php?p=35126#35126
Ponadto, układu nie testowałem z prockami w wersji "V" pracującej już od 1.8V.
Dostałem ostatnio informację że w obecnym stanie są problemy z tymi prockami ponieważ napięcie zasilające pacjenta nie koniecznie spada poniżej tej wartości przy starcie i są problemy.
Humberto zaproponował takie rozwiązanie - http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/comment-page-1/#comment-1052 I podobno to naprawia problem, być może ktoś ma możliwość sprawdzić, to bardzo proszę.
mówię o zmianie wartości bitu SPIEN poprzez SPI, gdyż u znajomego wykładowcy na AGH podobno (wiem to tylko z opowiadań) studenci zablokowali SPI w kilku uP właśnie korzystając z ISP do programowania. Wina leżała ponoć w oprogramowaniu, którym ustawiali fusebity, gdyż jako domyślną opcję wyłączało SPI...
a sam nie chcę próbować, bo potem, żeby procki odblokować albo musiałbym montować układ z tego projektu, albo wcześniej włączywszy JTAGEN użyć takiego programatora
Wsad 2.04:
-poprawiono kilka błędów
-dodano obsługę nowych procesorów, łącznie 106 (138)
-zmiana wewnętrznego zegara na 1MHz, baudrate UARTa to 2400bps
UWAGA, FUSEBITY! Jeśli uaktualniasz wsad do 2.04, koniecznie zmień wartość wewnętrznego generatora na 1MHz. Jeśli wykonujesz układ od początku, jedyną rzeczą jaką musisz zrobić to włączenie bitu EESAVE – 1MHz jest już ustawiony fabrycznie.
Łącznie 106 obsługiwanych różnych procesorów.
Ukośnik wraz z P/A/PA oznacza że dany procesor w nowszych wersjach ma nadal tą samą sygnaturę i fusebity, przykładowo zapis Atmega165/P/A/PA obejmuje procesory Atmega165, Atmega165P, Atmega165PA. Gdyby liczyć to wszystko osobno, tak jak ma to miejsce na listach różnych programatorów, to wyjdzie ich razem 138.
Proszę zgłaszać błędy itp.
Także jeśli ktoś zna jeszcze jakiś procesor obsługujący parallel lub serial programming, zasilany do 5V, to proszę pisać.
Oto procesory które jeszcze znalazłem, które nie spełniają tych warunków i na 99% NIE będą obsługiwane:
AT90scr100
Atmega128rfa1
Atmega16hva
Atmega16hvb
Atmega32hvb
Atmega8hva
Attiny4
Attiny5
Attiny9
Attiny10
Attiny20
Attiny40
wsad HEX, BIN, oraz Eeprom HEX, BIN, dla programu wersja 2.04.
Wsad wersja 2.05:
-nie ma potrzeby programowania eepromu
-ulepszona obsługa 20-pinowych procków, w tym poprawiony błąd przy naprawie tiny26
-ulepszone rozpoznawianie sygnatury, gdy pierwszy bajt wynosił 1E to układ uznawał ją za odczytaną poprawnie jednak zdarzały się procki które przedstawiały się jako 1E 1E 1E. Teraz dodatrkowo sprawdzany jest drugi bajt, musi się mieścić w zakresie h90 do h98
-brak nazw procków po uarcie, po poprawkach miejsce skurczyło się tak że postawnowiłem całkiem je usunąć - w zamian nie musimy wgrywać eepromu -znowu zmiana prędkości uart, teraz na 4800. Poprzednia 2400 była po prostu zbyt wolna i program przez to zbyt wolno naprawiał
FUSEBITY OD WERSJI 2.04 WYMAGAJĄ ZMIAN, CZYTAJ OPIS!
(PS, w poprzedniej aktualizacji zapomniałem zmienić numerek wersji i układ przedstawiał się jako 2.03)
W załączniku pliki HEX oraz BIN wsadu 2.05
Kolejnych aktualizacji nie przewiduję, chyba że ktoś znajdzie jakieś błędy.
I jeszcze zrzut z terminala... procek tiny2313 który właśnie zrobiłem dla znajomego, fuski ładnie uwalone bo wszystkie były FF... nie wiem jak on tego dokonał
(podglądam swój od a16), fuse high tak samo.
, jakoś najpradopodobniejsze wydają mi się te opóźnienia.
wsad HEX, BIN, oraz Eeprom HEX, BIN, dla programu wersja 2.04.
