Autor: tmf
Redakcja: Dondu
- RESET
- MISO
- MOSI
- SCK
Najlepiej jeśli w docelowym układzie piny ISP nie będą współdzielone z innymi elementami układu. Nie zawsze jednak jest to możliwe ani celowe. Jeśli piny ISP chcemy wykorzystać także do innych celów, musimy pamiętać o paru prostych zasadach.
Stosunkowo najprościej jest z linią RESET – jest ona w układzie rzadko wykorzystywana, chociaż niektóre procesory AVR pozwalają na jej wykorzystanie jako zwykłej linii I/O – w takiej sytuacji tracimy jednak możliwość programowania poprzez zwykły interfejs ISP – taki procesor można programować wyłącznie programatorem wysokonapięciowym.
Jednak użytkownicy często podłączająją pod ten pin dodatkowe rezystory podciągające, mające zwiększyć odporność układu na zakłócenia. Należy pamiętać, aby wartość tego rezystora nie była mniejsza niż 4k7 (niższa uniemożliwi programowanie ISP przez większość programatorów), lub niższa niż 10k w przypadku wykorzystania DebugWire (jest to dokładnie opisane w nocie AVR042). Więcej na ten temat znajdziesz tutaj: Minimalne podłączanie pinów mikrokontrolerów
A co z pozostałymi pinami?
W innym artykule opisałem ich wykorzystanie w systemach, w których interfejs ISP jest współdzielony z interfejsem SPI: Interfejs SPI, a sprawa ISP.
Czasami jednak pod piny ISP podłączamy inne urządzenia, niekoniecznie cyfrowej natury. Kiedy jest to bezpieczne?
Z pewnością nie należy:
Podłączać do tych pinów kondensatorów. Pojemności do kilku nF w zasadzie są akceptowalne, lecz prawdopodobnie wymuszą znaczne spowolnienie transmisji ISP – driver programatora będzie potrzebował więcej czasu na przeładowanie tych pojemności, zwolni się szybkość opadania/narastania zboczy. Czasami celowo wprowadza się dodatkowe kondensatory o pojemności kilkudziesięciu-kilkuset pF dla zwiększenia odporności na zakłócenia – szczególnie na linii SCK.
Podłączać wyjść jakichkolwiek układów – uniemożliwi to sterowanie stanem tych linii przez programator lub procesor. Jeśli chcemy podłączyć jakieś wyjścia to muszą to być wyjścia trójstanowe, które w sytuacji kiedy RESET jest aktywny przejdą w stan wysokiej impedancji, co umożliwi uniknięcie konfliktu. Co prawda Atmel dopuszcza inne rozwiązanie – wstawienie pomiędzy ISP a wyjście szeregowych rezystorów, jednak powoduje to powstanie dzielnika, w którym finalny stan na danym pinie zależy od „siły” wyjść dwóch układów. Należy to rozwiązanie traktować raczej jako zabezpieczenie, niż rozwiązanie problemu.
Obciążać wyjść ISP odbiornikami o znacznym poborze prądu. Znaczny pobór w tej sytuacji w praktyce oznacza nawet kika mA – np. diody LED, przekaźniki. Jeśli zachodzi taka konieczność należy pomiędzy pinem a resztą ukłądu wstawić bufor.
Musimy także pamiętać, że na liniach ISP w trakcie programowania pojawiają się przebiegi zmienne, stąd też inne układy współdzielące te linie muszą być tak zaprojektowane, aby im to nie przeszkadzało.
Kilka typowych błędów i potencjalnych rozwiązań pokazałem na poniższych schematach.
Podłączenie kondensatora C1 do linii SCK w sytuacji, kiedy ma on znaczną pojemność uniemożliwi to lub zwolni programowanie. Należy tego bezwzględnie unikać.
Kolejny przykład to podłączenie diody LED do linii wykorzystywanej podczas programowania ISP – dioda stanowi istotne obciążenie linii, w efekcie jej stan nie będzie ustalał się dostatecznie szybko i programowanie może być niemożliwe (to jednak zależy od wydajności prądowej wyjść programatora i procesora).
Kolejny problem to podłączenie pod linie ISP jakiegoś wyjścia (niekoniecznie cyfrowego, jak na rysunku poniżej). Wyjście bufora na stałe wysteruje linię SCK powodując konflikt z programatorem.
Ostatni przykład nie jest zasadniczo błędem, ale jest raczej dosyć nieszczęśliwym rozwiązaniem. W trakcie programowania, zmienny sygnał na linii SCK będzie powodował „kłapanie” przekaźnika. Właściwie to ze względu na prędkość jego zmian przekaźnik będzie sterowany niższym napięciem, zależnym od wypełnienia sygnału SCK, w efekcie jego stan będzie nieustalony.
Pamiętajmy też o kilku ogólnych zasadach:
1. Masy programowanego urządzenia i programatora muszą być połączone. Powoduje to, że masa programowanego układu połączona jest z masą komputera, a ta z kolei w przypadku braku zerowania komputera ma potencjał ok 115V. W skrajnych sytuacjach może to spowodować nieprzyjemne „kopnięcie” oraz uszkodzenie układu. Problem rozwiązuje zastosowanie programatora z optoizolacją, ale to podraża jego koszty. Pamiętajmy więc aby zawsze zerować komputer, szczególnie jeśli programowany układ ma własne, nie izolowane od sieci zasilanie.
2. W przypadku programatorów mogących programować układy zasilane napięciem w szerokim zakresie, to programowany układ zasila bufory wyjściowe programatora.
3. Niektóre programatory (głównie USB) posiadają możliwość zasilania programowanego układu. Tego typu programatory zazwyczaj posiadają zworkę określającą tryb pracy – albo programowany układ jest zasilany z programatora, albo możliwość taka jest wyłączona. Należy pamiętać o prawidłowym ustawieniu tej zworki w sytuacji, kiedy programowany układ ma własne zasilanie – bezwzględnie należy wtedy wyłączyć możliwość zasilania z USB.
Pamiętajmy także, że wydajność prądowa portu USB jest ograniczona do 500 mA (USB 2.0) lub 900 mA (USB 3.0). Większość komputerów nie posiada jednak zabezpieczeń, co stwarza możliwość uszkodzenia USB w przypadku nadmiernego poboru prądu.
Zobacz także:
To ja jeszcze podrążę przypadek z pojemnością na linii. Jak temu sobie z tym radzić? Zworki ściągane na czas programowania? Może są jakieś "automagiczne" sztuczki jak z buforem trójstanowym? Może jeszcze inaczej?
OdpowiedzUsuńMając do dyspozycji tyle pinów IO, kondensatory muszą być akurat na tych od ISP? Chyba nie tędy droga.
OdpowiedzUsuńSpecjalnie dopisałem propozycję takiego artykułu, bo trafiłem na taki przypadek. Przykładowo Mega 48/88/168 ma OC2A na jednym pinie z MOSI, a ja chciałem tam umieścić bezpośrednio MOSFETa (logic level), dzięki temu oba 8-bitowe timery służyłyby mi do PWM, a trzeci, 16-bitowy, do innych zastosowań. Ja się obejdę używając akurat "niekonfliktowych" timerów, ale łatwo sobie wyobrazić, że ktoś chce użyć wszystkich sześciu kanałów do PWM, a wtedy klops (albo programowy PWM). Także chyba warto wspomnieć o rozwiązaniu nawet, jeśli ogranicza się ono do prostej zworki ściąganej przed programowaniem.
OdpowiedzUsuńW takiej sytuacji można dodać bufor (driver) do sterowania MOSFETEM, czy przeładowania pojemności jeśli tam ma być filtr. IMHO zworka to kiepski pomysł, bo trzeba ciągle coś przełączać, a w końcu pewnie i tak się o tym zapomni. Inna możliwość to wgranie bootloadera i potem programowanie nie przez ISP tylko dowolny inny interfejs. Taki bootloared np. na RS232 można zmieścić w kilkuset bajtach.
OdpowiedzUsuńDziękuję, o coś takiego mi właśnie chodziło. Bootloadera wcześniej nie brałem pod uwagę, ale RS232 i tak zamierzałem wykorzystać, więc pewnie tak zrobię. Teraz wystarczy jedynie dopisać tę informację do artykułu.
OdpowiedzUsuńTo ja mam takie pytanie. Czy w AtMedze8 MISO i MOSI mogą podczas prgramowania być podłączone do mostka H?
OdpowiedzUsuńWitam Kolegów. Co do problemów z programowaniem z wykorzystaniem ISP przy współdzieleniu tych linii przez inne układy to ja miałem 1 przypadek we wszystkich swoich projektach, gdy było to problemem. Jedne z wyprowadzeń współdzielone było z termometrem DS1820, który to odpowiadał sygnałem Presence na wygenerowane sygnały programowania w związku z czym programowanie stało się niemożliwe...robiw
OdpowiedzUsuńCytat: "To ja mam takie pytanie. Czy w AtMedze8 MISO i MOSI mogą podczas prgramowania być podłączone do mostka H? ".
OdpowiedzUsuńOdpowiem z opóźnieniem, ale może komuś się to przyda. Zdecydowanie odradzam! Sytuacja przypomina sytuację opisaną w artykule, w której pod te piny podpięty jest przekaźnik. Programować będzie się dało, ale co z błędnym sterowaniem mostka? W szczególności co jeśli na raz otwarte zostaną oba (górny i dolny) tranzystory? Będzie dym.
Żeby się nie zakłócać można zastosować zwykły multiplekser 4053, wtedy sygnałem LED z pinu nr 3 złącza kanda 10pin można wysterować tak 4053 aby na czas programowania nie zakłócało nic inne w układzie. Pytanie tylko czy każdy programator coś podaje na 3 pin led, ja mam UsBasp (samoróbka kogoś) i STK200 na LPT i żaden nie obsługuje prawidłowo pinu 3 tzn nic się tam nie dzieje. Czy ktosik napotkał się na podobny problem?
OdpowiedzUsuńPin nr 3 w złączu ISP 10-pinowym jest niewykorzystany i niepodłączony (NC). Trudno więc go wykorzystać do sterowania czymkolwiek. Potencjalnie można wykorzystać sygnał reset, wiadomo, że w czasie programowania ma stan niski, a w czasie normalnej pracy - wysoki. Zostało to zresztą w powyższych przykładach pokazane.
OdpowiedzUsuńJa sobie poradziłem z podpięciem ISP w ten sposób, że piny te służą do komunikacji z LCD, które jest podpinane pod złącze. Wystarczy podpiąć złącze na czas programowania i już :D
OdpowiedzUsuńPytanie podstawowe: Chce wykorzystać wszystkie linie portu C w ATmedze8 oprócz resetu (PC6). Czy jeżeli ustawie "DDRC=0b00111111" (czyli na PC6 jest 0) to zablokuję sobie uC?
OdpowiedzUsuńNie, gdyż twoje ustawienie będzie działać aż do aktywacji sygnału RESET. W momencie jego aktywacji to co ustawiłeś programowo jest bez znaczenia.
OdpowiedzUsuńStary temat ale też się ten problem też mnie trochę pomęczył i "rozwiązałem" go w nie podany tu sposób (mocno "na chłopski rozum" ale zadziałał).
OdpowiedzUsuńOtóż robiłem LEDCube 4x4x4 sterowanego ATTiny85 - z oczywistych względów musiałem używać MOSI, MISO, SCK (przy 6 pinach, z czego jeden to RESET nie można wybrzydzać :) ). Po złożeniu całej sterującej elektroniki na płytce stykowej nie mogłem programować układu - jak przekładałem go obok to działało - ale było to upierdliwe i pomyślałem, że ta elektronika dwa 8-bitowe rejestry 595, i jeden licznik dziesiętny (które rozmnożyły mi 5 wyjść na 20 :) ) pobierają za dużo prądu (czyt. brużdżą - wspomniany wyżej chłopski rozum). Podłączyłem więc 2 diody do zasilania, w ten sposób, że programator zasilał tylko i wyłącznie ATTiny, a reszta jak nawet dostawała sygnały (na liniach MOSI, MISO, SCK) to nie powinna jakoś strasznie szaleć bez zasilania. Takie moje rozumowanie i 2 diody później mogłem programować mojego ATTiny "In System" - można powiedzieć "I wszyscy żyli długo i szczęśliwie", ale nie widzę takiego rozwiązania tutaj, a wydaje mi się dość proste, a skuteczne.
Dlatego pytanie do Was - Co mi uciekło? bo nie wierzę że nikt na coś takiego nie wpadł - czyt. musi być jakaś straszna wada tego rozwiązania (ograniczającego propagacje VCC jak i GND). Pewno reszta może się zachować w sposób "nieoznaczony", ale i tak - jak na super proste rozwiązanie - IMO warto.
Wadą tej metody jest to, że niezasilany scalak jest zasilany pasożytniczo z magistrali cvo grozi jego uszkodzeniem. Dlatego nie jest to metoda, którą można polecać.
Usuń