Atlantis <m...@w...pl> wrote:

> Będę wtedy chyba potrzebował jakiegoś level shiftera?

Widziałem kiedyś fajny level shifter na takie okazje.

http://husstechlabs.com/wp-content/uploads/2010/09/L
evel-shifter.jpg

Stosowałem z powodzeniem na BSS138.

> Dodatkowo, przed nadaniem każdej komendy zastosuję opóźnienie.

Daj 20ms (na ślepe oko) przed każdym znakiem.

> BTW jeszcze pytanie natury formalnej. Jak inteligentny jest kompilator w
> zakresie makrodefinicji zastępujących wartości liczbowe? Jeśli np. dam:
>
> #define WARTOSC 31
>
> a potem w programie dam:
>
> if (zmienna < (WARTOSC-1))

Kompilator zobaczy w tym miejscu "zmienna < (31 - 1)" (bo preprocesor podstawi
31 za WARTOSC) i od razu obliczy do 30.

> To w którym momencie zostanie obliczona wartość? Podczas kompilacji, czy
> też za każdym razem uC będzie sobie musiał odejmować jedynkę? ;)

Optymalizatorem się nie martw - dzisiejsze optymalizatory są wystarczająco
inteligentne :) Mało jest przypadków, gdy trzeba poprawiać optymalizator.

Poza tym najpierw zrób, żeby działało, a potem baw się w optymalizacje.

--
Gof
http://www.chmurka.net/

do góry

Atlantis <m...@w...pl> wrote:

> 1) Możliwe jest, żeby moduł zachowywał się inaczej w stosunku do Amtegi
> niż do PC z odpalonym HyperTerminalem? Na przykład żeby wysyłał jakieś
> dodatkowe dane?

Jeśli tylko elektrycznie wszystko jest OK (prawidłowe zbocza, prawidłowe
poziomy napięć), to jest to mało prawdopodobne. Tzn. modem będzie wysyłał
to samo (taka natura RS-232), ale różne odbiorniki mogą różnie to odbierać.
Tutaj oscyloskop jest Twoim najlepszym przyjacielem.

> 2) Możliwe jest, żeby HyperTerminal "ukrywał" pewne rzeczy przy
> normalnej komunikacji z modułem, gdy był z nim połączony obiema liniami,
> ale już pokazywał je przy "podsłuchiwaniu" linią odbiorczą?

Nie. To nie ma znaczenia. Ale nie zdziwiłbym się (chociaż nie wiem tego, bo
bardzo dawno używałem HT), gdyby HT np. ukrywał NUL-e (znaki 0x00).

> 3) Możliwe jest, żeby jednego komunikatu nie dało się wysłać z Atmegi do
> modułu (chociaż HyperTerminal go odbierał), a co więcej - żeby
> "podsłuchujący" komputer nic nie widział?

Nie. RS jest bardzo prosty i nie ingeruje w wysyłane komunikaty. Dla niego
to po prostu ciąg znaków.

--
Gof
http://www.chmurka.net/

do góry

J.F. <j...@p...onet.pl> wrote:

> Podstawa to terminal z trybem hex ... tylko ktory to ?

Linux i hexdump -C /dev/ttyS0 :)

> Wlacz logowanie do pliku ... a i za to nie recze, poza tym ... czym to
> potem obejrzec, zeby bylo uczciwie ..

notepad++ jest w miarę uczciwy, jeśli chodzi o znaki specjalne.

>> 3) Możliwe jest, żeby jednego komunikatu nie dało się wysłać z Atmegi do
>
> A to juz mniej ... ale w czym oprogramowane ?
> Tylko assembler prawde ci powie .. o ile go dobrze znasz :-)

Assembler? Ja ufam kompilatorowi :) Błędy kompilatora to bardzo rzadkie
stworzenia. Są możliwe, ale nieprawdopodobne. Chociaż zdarzały mi się różne
jaja, gdy źle były poustawiane np. opcje linkera. Ale w tak dużym programie
to by już dawno powychodziło.

--
Gof
http://www.chmurka.net/

do góry

On Sat, 15 Dec 2012 18:07:13 +0100, Atlantis <m...@w...pl>
wrote:
> Niezależnie od tego stan wysoki na liniach rs232 wynosi 5V. W tej
chwili

Pisząc rs232 nasz na myśli usart mcu? Używasz jakieś przejściówki
usart<->rs232 czy usart<->usb w przypadku łączenia się z pc?


> Będę wtedy chyba potrzebował jakiegoś level shiftera?

jeśli atmega nie może na 3.3v, to owszem albo level shifter ale można
też obniżyć dzielnikami a podciagnac dioda + rez. osobiście używałem
ten drugi sposób z powodzeniem.


