Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Attiny13a Fuse SPIEN nie działa

Modecom601 11 Maj 2012 23:19 1165 4
  • #1 11 Maj 2012 23:19
    Modecom601
    Poziom 13  

    Witam.
    Zakupiłem uC Attiny13a w wersji smd. Chcę wykorzystać piny programowania PB0,PB1 i PB2 do innych celów po ukończonym programie. Wgrałem już program burn-o-matem, następnie zakładka fusy, i odchaczenie i wgranie fusów bez SPIEN powoduje wyświetlenie komunikatu error reading fuses. Do procka podłączam się za pomocą usbasp MISO/MOSI/SCK/RESET/VCC/GND. Dodam, że zmiana innych fuse bitów działa np. wyłączyłem dla sprawdzenia kilkukrotnie fuse bit dzielnika zegara CKDIV8.
    Ustawienie PINB5 zamiast reset również działa, wrzucam na fuse doctora probóję dalej ale z spien nie chce się ustawić. Czy jest to coś związane z tym, że w burn-o-macie ustawilem typ avr attiny13 bez 'a'? W makefilu jest attiny13a(próbowałem bez 'a', ale bez rezultatów).

    Bardzo proszę o pomoc

    Pozdrawiam

    0 4
  • Pomocny post
    #2 11 Maj 2012 23:40
    piotrva
    Moderator na urlopie...

    1. Żadnemu procesorowi AVR nie da się przeprogramować fusebitu SPIEN za pomocą interfejsu SPI - innymi słowy nie można sobie samym interfejsem go zablokować.
    2. Nie wiem jaki jest sens takiego działania, RSTDSBL owszem, ponieważ inaczej pin ten działa jako RESET i tylko po zaprogramowaniu bitu można go wykorzystać jako I/O, ale pozostałe piny (SCK, MISO, MOSI) działają normalnie jako piny I/O, jeśli procesor nie jest w trybie programowania (czyli w uproszczeniu jeśli procesor nie jest w stanie resetu), więc nie wiem jaki jest sens walki z tym ustawieniem. Jeśli w jakiś sposób program nie działa ze względu na te linie to są chyba tylko 2 możliwe powody: a) programator masz do bani i nie zachowuje odpowiednich charakterystyk wysokiej impedancji po wyjściu z trybu programowania, lub soft z PC nie przełącza go w taki tryb -> rozwiązanie: odepnij programator. b) masz program napisany do bani i szukasz błędu tam gdzie go nie ma -> rozwiązanie: sprawdź dokładnie program

    Jeśli mimo wszystko się uprzesz na zmianę tego fusebitu (choć na 100% <<no może 99,999999%>> nie w tym leży problem - sam pracuję na t13(a) z podpiętym programatorem ISP i nie zakłóca on w żaden sposób działania linii MOSI, MISO i SCK) to zaktualizuj fusebit doctorka do najnowszej wersji, zdejmij zworkę Allow Erease i poprzez terminal RS232 wgraj fusebity manualnie.

    0
  • #3 11 Maj 2012 23:58
    Modecom601
    Poziom 13  

    Dzieki za odpowiedź
    " pozostałe piny (SCK, MISO, MOSI) działają normalnie jako piny I/O, jeśli procesor nie jest w trybie programowania"
    zawsze uważałem, że wykorzystanie tych pinów jako piny I/O będzie dopiero możliwe, po wyłączeniu SPIEN... to zmienia postać rzeczy i jednocześnie rozwiązuje mój problem brakujących pinów.

    To w takim razie fusebit SPIEN jest po to, by nie "ściągać" programu z urządzeń np. z pralek itp.? myślałem, że od tego są lockbity.

    EDIT. jeśli można jeszcze jedno pytanie zadać.
    Po skompilowaniu hexa winavr pokazuje mi objętość programu w bajtach i % zajętości procesora. Czym w takim razie jest Data, która u mnie wyniosła raz 120%?

    0
  • #4 12 Maj 2012 00:12
    piotrva
    Moderator na urlopie...

    Fusebit SPIEN wyłącza programowanie przez SPI, tyle i koniec. Nie daje to zabezpieczenia przed ściąganiem oprogramowania, bo jeśli nawet wyłączysz SPIEN, a nie dasz lockbitów to program nadal można ściągnąć programatorem wysokonapięciowym (np. AvrDragon).
    Data to sekcja zmiennych (pamięć RAM procesora). Jeśli wynosi 120% to znaczy, że zmiennych jest za dużo w stosunku do dostępnego ramu - taki program na 90% nie ma szans działać prawidłowo. Już przy wartościach rzędu 80-90% (w zależności od programu, tego jak w nim rośnie stos itp.) trzeba bardzo uważać, żeby stos nie wjechał na sekcję zmiennych, a co dopiero jak masz 120%...

    0
  • #5 12 Maj 2012 00:31
    Modecom601
    Poziom 13  

    POdczas czytania Twojego postu, wrzuciłem program z 120% Data, wyjechał program zwieszony jest. Tak coś mi się wydawało, że jakaś pamięć podręczna etc., bo wzrastało przy tworzeniu zmiennych i tablic, ale chciałem się upewnić od lepszych ;) Zaraz się biorę za optymalizację.

    Bardzo dziękuję za pomoc, nie wiem jak mogłem nie wiedzieć, że podczas normalnej pracy piny, na których jest MISO MOSI oraz SCK działają jako normalne porty I/O.

    Dziękuję
    Pozdrawiam

    0