Bry,
to mój pierwszy temat, więc proszę o wyrozumiałość - problem przedstawia się następująco. Otóż zacząłem bawić się w programowanie uC(to już pierwszy z problemów) Mam gotowy programator USBasp(kupiony), adapter jakoś tam parszywie przylutowany do płytki uniwersalnej, no i uC - ATmega 8. Środowisko programistyczne to WIN AVR, AVRdude z Burn-O-Matem, ale dość przechwałek, przechodzę do sedna.
Otóż, dokładnie wg instrukcji napisałem i skompilowałem program z zapewne dobrze znanej książki P.Borkowskiego AVR & ARM. Po paru nieudanych próbach wkońcu dioda się zaświeciła, ale stwierdziłem, że potrzebuję jeszcze zmienić fuse bity(ponieważ tak w książce jest napisane). Jednak po tym programator bynajmniej przestał odpowiadać, pokazuje USBasp, ale nie wykrywa uC. Adapter na pewno jest sprawny (sprawdziłem połączenia z 50 razy, zanim odkryłem, że to wina fuse bitów).Próbowałem też zaprogramować przez asemblera i wgrać za pomocą PonyProg, co spełzło na niczym. W książce dopiero po fakcie przeczytałem,jak zestresowany maturzysta, że to w książce (o fuse bitach) tyczyło się programowania własnego programatora USBasp.Na elektrodzie coś o nich znalazłem, ale jako początkujący nie mam o tym zbytnio pojęcia.
Ustawienia, w którym został zaprogramowany uC po raz pierwszy(domyślne ustawienia avrdude): SPIEN, BOOTSZ1, BOOTSZ0, SUT0, CKSEL3,CKSEL2,CKSEL1 na 0, reszta na 1
po raz 2gi(przyrównując do ustawień domyślnych): CKOPT na 0, CKSEL3, CKSEL2,CKSEL1 na 1, a reszta bez zmian
Moje pytanie do bardziej zaawansowanych (+3 gratis).
1. Czy to, że w ogóle programator nie wykrywa uC, to na pewno wina fuse bitów ? (czy moja diagnoza jest słuszna)
2. Czy jest jeszcze możliwość "odratowania" ATmegi ?
3. Czy nie będzie problemów programowaniem w przyszłości (coś było o nieodwracalnej zmianie dostępu do pamięci procka)
4. Czy programator mógł ulec uszkodzeniu, w sumie tam też jest uC (też mi się wydaje to pytanie głupie, ale wolę się upewnić)?
to mój pierwszy temat, więc proszę o wyrozumiałość - problem przedstawia się następująco. Otóż zacząłem bawić się w programowanie uC(to już pierwszy z problemów) Mam gotowy programator USBasp(kupiony), adapter jakoś tam parszywie przylutowany do płytki uniwersalnej, no i uC - ATmega 8. Środowisko programistyczne to WIN AVR, AVRdude z Burn-O-Matem, ale dość przechwałek, przechodzę do sedna.
Otóż, dokładnie wg instrukcji napisałem i skompilowałem program z zapewne dobrze znanej książki P.Borkowskiego AVR & ARM. Po paru nieudanych próbach wkońcu dioda się zaświeciła, ale stwierdziłem, że potrzebuję jeszcze zmienić fuse bity(ponieważ tak w książce jest napisane). Jednak po tym programator bynajmniej przestał odpowiadać, pokazuje USBasp, ale nie wykrywa uC. Adapter na pewno jest sprawny (sprawdziłem połączenia z 50 razy, zanim odkryłem, że to wina fuse bitów).Próbowałem też zaprogramować przez asemblera i wgrać za pomocą PonyProg, co spełzło na niczym. W książce dopiero po fakcie przeczytałem,jak zestresowany maturzysta, że to w książce (o fuse bitach) tyczyło się programowania własnego programatora USBasp.Na elektrodzie coś o nich znalazłem, ale jako początkujący nie mam o tym zbytnio pojęcia.
Ustawienia, w którym został zaprogramowany uC po raz pierwszy(domyślne ustawienia avrdude): SPIEN, BOOTSZ1, BOOTSZ0, SUT0, CKSEL3,CKSEL2,CKSEL1 na 0, reszta na 1
po raz 2gi(przyrównując do ustawień domyślnych): CKOPT na 0, CKSEL3, CKSEL2,CKSEL1 na 1, a reszta bez zmian
Moje pytanie do bardziej zaawansowanych (+3 gratis).
1. Czy to, że w ogóle programator nie wykrywa uC, to na pewno wina fuse bitów ? (czy moja diagnoza jest słuszna)
2. Czy jest jeszcze możliwość "odratowania" ATmegi ?
3. Czy nie będzie problemów programowaniem w przyszłości (coś było o nieodwracalnej zmianie dostępu do pamięci procka)
4. Czy programator mógł ulec uszkodzeniu, w sumie tam też jest uC (też mi się wydaje to pytanie głupie, ale wolę się upewnić)?
