Problem z fuse bits (ATMega8)
-
Stick
Problem z fuse bits (ATMega8)
Mega 8 standardowo ustawiony oscylator wewnętrzny. Rzecz jasna, chciałem to zmienić na kwarc zewnętrzny i tu zbliżamy się do problemów. Programuję w Bascomie i tam te bity można łatwo pozmieniać. Zmieniłem zatem wszystkie na 1111:1111 i gdy to zapisałem procek w ogóle przestał pracować. Podłączam kwarc i dalej to samo. Bascom już go nie wykrywa (dokładnie to ich, bo załatwiłem tak 2 procki) i pisze:
could not identify chip with id:ffffff
selected chip and target chip do not match 90s2313<>M8
readlb entry not found
Please, pomóżcie!!!
could not identify chip with id:ffffff
selected chip and target chip do not match 90s2313<>M8
readlb entry not found
Please, pomóżcie!!!
-
ZbeeGin
- Tranzystor
- Użytkownik
- Posty: 889
- Rejestracja: 28 sie 2005, 19:19
- Lokalizacja: Świętochłowice
- Kontakt:
Jest jedna bardzo ważna żecz, nie możesz zmieniać byle czego w fuse bitach jeżeli masz programator ISP, a jeżeli chodzi o kwarc to ustaw tylko High bity, a raczej tylko kwarc. Jak chcesz to zapisać do procka to daj tylko Write HB.
Jak nie będziesz jeszcze czegoś wiedzieć to powiedz spróbuje Ci pomóc, bo ostatnio bawiłem się z ATmega8.
Pozdrawiam
Jak nie będziesz jeszcze czegoś wiedzieć to powiedz spróbuje Ci pomóc, bo ostatnio bawiłem się z ATmega8.
Pozdrawiam
To ja jestem stick-gość, a właściwie to stick jest mną, tzn. miałem problem z zalogowaniem się, ale już działa.
Wracając do meritum: sytuacja jest taka, że mam 2 załatwione procki w sposób powyżej już opisany i prosiłbym o opis tego programowania równoległego (po prostu nie chcę wyrzucać tych procków do śmieci). Chyba. że znacie jakiś inny sposób na mój problem.
Wdzięczny za zaiteresowanie,
Laska
Wracając do meritum: sytuacja jest taka, że mam 2 załatwione procki w sposób powyżej już opisany i prosiłbym o opis tego programowania równoległego (po prostu nie chcę wyrzucać tych procków do śmieci). Chyba. że znacie jakiś inny sposób na mój problem.
Wdzięczny za zaiteresowanie,
Laska
- Tranzystor
- Użytkownik
- Posty: 889
- Rejestracja: 28 sie 2005, 19:19
- Lokalizacja: Świętochłowice
- Kontakt:
Jak widze za bardzo się nie znasz na mikroprocesorach, nie jest aż tak prosto zrobić programator równoległy jak Ci się wydaje. Trzeba troszke więcej umieć, wiedzieć jak ma sie programator porozumieć z mikroprocesorem. Niestety taki programator kosztuje sporo powyżej 80zł, więc moim zdaniem najlepszym rozwiązaniem jest wyżucenie tych procków i kupienie jednego, a gdy czegoś nie wiesz to nie rób tylko najpierw się spytaj na forum, tak oszczędzisz sobie części elektroniczne.
Hej hej... hola... nic nie wyrzucaj!! Pójdź z tym na uczelnię (Politechnikę) albo do technikum Elektronicznego. Tam powinni mieć odpowiedni sprzęt. Profesorzy zwykle bardzo chętnie pomagają młodym studentom którzy są aktywni i eksperymentująTranzystor pisze: Niestety taki programator kosztuje sporo powyżej 80zł, więc moim zdaniem najlepszym rozwiązaniem jest wyżucenie tych procków i kupienie jednego
-
Kapitan_Rzbik
- -
- Posty: 97
- Rejestracja: 20 gru 2005, 10:52
- gwozdex
- Użytkownik
- Posty: 879
- Rejestracja: 24 lut 2006, 10:04
- Lokalizacja: Czechowice-Dziedzice
- Kontakt:
Witam! [BASCOM]
Mam pytanie (znów te fusebity...), dziwne, ale to co mi się przytrafiło... jest dziwne. Otóż zablokowałem sobie ATtiny2313 (przynajmniej tak mi się wydaje ponieważ wyskakuje komuniktat "readlb entry not found" oraz, że pomieszałem typy procków). Sęk w tym że nawet nie ruszałem fusebitów... Ba nawet nie zdążyłem załączyć funkcji programowania- ustawiłem sobie tylko w ustawieniach opcje "Program after compile" oraz "upload code and data" no ale chyba to nie jest przyczyną- przecież proces programowania nie ingerowałby w fusebity- zostałyby one w domyślnej konfiguracji.
A korzystając z okazji to chciałem (na przyszłość) zapytać jaką kolejność wykonywania czynności polecacie, żeby takich sytuacji uniknąć?? Chodzi mi o to czy np. zaraz po włożeniu układu do podstawki załączyć Bascoma i skonfigurawać same fuse bity czy może pierwszym razem nie włączać funkcji automatycznego programowania??
I ostatnie pytanie: jak to jest, że w AVT-3500 złącze SPI jest podłączone do innych pinów niż jest to ustawione (domyślnnie) w Bascomie a pomimo to układy się programują ( np. programy z kursu mikroprocesorowa ośla łączka na układ AT90s2313)?
Dziękuję za pomoc i pozdrawiam.
Mam pytanie (znów te fusebity...), dziwne, ale to co mi się przytrafiło... jest dziwne. Otóż zablokowałem sobie ATtiny2313 (przynajmniej tak mi się wydaje ponieważ wyskakuje komuniktat "readlb entry not found" oraz, że pomieszałem typy procków). Sęk w tym że nawet nie ruszałem fusebitów... Ba nawet nie zdążyłem załączyć funkcji programowania- ustawiłem sobie tylko w ustawieniach opcje "Program after compile" oraz "upload code and data" no ale chyba to nie jest przyczyną- przecież proces programowania nie ingerowałby w fusebity- zostałyby one w domyślnej konfiguracji.
A korzystając z okazji to chciałem (na przyszłość) zapytać jaką kolejność wykonywania czynności polecacie, żeby takich sytuacji uniknąć?? Chodzi mi o to czy np. zaraz po włożeniu układu do podstawki załączyć Bascoma i skonfigurawać same fuse bity czy może pierwszym razem nie włączać funkcji automatycznego programowania??
I ostatnie pytanie: jak to jest, że w AVT-3500 złącze SPI jest podłączone do innych pinów niż jest to ustawione (domyślnnie) w Bascomie a pomimo to układy się programują ( np. programy z kursu mikroprocesorowa ośla łączka na układ AT90s2313)?
Dziękuję za pomoc i pozdrawiam.
Programowanie automatyczne akurat nie powinno mieć tu żadnego znaczenia; to jest jedynie kasowanie-zapis-odczyt obu pamięci (FLASH i EEPROM) przy pomocy jednego kliknięcia. To wszystko można też robić ręcznie.gwozdex pisze:A korzystając z okazji to chciałem (na przyszłość) zapytać jaką kolejność wykonywania czynności polecacie, żeby takich sytuacji uniknąć?? Chodzi mi o to czy np. zaraz po włożeniu układu do podstawki załączyć Bascoma i skonfigurawać same fuse bity czy może pierwszym razem nie włączać funkcji automatycznego programowania??
Na początku zazwyczaj ustawia się wszystkie niezbędne fusebity dotyczące np. źródła taktowania i innych ważnych rzeczy, które znacząco zmieniają sposób pracy mikrokontrolera. Jeżeli chcesz się np. nim pobawić to na początku odpowiednio ustawiasz fusy. Jeżeli to jest jużgotowy projekt, wgrywasz program i wtedy przestawiasz potrzebne bity konfiguracyjne. Właściwie to nie ma jakiegoś ścisłego przepisu co należy najpierw zrobić, wszystko zależy od sytuacji. Fusebity można też przestawiać programowo.
Nie można przecież zmnienić pinów programujących. Są przydzielone "na stałe". Moduł SPI to już inna sprawa.I ostatnie pytanie: jak to jest, że w AVT-3500 złącze SPI jest podłączone do innych pinów niż jest to ustawione (domyślnnie) w Bascomie a pomimo to układy się programują ( np. programy z kursu mikroprocesorowa ośla łączka na układ AT90s2313)?
Dziękuję za pomoc i pozdrawiam.
P.S. Zablokowanego ATtiny2313 można obudzić poprzez podanie sygnału taktującego (1MHz) na nóżkę XTAL1.
- gwozdex
- Użytkownik
- Posty: 879
- Rejestracja: 24 lut 2006, 10:04
- Lokalizacja: Czechowice-Dziedzice
- Kontakt:
Chyba trochę się pospieszyłem...
We wcześniejszym poście nie wspomniałem, że problem wystąpił na nowo zainstalowanej wersji BASCOMA. Poprzednia wersja nie nastręczała mi żadnych problemów.
Po podłączeniu mojego układu ( na procesorze ATmeg162) i próbie wgrania do niego programu otrzymywałem takie same komunikaty jak w poprzednim przypadku. Przeprogramowanie fuse bitów nie wchodzi w grę gdyż w programie jest dyrektywa ($prog o ile się nie mylę) z wygenerowanymi ustawieniami "fusów". układ ten (program) kilkakrotnie wgrywałem i nigdy nie było problemów.
We wcześniejszym poście nie wspomniałem, że problem wystąpił na nowo zainstalowanej wersji BASCOMA. Poprzednia wersja nie nastręczała mi żadnych problemów.
Po podłączeniu mojego układu ( na procesorze ATmeg162) i próbie wgrania do niego programu otrzymywałem takie same komunikaty jak w poprzednim przypadku. Przeprogramowanie fuse bitów nie wchodzi w grę gdyż w programie jest dyrektywa ($prog o ile się nie mylę) z wygenerowanymi ustawieniami "fusów". układ ten (program) kilkakrotnie wgrywałem i nigdy nie było problemów.
-
ZbeeGin
I właśnie zastosowanie tej dyrektywy powoduje także z automatu zmianę także bitów konfiguracji podczas programowania. Miała ona być ułatwieniem dla użytkowników programujących procesory seryjnie.gwozdex pisze:Przeprogramowanie fuse bitów nie wchodzi w grę gdyż w programie jest dyrektywa ($prog o ile się nie mylę) z wygenerowanymi ustawieniami "fusów". układ ten (program) kilkakrotnie wgrywałem i nigdy nie było problemów.
I teraz wystarczy, by odpowiedzieć na pytanie zadawane czasami przez kompilator "Leave old CFG file" przy tworzeniu nowego programu twierdząco, a stan fusebit będzie przetransportowany z innego układu. I tu może się taki właśnie problem pojawić.Every time you program the chip, it will check the lock and fuse bit settings and will change them if needed.
Za każdym razem jak programujesz układ, sprawdzane jest ustawienie fuse bitów i zabezpieczających, i w razie potrzeby są one zmieniane.
So in a new chip, the lock and fuse bits will be set automatically. A chip that has been programmed with the desired settings will not be changed.
Zatem w przypadku nowego układu, bity zabezpieczające i fuse bity będa ustawione automatycznie. Układ który został już zaprogramowany z takimi ustawieniami nie będzie zmieniany.
Zatem najlepiej wszystko określić w dyrektywach w programie i odpowiadać nie na zadane j.w. pytanie.