między Atmegą a modułem G

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

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

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.

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.

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.

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:

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?

Atlantis snipped-for-privacy@wp.pl napisał(a):

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

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?

Atlantis snipped-for-privacy@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.

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kcmvnv$u5q$ snipped-for-privacy@portraits.wsisiz.edu.pl...

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.

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

W dniu 2013-01-11 10:40, Piotr Gałka pisze:

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?

Atlantis snipped-for-privacy@wp.pl napisał(a):

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.

Float.

Dla DDR=0 PORT nie podciąga do masy.

DDR=0 PORT=0 to float, wysoka impedancja.

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kcpivn$2ar$ snipped-for-privacy@portraits.wsisiz.edu.pl...

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.

Zwiększony pobór prądu. Bufor cyfrowy nadal jest aktywny.