Jak skutecznie rozwiązać problem komunikacji Atmegi z modułem GSM przez RS232?

Sun Dec 23, 2012 3:42 pm   

BTW mam jeszcze jedno pytanie o obsługę bufora odbiorczego.

Mianowicie jak uniknąć sytuacji, kiedy jakiś błąd transmisji (np.
przeinaczony znak) uniemożliwi jego normalne wyczyszczenie? Normalnie w
tym przypadku mamy do czynienia z dwiema sytuacjami:

1. Wysyłanie polecenia do modułu i oczekiwanie na odpowiedź. Tutaj mogę
wyczyścić bufor przed rozpoczęciem tej procedury i przed jej
zakończeniem (bez względu na to, czy wynik będzie pozytywny czy nie).

2. Bardziej kłopotliwa jest jednak druga sytuacja, mianowicie
oczekiwanie na konkretną wiadomość, wysłaną przez moduł w przypadku
konkretnego zdarzenia (np. "RING\r\n\r\n" przy połączeniu przychodzącym)
tutaj bufor mogę wyczyścić dopiero w przypadku rozpoznania właściwej
komendy. A co, jeśli do bufora przyjdzie coś innego? Wtedy po prostu
kolejny komunikat zostanie do niego doklejony...

Poprzednio, gdy analizowałem komunikaty linijka po linijce, przepisując
je do innej tablicy ten problem nie występował - przyjście kolejnej
linijki czyściło bufor z jego poprzedniej zawartości.

Czy istnieje jakiś sposób na nauczenie programu rozróżniania
poszczególnych komunikatów jako odrębnych całości, nawet jeśli składają
się z kilku linii? Jedyne rozwiązanie jakie w tej chwili przychodzi mi
do głowy, to zastosowanie timera, który cyklicznie czyściłby bufor,
zapobiegając "sklejeniu" dwóch komunikatów.

Sun Dec 23, 2012 11:45 pm   

On Sun, 23 Dec 2012 15:42:06 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Po co w ogóle chcesz czyścić bufor? W normalnym korzystaniu nie ma
takiej potrzeby, jedynie zagrożenie to nadpisanie danych, gdy za
wolno go czytasz (jest za mały).
Problem może nastąpić gdy dane beda się pojawiac niespodziewanie np.
RING w trakcie procesowania innej komend. O ile pamiętam RING pojawi
się po OK ostatniego pol

--
Marek

Sun Dec 23, 2012 11:50 pm   

On Sun, 23 Dec 2012 23:45:55 +0100, Marek <fake@fakeemail.com> wrote:

Urwało posta.. ostatniego polecenia więc wystarczy przed wysłaniem
kolejnego polecenia wysadzić czy czegoś nowego w buforze nie ma.

--
Marek

Mon Dec 24, 2012 11:39 am   

Dnia Sun, 23 Dec 2012 23:45:55 +0100, Marek napisał(a):

Musi jednak jakos lapac dane do porownania, zeby rozne smieci nie zaklocily
przetwarzania.
\r czy \n jest wystarczajace - je ignotujemy, ale one wyznaczaja kolejne
komunikaty.
Nawet jesli jakies smmieci przejda, to "ring" jest powtarzany za kazdym
dzwonkiem.
A inne ... timeout. Nie bylo potwierdzenia w stosownym czasie - powtarzamy.

J.

Mon Dec 24, 2012 4:41 pm   

On Mon, 24 Dec 2012 11:39:17 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:

