W dniu 2012-12-15 09:12, Marek pisze:

> Rozumiem ze to moduł 5V? Możesz mi podać jego model?

Wydawało mi się, że już wcześniej wspominałem. Moduł to Motorola D15.
Może pracować z napięciem zasilania od 3V do 6V.
Niezależnie od tego stan wysoki na liniach rs232 wynosi 5V. W tej chwili
się tym szczególnie nie martwię, bo Atmega zasilana jest ze
stabilizatora 5V, ale faktycznie ta kwestia chodzi mi po głowie, bo
docelowo układ ma być zasilany z akumulatorka 3,6V.

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

Manual podaje następującą informację.

The signal thresholds are:
Vih 2.0V min.
Vil 0.8V max.
Voh 4.4V min. @ 50uA or 3.8V min. @ 8mA.
Vol 0.1 max. @ 50uA or 0.44V @ 8mA.


> W dalszej części przez ze nie ma problemu przy komunikacji z komputerem
> a później masz wątpliwisci co do działania hyperterminala.

Po prostu starałem się doszukiwać przyczyn tam, gdzie tylko się dało.
Program pisałem w oparciu o wskazania HT, więc zacząłem nawet
podejrzewać, że to on coś ukrywał i mogłem tego nie uwzględnić w kodzie.
Wychodzi jednak na to, że przyczyna była zgoła inna...


> odpowiedzi może transmitowac kolejne polecenie. Kiedyś miałem podobny
> problem ze moduł dziwnie się zachowywał z mcu a w terminalu było
> prawidłowo. Był błąd w kodzie programu, mcu wysyłał kolejne polecenie w
> trakcie transmisji ostatniego \n z odpowiedzi poprzedniego polecenia i
> moduł albo się "przytykal" albo wysylal krzaczek.

No i to chyba będzie to... Dopiero wróciłem z pracy i nie miałem czasu
na eksperymenty, ale to najbardziej prawdopodobne wytłumaczenie. Po
prostu nie wiedziałem o tej własności modułu - sądziłem, że komunikaty
się kolejkują i wymiana informacji w obydwie strony odbywa się
niezależenie. Faktycznie dotychczasowy kod ma opisaną przez Ciebie cechę.

Krótko rzecz ujmując używam dwóch tablic: rx_buffer[] i last_line[]. Do
pierwszej napływają wszystkie znaki z modułu GSM, za wyjątkiem \n, które
są pomijane. Wystąpienie \r powoduje przepisanie wszystkich
poprzedzających go znaków z bufora do last_line[]. Pierwszy element
tablicy last_line[] pełni też funkcję flagi informującej o przyjęciu
odpowiedzi (kopiowanie odbywa się w przerwaniu, więc z punktu widzenia
reszty programu całość przybywa za jednym razem).

Jednak zgodnie z tym co piszesz po wystąpieniu \r moduł odbierał jeszcze
\n (tyle tylko, że go nigdzie nie zapisywał). Co więcej - w niektórych
przypadkach potem leciała jeszcze pusta linie (\r\n). A tymczasem flaga
była już postawiona i zaczynało się nadawanie kolejnej komendy...

Teraz zrobię to inaczej. Wystąpienie \n będzie inicjowało kopiowanie
danych z bufora do last_line[], aż do wystąpienia znaku \r. Wyjątkiem
będzie sytuacja, kiedy \r znajdzie się w pierwszym polu bufora - wtedy
zostanie on po prostu wyczyszczony (ignorowanie pustych linii).
Dodatkowo, przed nadaniem każdej komendy zastosuję opóźnienie.

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ę? ;)