-
71. Data: 2013-01-10 20:56:39
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Atlantis <m...@w...pl>
W dniu 2013-01-10 19:09, Grzegorz Niemirowski pisze:
> Jakby kompilator ustawiał wartość wejścia, to to już przestałoby być
> wejście, tylko by było zwykłe wyjście. Użytkownik też nic nie robi.
> Wejście jest wejściem dlatego, że stan jest wyznaczany przez czynniki
> zewnętrzne. Po co Ci wejście, na którym możesz coś ustawić?
Miałem na myśli wewnętrzny pull-up albo pull-down ustawiany za pomocą
odpowiedniego bitu rejestru PORTx. Podstawowy przykład - weźmy linię
PB0. W rejestrze DDRB ustawiam 0 (wejście), w PORTB 1 (podciągnięcie do
VCC). Linię łączę przez switcha do masy. Przy każdym wciśnięciu
odpowiedni bity rejestru PINB przyjmie wartość 0, po zwolnieniu powróci
do 1.
> Np. gdy w jakichś sytuacjach do wejścia nie jest nic podłączone.
To wiem, czytałem o tym już w kilku różnych tutorialach. Przy czym
zwykle chodziło o wewnętrzny pull-up, a nie stosowanie zewnętrznego
rezystora. Swoją drogą czym grozi brak takiego podciągnięcia, skoro i
tak takich linii się nie odczytuje?
Mi jednak chodziło o sytuacje, kiedy do tej linii COŚ JEST PODŁĄCZONE -
i mam tu na myśli jakieś urządzenie przesyłające dane. Czasem widziałem
takie zalecenia. Na przykład zobacz tutaj:
http://mikrokontrolery.blogspot.com/2011/03/podlacze
nie-karty-pamieci-sd.html
Zarówno karta jak i uC są zasilane napięciem 3,3V. Linie komunikacyjne
podciągnięte do VCC rezystorami, co ma zapobiec stanom nieustalonym.
Czy stosowanie takiego rozwiązania, albo ustawienie wewnętrznego
pull-upu jest wskazane przy podłączaniu modułów USART albo SPI?
>> Słyszałem też głosy mówiące, że uC powinien być połączony z modułem za
>> pośrednictwem szeregowych rezystorów. Rozwiązanie wskazane czy nie?
>
> Jeśli są zasilane różnymi napięciami.
Ja właśnie spotkałem się raz z takim zaleceniem odnośnie przypadku, gdy
urządzenia są zasilane tym samym napięciem.
W przypadku różnych napięć chyba lepiej stosować dzielniki, diodę zenera
+ rezystor, tudzież bufor OC z rezystorem do odpowiedniej linii
zasilania na wyjściu...
-
72. Data: 2013-01-10 21:17:35
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: "Grzegorz Niemirowski" <g...@p...onet.pl>
Atlantis <m...@w...pl> napisał(a):
> Miałem na myśli wewnętrzny pull-up albo pull-down ustawiany za pomocą
> odpowiedniego bitu rejestru PORTx. Podstawowy przykład - weźmy linię PB0.
> W rejestrze DDRB ustawiam 0 (wejście), w PORTB 1 (podciągnięcie do VCC).
> Linię łączę przez switcha do masy. Przy każdym wciśnięciu odpowiedni bity
> rejestru PINB przyjmie wartość 0, po zwolnieniu powróci do 1.
Więc jak widzisz kontrolowane jest to przez rejestry. Wartości rejestrów są
ustawiane przez układ resetujący. A więc tak, mają wartość domyślną ustaloną
przez ten układ (zwykle zera).
> To wiem, czytałem o tym już w kilku różnych tutorialach. Przy czym zwykle
> chodziło o wewnętrzny pull-up, a nie stosowanie zewnętrznego rezystora.
> Swoją drogą czym grozi brak takiego podciągnięcia, skoro i tak takich
> linii się nie odczytuje?
Śmieci mogą prowadzić do częstego przełączania się tranzystorów w układzie
generując kolejne zakłócenia i zwiększając pobór prądu.
> Mi jednak chodziło o sytuacje, kiedy do tej linii COŚ JEST PODŁĄCZONE - i
> mam tu na myśli jakieś urządzenie przesyłające dane. Czasem widziałem
> takie zalecenia. Na przykład zobacz tutaj:
> http://mikrokontrolery.blogspot.com/2011/03/podlacze
nie-karty-pamieci-sd.h
> tml
> Zarówno karta jak i uC są zasilane napięciem 3,3V. Linie komunikacyjne
> podciągnięte do VCC rezystorami, co ma zapobiec stanom nieustalonym.
> Czy stosowanie takiego rozwiązania, albo ustawienie wewnętrznego pull-upu
> jest wskazane przy podłączaniu modułów USART albo SPI?
Nie zaszkodzi. Zapewne chodzi o sytuację, gdy układ zarządzający szyną
danych nie wysterował jeszcze wyjść i układ odbierający może odebrać
jakiegoś śmiecia. Chodzi generalnie o to, żeby wejście nie pozostawało
niepodłączone. A jeśli jest podłączone do czegoś, co znajduje się w jakimś
momencie w stanie wysokiej rezystancji, to tak jakby było niepodłączone.
Dlatego takie podciągnięcie stosuje się dla bezpieczeństwa.
>>> Słyszałem też głosy mówiące, że uC powinien być połączony z modułem za
>>> pośrednictwem szeregowych rezystorów. Rozwiązanie wskazane czy nie?
>> Jeśli są zasilane różnymi napięciami.
> Ja właśnie spotkałem się raz z takim zaleceniem odnośnie przypadku, gdy
> urządzenia są zasilane tym samym napięciem.
> W przypadku różnych napięć chyba lepiej stosować dzielniki, diodę zenera +
> rezystor, tudzież bufor OC z rezystorem do odpowiedniej linii zasilania na
> wyjściu...
Chodziło mi dokładniej o przypadek, gdy niby jest to samo napięcie, ale z
różnych źródeł. Jeśli masz dwa zasilacznie na np. 3,3V, to zawsze jeden
będzie dawać napięcie trochę inne niż drugi. Wtedy przez linie danych mogą
płynąć prądy i doprowadzić do nieprawidłowego działania układu. Miałem taki
przypadek z przejściówką RS232-USB wykonaną na ATmega88. Ona była zasilana z
USB przez czerwonego LEDa, co dawało właśnie ok. 3,3V. Podłączenie do innego
układu zasilanego własnym napięciem (ale też 3,3V) powodowało zawieszenie
się mikrokontrolera. Rezystory rozwiązywały problem.
W przypadku różnych napięć (np. 3,3 i 5) oczywiście dzielnik/bufor, tak jak
napisałeś.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 2 hours, 17 minutes and 41 seconds
-
73. Data: 2013-01-10 21:45:49
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Atlantis <m...@w...pl>
W dniu 2013-01-10 21:17, Grzegorz Niemirowski pisze:
> Nie zaszkodzi. Zapewne chodzi o sytuację, gdy układ zarządzający szyną
> danych nie wysterował jeszcze wyjść i układ odbierający może odebrać
> jakiegoś śmiecia. Chodzi generalnie o to, żeby wejście nie pozostawało
> niepodłączone. A jeśli jest podłączone do czegoś, co znajduje się w
> jakimś momencie w stanie wysokiej rezystancji, to tak jakby było
> niepodłączone. Dlatego takie podciągnięcie stosuje się dla bezpieczeństwa.
Fakt, że napięcia na liniach są z reguły nieco niższe od tego na VCC nie
stwarza tutaj żadnej przeszkody ani niebezpieczeństwa dla układu?
Tak właśnie sobie przypomniałem, że eksperymentując nad moim projektem
natknąłem się na pewien problem, który może mieć z tym coś wspólnego -
mianowicie po przejściu procedury włączenia modemu ustawiłem pętlę
while, która miała zatrzymać program dopóki na linii DSR istniał stan
wysoki. Po pojawieniu się zera (gotowość modułu do nawiązania
komunikacji przez USART) program miał przejść do wysyłania komunikatów.
Niestety program się wysypywał. Wyglądało to tak, jakby pętla w ogóle
nie działała i program od razu przystępował do wysyłania komend. Nie
otrzymawszy odpowiedzi zwracał kod błędu. Nie zastanawiałem się wtedy
nad tym głębiej, przechodząc do innych prób (prowizorycznie dałem tam po
prostu odpowiednio długi _delay_ms). Może tam przez moment na tej linii
był właśnie stan nieustalony?
> Chodziło mi dokładniej o przypadek, gdy niby jest to samo napięcie, ale
> z różnych źródeł. Jeśli masz dwa zasilacznie na np. 3,3V, to zawsze
> jeden będzie dawać napięcie trochę inne niż drugi.
Czyli jeśli będę zasilał zarówno moduł jak i uC z tego samego
stabilizatora albo akumulatorka, to problem raczej nie wystąpi i mogę
spokojnie połączyć odpowiadające sobie linie krótkimi ścieżkami, bez
żadnych elementów pośredniczących?
-
74. Data: 2013-01-10 21:58:15
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: "Grzegorz Niemirowski" <g...@p...onet.pl>
Atlantis <m...@w...pl> napisał(a):
> Fakt, że napięcia na liniach są z reguły nieco niższe od tego na VCC nie
> stwarza tutaj żadnej przeszkody ani niebezpieczeństwa dla układu?
W jaki sposób? Z resztą, przecież linie służą też do transmisji zer, czyli
napięć bliskich zeru. Poza tym o to chodzi w cyfrowej transmisji danych, że
napięcie nie musi być idealne. Problem jest, jak napięcie na linii danych
jest wyższe niż VCC. Niepożądane są też napięcia w okolicach progu
przełączania, pomiędzy zerem a jedynką. No ale to oczywiste.
> Tak właśnie sobie przypomniałem, że eksperymentując nad moim projektem
> natknąłem się na pewien problem, który może mieć z tym coś wspólnego -
> mianowicie po przejściu procedury włączenia modemu ustawiłem pętlę while,
> która miała zatrzymać program dopóki na linii DSR istniał stan wysoki. Po
> pojawieniu się zera (gotowość modułu do nawiązania komunikacji przez
> USART) program miał przejść do wysyłania komunikatów.
> Niestety program się wysypywał. Wyglądało to tak, jakby pętla w ogóle nie
> działała i program od razu przystępował do wysyłania komend. Nie
> otrzymawszy odpowiedzi zwracał kod błędu. Nie zastanawiałem się wtedy nad
> tym głębiej, przechodząc do innych prób (prowizorycznie dałem tam po
> prostu odpowiednio długi _delay_ms). Może tam przez moment na tej linii
> był właśnie stan nieustalony?
Tutaj pomocny będzie oscyloskop. Ustawiasz sobie wyzwalanie zboczem, sweep
na single i odpalasz. Oscyloskop przechodzi w tryb czuwania i czeka na
zbocze. Gdy się pojawi, zapamiętuje je i wyświetla. Możesz w ten sposób
sobie złapać pojedynczy impuls.
> Czyli jeśli będę zasilał zarówno moduł jak i uC z tego samego
> stabilizatora albo akumulatorka, to problem raczej nie wystąpi i mogę
> spokojnie połączyć odpowiadające sobie linie krótkimi ścieżkami, bez
> żadnych elementów pośredniczących?
Ogólnie tak.
Problem możesz mieć, jeśli w układzie będzie coś, co będzie pobierało bardzo
dużo prądu, a zasilanie będzie szło cienkimi ścieżkami, co spowoduje spadki
napięć. Ale generalnie tego typu problemu dręczą projektantów układów
analogowo-cyfrowych, w których część analogowa jest wrażliwa na spadki
napięć generowane przez część cyfrową. Więc to tak tylko przy okazji
wspominam.
Jak masz układ cyfrowy, który pobiera kilka-kilkanaście mA, a ścieżki są
poprowadzone z głową, to nie ma się czym przejmować.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 3 hours, 7 minutes and 16 seconds
-
75. Data: 2013-01-11 10:40:28
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Piotr Gałka <p...@C...pl>
Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kcmvnv$u5q$1@portraits.wsisiz.edu.pl...
>
> Słyszałem też głosy mówiące, że uC powinien być połączony z modułem za
> pośrednictwem szeregowych rezystorów. Rozwiązanie wskazane czy nie?
>
Jest tak:
- konkurencja w produkcji scalaków zmusza wszystkich producentów do
produkcji taniej, taniej i jeszcze raz taniej,
- im więcej chipów na płytce krzemu w produkcji tym taniej,
- więcej chipów na płytce = większe płytki i coraz mniejsze elementy,
- mniejsze rozmiary elementów -> mniejsze pojemności,
- mniejsze pojemności -> krótsze czasy przełączania,
- zauważ, że w katalogu podawany jest maksymalny czas narastania/opadania
sygnału na wyjściu, a nie jest podany minimalny,
- efekt - ten sam scalak (np. ze starej serii HC) obecnie produkowany może
mieć 10 razy stromsze zbocza niż taki sprzed 20 lat,
I teraz rozgałęzienie na dwa tematy:
1. Ground bounce
- struktura scalaka jest podłączona do pinu GND jakimś drucikiem o
niezerowej L,
- bufor wyjściowy musi przeładować pojemności zewnętrzne,
- przez ten przewód o indukcyjności L przepływają impulsy o czasach
narastania poniżej ns,
- efekt - na wyjściu bufora pojawiają się napięcia poniżej GND i powyżej
VCC,
- te przepięcia powodują przepływ impulsów prądu przez obwody
zabezpieczające wejścia drugiego scalaka,
- impulsy prądu są źródłem emisji zakłóceń,
- nie wiem jaki jest wpływ na przykład na trwałość obwodów zabezpieczających
wejścia i czy w skrajnych sytuacjach nie może prowadzić do latch-up,
- rezystor szeregowy zmniejsza pojemność do przeładowania natychmiast (o
pojemność ścieżki i wejścia) zmniejszając te impulsy,
- poza tym rezystor szeregowy ogranicza prąd w obwodach zabezpieczających.
2. Linie długie
- o tym, czy ścieżka jest linią długą nie decyduje częstotliwość sygnałów, a
stromość zboczy,
- obecnie nawet 5cm ścieżka może już być linią długą,
- niedopasowana linia długa = odbicia, emisja zakłóceń, wrażliwość na
zakłócenia (a zakłóceń obecnie bardzo dużo - kiedyś nie było komórek),
- rezystor szeregowy o R zgodnych z Zo ścieżki tuż przy wyjściu scalaka to
jednostronne dopasowanie linii długiej (zbocze dzielone jest w R/Zo na pół,
potem odbijając się od wejścia jest podwajane (odbiorca widzi pełne zbocze),
wraca i już się nie odbija bo dopasowanie).
P.G.
-
76. Data: 2013-01-11 18:43:09
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Atlantis <m...@w...pl>
W dniu 2013-01-11 10:40, Piotr Gałka pisze:
> Jest tak:
> (...)
Hmm... Może w takim razie dobrym pomysłem byłoby (o ile tylko pozwala na
to ilość miejsca na PCB oraz poziom skomplikowania układu) stosowanie
buforów z otwartym kolektorem, z wyjściem podciągniętym do VCC? Nawet
wtedy, jeśli peryferia pracują na tym samym napięciu co uC.
Takie rozwiązanie ogólnie zwiększy bezpieczeństwo układów (np. względem
możliwości wystąpienia latch-upu) i poprawi jakość transmisji?
Czy to już jednak będzie overkill?
-
77. Data: 2013-01-11 18:56:11
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: "Grzegorz Niemirowski" <g...@p...onet.pl>
Atlantis <m...@w...pl> napisał(a):
> Hmm... Może w takim razie dobrym pomysłem byłoby (o ile tylko pozwala na
> to ilość miejsca na PCB oraz poziom skomplikowania układu) stosowanie
> buforów z otwartym kolektorem, z wyjściem podciągniętym do VCC? Nawet
> wtedy, jeśli peryferia pracują na tym samym napięciu co uC.
> Takie rozwiązanie ogólnie zwiększy bezpieczeństwo układów (np. względem
> możliwości wystąpienia latch-upu) i poprawi jakość transmisji?
> Czy to już jednak będzie overkill?
A jak się ten pomysł ma do tego, co napisał Piotr, np. stromych zboczy i
przepięć? Zysk byłby połowiczny, bo tylko przy zboczach narastających.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 2 hours, 26 minutes and 23 seconds
-
78. Data: 2013-01-11 21:08:07
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Atlantis <m...@w...pl>
W dniu 2013-01-10 21:58, Grzegorz Niemirowski pisze:
> Tutaj pomocny będzie oscyloskop. Ustawiasz sobie wyzwalanie zboczem,
> sweep na single i odpalasz. Oscyloskop przechodzi w tryb czuwania i
> czeka na zbocze. Gdy się pojawi, zapamiętuje je i wyświetla. Możesz w
> ten sposób sobie złapać pojedynczy impuls.
Niestety, może się mylę, ale wydaje mi się, że moim oscyloskopem czegoś
takiego zrobić nie mogę. To leciwy KR-7010. Chyba jest w stanie tylko
wyświetlać przebieg na bieżąco, ale już nie zapamiętać jeden impuls... A
może się mylę?
-
79. Data: 2013-01-14 09:39:48
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: g...@s...invalid (Adam Wysocki)
Atlantis <m...@w...pl> wrote:
> BTW jak zachowa się uC AVR, jeśli na początku programu nie ustalimy
> stanu wejścia podciągając go do plusa lub masy przez wpisanie
> odpowiedniej wartości do PORTx?
Float.
Dla DDR=0 PORT nie podciąga do masy.
DDR=0 PORT=0 to float, wysoka impedancja.
--
Gof
http://www.chmurka.net/
-
80. Data: 2013-01-14 09:41:20
Temat: Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Od: Piotr Gałka <p...@C...pl>
Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kcpivn$2ar$1@portraits.wsisiz.edu.pl...
>W dniu 2013-01-11 10:40, Piotr Gałka pisze:
>
>> Jest tak:
>> (...)
>
> Hmm... Może w takim razie dobrym pomysłem byłoby (o ile tylko pozwala na
> to ilość miejsca na PCB oraz poziom skomplikowania układu) stosowanie
> buforów z otwartym kolektorem, z wyjściem podciągniętym do VCC? Nawet
> wtedy, jeśli peryferia pracują na tym samym napięciu co uC.
> Takie rozwiązanie ogólnie zwiększy bezpieczeństwo układów (np. względem
> możliwości wystąpienia latch-upu) i poprawi jakość transmisji?
> Czy to już jednak będzie overkill?
Dokładanie czegoś więcej niż jeden rezystor to chyba przesada. Szyny
szeregowe to tylko kilka drutów. Ja tam (na wszelki wypadek) nie żałuję tych
kilku 0402 (do 0201 jeszcze nie doszedłem).
P.G.