> Krótko rzecz ujmując używam dwóch tablic: rx_buffer[] i
last_line[]. Do

ja jestem zwolennikiem buforu odbiorczego typu ring, które wypełnia
przerwanie po odbiorze znaku + funkcje odczytu zawartosci bufora.
Algorytm to m.in. dwie funkcje (w psedokodzie):
wyslij("at&f\r\n");
czekajna("OK\r\n", 1000);
Pierwsza wysyła string polecenia, druga odczytuje bufor (nie będę
wnikał w obsługę bufora, sloty itp. ) czekając aż się pojawi
oczekiwany string w określonym czasie (timeout w ms), jeśli się nie
pojawi to funkcją zwraca błąd, który możemy obsłużyć. Bufor ring
bardzo ładnie jest opisany wraz z przykładami w nocie an2120 dla
m68hc08, polecam. Oczywiście ważne jest aby do funkcji oczekującej
podawać "cały koniec" oczekiwanego stringu (wraz z "\r\n") aby nie
doprowadzić do zbyt wczesnego nadania kolejnego polecenia.

> BTW jeszcze pytanie natury formalnej. Jak inteligentny jest
kompilator w
> zakresie makrodefinicji zastępujących wartości liczbowe? Jeśli np.
dam:
> #define WARTOSC 31
> a potem w programie dam:
> if (zmienna < (WARTOSC-1))
> To w którym momencie zostanie obliczona wartość? Podczas
kompilacji, czy
> też za każdym razem uC będzie sobie musiał odejmować jedynkę? ;)

Nie powinien przy włączonej optymalizacji (to się chyba nazywa
constant folding), po prostu sprawdzi czy,zmienna<30. Ale to zalezy
od kompilatora i włączonego poziomu optymalizacji.

--
Marek

do góry

W dniu 2012-12-15 20:04, Marek pisze:

> Pisząc rs232 nasz na myśli usart mcu? Używasz jakieś przejściówki
> usart<->rs232 czy usart<->usb w przypadku łączenia się z pc?

Tak, miałem na myśli właśnie usart Atmegi.
Łącząc się z pecetem używam modułu na max3232.
Przelotkę na USB będę musiał kupić, ale do takich "warsztatowych"
zastosowań używam leciwego ThinkPada T23, który posiada port COM.


> ja jestem zwolennikiem buforu odbiorczego typu ring, które wypełnia
> przerwanie po odbiorze znaku + funkcje odczytu zawartosci bufora.
> Algorytm to m.in. dwie funkcje (w psedokodzie):
> wyslij("at&f\r\n");
> czekajna("OK\r\n", 1000);

Hmm... Zainteresuję się tematem. Na razie zrobiłem to "po swojemu". Jest
to może rozwiązanie proste, nawet i nieco toporne, ale w pewnym sensie
to jego zaleta.

W każdym razie najważniejsze - miałeś rację co do przyczyny. Zmieniłem
procedurę odbierającą znaki. W sposób opisany w poprzedniej wiadomości i
teraz transmisja przebiega prawidłowo. W komunikatach wysyłanych przez
moduł nie ma żadnych "krzaczków". Wracają czyste komunikaty.

Jednak teraz w oczy rzuciła mi się jeszcze jedna kwestia, której nie
dostrzegłem wcześniej. Mianowicie komunikaty są odbierane liniami. Puste
są ignorowane, ale przyjście każdej następnej pełnej zastępuje
poprzednią zawartość last_line[].
Sęk w tym, że np. na zapytanie "AT+CPIN?" moduł odpowiada w następujący
sposób:

+CPIN: SIM PIN\r\n
\r\n\
OK\r\n

Efekt jest oczywisty - oczekiwana, pierwsza linia zostaje niemal
momentalnie zastąpiona przez trzecią (druga zostaje zignorowana).
Można by to wyłączyć (np. jakąś komendą AT) czy jedynie w grę wchodzi
zmiana algorytmu odbierania komunikatów?

do góry

On Sat, 15 Dec 2012 20:37:11 +0100, Atlantis <m...@w...pl>
wrote:
> Sęk w tym, że np. na zapytanie "AT+CPIN?" moduł odpowiada w
następujący
> sposób:
> +CPIN: SIM PIN\r\n \r\n\ OK\r\n
> Efekt jest oczywisty - oczekiwana, pierwsza linia zostaje niemal
> momentalnie zastąpiona przez trzecią (druga zostaje zignorowana).
> Można by to wyłączyć (np. jakąś komendą AT) czy jedynie w grę
wchodzi
> zmiana algorytmu odbierania komunikatów?


