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.

do góry

On Sun, 23 Dec 2012 15:42:06 +0100, Atlantis <m...@w...pl>
wrote:
> przeinaczony znak) uniemożliwi jego normalne wyczyszczenie?
Normalnie w

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

do góry

On Sun, 23 Dec 2012 23:45:55 +0100, Marek <f...@f...com> wrote:
> się po OK ostatniego pol

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

--
Marek

do góry

Dnia Sun, 23 Dec 2012 23:45:55 +0100, Marek napisał(a):
> On Sun, 23 Dec 2012 15:42:06 +0100, Atlantis <m...@w...pl>
>> przeinaczony znak) uniemożliwi jego normalne wyczyszczenie?
> Po co w ogóle chcesz czyścić bufor? W normalnym korzystaniu nie ma
> takiej potrzeby,

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.

do góry

On Mon, 24 Dec 2012 11:39:17 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Musi jednak jakos lapac dane do porownania, zeby rozne smieci nie
zaklocily
> przetwarzania.
Nie wiem jakie śmieci masz na myśli.
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

do góry

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.

do góry

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

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?

do góry

Atlantis <m...@w...pl> napisał(a):
> 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?

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

do góry

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

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

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?

do góry

Atlantis <m...@w...pl> napisał(a):
> Gdyby np. kompilator ustawiał jakąś domyślną wartość wejścia w przypadku,
> gdyby użytkownik tego nie zrobił.

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

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

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

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

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

do góry