Bufor cykliczny ma zapis i odczyt niezależny. Funkcja odczytu z
bufora pobieraja tylko te dane (z bufora), które nie zostały jescze
odebrane. Funkcja zapisujaca (przerwanie usarta) dodaje odebrane do
bufora i przesuwa wskaźnik odczytu dla funkcji czytujacej. Jeśli nic
nowego w buforze nie ma funkcja odczytyjaca zwraca null. Wtedy wiemy
ze bufor jest "pusty".
"Czyszczenie" bufora (jeśli w ogóle konieczne) robi się poprzez
zrownanie wskaźnika odczytu i zapisu (danych nie trzeba "zerować").
Jak już pisałem RING nie powinIen się pojawić z nienacka tzn. w
połowie odpowiedzi na poprzednie polecenie, ale tuż po jego
zakończeniu lub w trakcie przerwy między poleceniami. Wystarczy
pilnowac aby po każdej odpowiedzi lub przed nowym zapytaniem
sprawdzac czy w buforze nie pojawił się ring.

--
Marek

Wed Dec 26, 2012 11:24 am   

Tak swoją drogą, jeśli chodzi o programowanie AVR to (abstrahując od
tematu modułu GSM) jedno pytanie chodzi mi po głowie. Mianowicie do
jakiego stopnia trudności można zakwalifikować projekty wykorzystujące
moduły Ethernet? Takie konstrukcje widuje się od jakiegoś czasu coraz
częściej - czy to w postaci jakiegoś Arduino z odpowiednim shieldem czy
też układu zaprojektowanego zupełnie od podstaw.

To wyższa szkoła jazdy, wymagająca kilkuletniego doświadczenia czy może
nie jest aż tak źle? Istnieją gotowe rozwiązania, które pozwalałyby
ominąć programowanie obsługi TCP/IP? Załóżmy, że w grę wchodzi
transmisja niezbyt złożonych danych - np. telnet.

Wed Jan 09, 2013 8:16 pm   

Tak swoją drogą, jeśli chodzi o poziomy napięć pomiędzy modułem a Atmegą.

W nocie katalogowej modułu D15 znajduje się informacja, że sygnały są
buforowane przez MC74VHCT244.
Znajduje się tam także następujący schemat:

http://obrazki.elektroda.pl/2864570200_1357753039.png

Jak widać na liniach wejściowych, za buforami znajdują się dzielniki
napięcia.

Natomiast linie wyjściowe połączone są jedynie przez bufor. Nota o tym
co prawda nie wspomina, ale czy tam nie powinny się przypadkiem znaleźć
jakieś rezystory podciągające do VCC?

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? Przyjmie jakąś domyślną wartość czy też
jego stan będzie nieustalony?

Wed Jan 09, 2013 11:45 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

Nieustalony, będzie zbierać śmieci. Co rozumiesz przez wartość domyślną? Co
miałoby ją zmieniać?

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 7 hours, 4 minutes and 35 seconds

Thu Jan 10, 2013 7:02 pm   

W dniu 2013-01-09 23:45, Grzegorz Niemirowski pisze:


Gdyby np. kompilator ustawiał jakąś domyślną wartość wejścia w
przypadku, gdyby użytkownik tego nie zrobił.
Tak swoją drogą kiedy wskazane jest podciągnięcie linii do VCC przez
rezystor, a kiedy powinienem tego unikać? Oczywiście pomijając oczywiste
sytuacje, jak np. zastosowanie bufora z otwartym kolektorem.

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?

Thu Jan 10, 2013 7:09 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

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ć?


Np. gdy w jakichś sytuacjach do wejścia nie jest nic podłączone.


Jeśli są zasilane różnymi napięciami.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 0 hours, 25 minutes and 47 seconds

Thu Jan 10, 2013 8:56 pm   

W dniu 2013-01-10 19:09, Grzegorz Niemirowski pisze:


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.



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/podlaczenie-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?



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...

Thu Jan 10, 2013 9:17 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

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).


Ś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.


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.


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

Thu Jan 10, 2013 9:45 pm   

W dniu 2013-01-10 21:17, Grzegorz Niemirowski pisze:


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?


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?

Thu Jan 10, 2013 9:58 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

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.


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.


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

Fri Jan 11, 2013 10:40 am   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kcmvnv$u5q$1@portraits.wsisiz.edu.pl...

- 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.