Niektóre odpowiedzi modemu można zamienić na kody numeryczne
poleceniem atv0 (np. zamiast "OK" modem odpowie "0"). Ale nie sądzę
ze tez to może dotyczyć polecen rozszerzonych dot. np. nr pin.
Proponuje zmianę algorytmu z zastosowaniem bufora, tak aby czekał na
podany wzorzec stringu odpowiedzi. Po wyslaniu polecenia, które
podałeś jako przykład czekamy na string "OK\r\n". Nie ma znaczenia
czy w odpowiedzi sa 2 czy 3 linie. Po odebraniu wzorca odpowiedzi
(wszystkich 4 znakow O+K+\r+\n) w buforze odbiorczym będzie cała
odpowiedź modulu (można ja później parsowac itp.).

--
Marek

do góry

Atlantis <m...@w...pl> wrote:

> Efekt jest oczywisty - oczekiwana, pierwsza linia zostaje niemal
> momentalnie zastąpiona przez trzecią (druga zostaje zignorowana).
> Można by to wyłączyć (np. jakąś komendą AT) czy jedynie w grę wchodzi
> zmiana algorytmu odbierania komunikatów?

Buforuj do cyklicznego bufora i wyciągaj z niego kolejne linie, parsując
je od razu.

--
Gof
http://www.chmurka.net/

do góry

W dniu 2012-12-15 20:04, Marek pisze:

> ja jestem zwolennikiem buforu odbiorczego typu ring, które wypełnia
> przerwanie po odbiorze znaku + funkcje odczytu zawartosci bufora.
> Algorytm to m.in. dwie funkcje (w psedokodzie):
> wyslij("at&f\r\n");
> czekajna("OK\r\n", 1000);

Hmm... Wydaje mi się, że w tym projekcie nawet nie występuje konieczność
implementacji ring bufora. Nie będzie występował ciągły przepływ danych.
Jedynie w określonych momentach będą przybywały komunikaty o możliwej do
przewidzenia długości (odpowiedzi na komunikaty oraz cyklicznie
pojawiający się "RING\r\n\r\n" w przypadku połączenia przychodzącego.

Czyszczenie bufora przed wysłaniem polecenie oraz po sprawdzeniu
odpowiedzi (a także wykryciu sygnału dzwonka) powinno wystarczyć, o ile
dodatkowo zastosuję jakieś zabezpieczenie przed jego przepełnieniem.

Niemniej w celach dydaktycznych przyjrzę się temu zagadnieniu.

Później pewnie będę musiał zastosować też obsługę linii RTS.

do góry

W dniu 2012-12-15 19:14, Adam Wysocki pisze:

> Widziałem kiedyś fajny level shifter na takie okazje.
>
> http://husstechlabs.com/wp-content/uploads/2010/09/L
evel-shifter.jpg
>
> Stosowałem z powodzeniem na BSS138.

Hmm... Chyba nie do końca na takie okazje... Z tego co widzę tutaj
potrzebuję dwóch napięć zasilania - 3.3V oraz 5V.
Moduł D15 może pracować na dowolnym napięciu zasilania pomiędzy 3V a 6V.
Logiczny stan wysoki jest jednak niezależny od VCC i wynosi 5V.
W tej chwili nie ma problemu, bo zarówno moduł jak i uC zasilam ze
stabilizatora 78T05.

Martwi mnie jednak zapis w manualu Atmegi8 (a także ATTiny 4313), który
dość jasno mówi, że najwyższe dopuszczalne napięcie na każdym pinie (za
wyjątkiem resetu) wynosi VCC+0,5V.

Jeśli zastosuję zasilanie z akumulatorka 3,6V z punktu widzenia D15 nic
się nie zmieni. VCC będzie mieściło się w widełkach, na liniach danych
stan wysoki wciąż będzie wynosił 5V. Jednak z punktu widzenia uC będzie
to prawie o jeden wolt za dużo.

Jednocześnie w takim układzie nie będę miał 5V do zasilenia tego
shiftera. Gdybym miał, po prostu zasiliłbym z niego całość układu. :)

do góry

Tak więc reasumując widzę tutaj tylko dwa możliwe rozwiązania:
1) Zasilanie układu z akumulatorka, który (wraz z ewentualnym
stabilizatorem) dawałby około 5V. Wolałbym uniknąć takiego rozwiązania -
akumulatorem 3,6V z odpowiednim sterownikiem pozwoli mi na korzystanie z
typowej ładowarki od komórki.
2) Zastosowanie shiftera, który nie wymaga innego zasilania, jak tylko
to pochodzące z baterii. W końcu max232 też nie potrzebuje napięć -15V i
+15V do prawidłowej pracy.

do góry