Hallo,
ich habe ein Problem mit dem oben genannten GSM Modul. Egal was ich ihm
schicke ich bekomme einfach keine Antwort vom Modul.
Weder wenn ich dem Modul vom Mikrocontroller (NXP LPC2119) noch vom
Hyperterminal etwas zuschicke.
Mit dem Oszi überwache ich die RxD und TxD Leitung. Beim Modul kommt
alles sauber an was ich rüberschicke aber nichts zurück.
Das Modul schalte ich ebenfalls über den µC ein und die Status LED
meldet sich dann auch.
Habe es mit 3 Leitungen versucht (RxD, TxD, GND) und dann noch mit den
anderen (RTS, DTR, etc. etc.) Reichen 3 oder brauche ich die volle
Handshake Geschichte bei diesem Modul?
Der Befehl AT<cr> sollte mir ja eigentlich ein OK zurückgeben,
unabhängig von den Einstellungen (baudrate usw.) oder nicht?
Weis vieleicht jemand Rat oder hatte das gleich Problem mit diesem
Modul!
Danke!
Peter
Hallo Peter
Ich benutzte für meine Diplomarbeit (Bikealarmanlage) ein Telit GE864
Modul.
Es reichen RxD, TxD, GND für die Kommunikation, einfach die Pegel
beachten. Das Modul hat eine automatische Baudraten Erkennung.
Allerdings nur im neusten Hardware-User-Guide stand, dass der Anschluss
"TXD (rx_uart)" keinen internen Pullup Widerstand hat und einen externen
benötigt.
Dazu benutzte ich die PWRMON Leitung zusammen mit einem Pullup
Widerstand (47K) um den benötigten High-Pegel am TXD Ausgang zu
erreichen.
vielleicht ist es ja das...
Grüsse aus der Schweiz
Martin
Hallo Peter,
Sind eventuell nur RX und TX vertauscht? Defekte Module sind sehr
selten. Wir haben einen Vorschlag:
- Wir tauschen das Modul im Vorabtausch, unabhängig wie alt es ist oder
wo es gekauft wurde.
- Alle User dieses Forums erhalten 30% Rabatt auf ein Round Solutions
Starterkit
- Über weitere Goodies können wir uns gerne unterhalten
Weiteres:
- Wir suchen immer Freelancer für kleine Aufgaben, aber auch für
Geräteentwicklungen. Wer Interesse hat kann sich gerne melden.
- Wir wachsen und suchen Personal mit Kenntnissen in uC und GPRS
Modulen. Zwei Stellen haben wir gerade besetzt, aber die nächste
Einstellung kommt bestimmt.
Beispiele für Aufträge
- www.track4free.com >>> erster kostenfreier Server für Entwickler von
Ortungsgeräten
- www.gauge4free.com >>> erster kostenfreier Server für Entwickler zur
Visualisierung von Messdaten
- Python Debugger für die GPRS Module mit lizenzfreiem Pythoninterpreter
(siehe Upload im Anhang)
Bitte sende eine Email an harald.naumann (at) roundsolutions.com und
frage nach einer RMA Nummer für die Rücksendung an:
Round Solutions GmbH & Co KG
Im Steingrund 3
D-63303 Dreieich
Tel +49 6103 27044200
Fax +49 6103 27044199
www.roundsolutions.com
Viele Grüße vom Round Solutions Support Team
Harald Naumann
P.S. Kunden können das weltweit größte Forum zum Thema GPRS, UMTS, CDMA,
WIFI, Bluetooth, ZigBee und ISM Module von Round Solutions nutzen
Hallo MC-Freunde!
Ich tüftel gerade an einem Project, in dem ich AT-Befehle von einem
MC(P89LPC932) über die serielle Schnittstelle (UART) zu einem Telit
GM862 Modem schicken will.
Hardware ist richtig verbunden, funktionierte vorher schon mit einem
anderen ASM-Code.
Ich schreibe nun ein neues Programm in C. In dem Programm sende ich vom
LPC932 den AT-Befehl AT#SHDN zum Telit Modem.
Daraufhin soll ein OK zurück gegeben werden und sich das Telit Modem zu
mindest ausschalten. Sollte ein OK zurück kommen, signalisiert der MC
dies durch einschalten von LED_W. Sollte etwas anderes zurück kommen,
geht LED_W an.
Jedoch zeigt das Modem, abgesehen davon, dass die Status LED beim
Einschalten an geht, keinerlei Reaktion.
Der P89LPC932 wird mit einem externen Quarz mit einer Frequenz von
1,8432 MHz betrieben.
Hier ist mein Code.
...geht leider auch nicht.
Habe es so implementiert dass jedes mal wenn ein Byte versonden ist eine
LED an geht. Scheinbar werden alle Bytes übertragen. Wenn ich dann beim
Empfangen auch eine LED anschalte, empfängt er ein Byte und bleibt dann
bei...
1
while(RI!=1);
...hängen. Scheinbar wird nur ein Byte empfangen und dann bleibt der
Empfangsbuffer leer.
Sende- und Empfangsfunktion sehen nun so aus:
1
// SEND STRING TO UART-----------------------------------------------------------------------------
geht es auch nicht.
Aber im Grunde genommen darf es daran ja auch nicht liegen, da die Zeit
zwischen den einzelnen Bytes ja nicht von Bedeutung ist. Nach jedem Byte
ist ja die Übertragung abgeschlossen.
Um nochmal auf den Abschluss eines Befehls zurück zu kommen.
Was muss da gesendet werden? Reicht ein <cr> (0x0D oder 13) aus?
Muss das Char-Arry in besonderer Art und Weise abgeschlossen werden,
z.B. mit /0 und dafür noch ein weiteres Feld zur verfügung stehen?
Denke, die letzte Frage ist eigentlich hiermit...
1
unsignedcharat[]={"AT#SHDN\r"};
...beantwortet. Das Array wird in der Größe des Strings erstellt und es
werden 8 Zeichen (AT#SHDN = 7, + \r = 1, = 8) übertragen, was ich an der
LED sehe.
Wie sieht es bei dieser Art der Implementierung mit der manuellen
Auslese und Setzung von RTS(output), DTR(output), CTS(intput),
DCD(input) aus?
Bei näherer Betrachtung meiner Schaltung ist noch aufgefallen, das DSR-
und RI-Pin vom Modem nicht mit dem MC verbunden sind.
Dies sollte aber im Grunde kein Hindernis darstellen, da genau diese
Hardware unter dem Assembler code funktionierte. Gegebenen Falls ist
vielleicht eine andere Implementierung erforderlicht?
Danke für eure bisherige Hilfe!
Vielleicht habt ihr ja noch weitere Ideen woran es liegen könnte?
Gruß Harry
>void receiveString(unsigned char *string) {> unsigned int i;> for(i = 0; i < resLen; i++) {
Du wartest mit dieser Schleife auf 30 Zeichen.
Du bekommst in diesem Fall aber möglicherweise nur 3 => "OK\r".
Beim Zeichen 13 musst du die Schleife abbrechen.
Sonst hängt dein Programm.
Hallo Holger!
Vielen Dank für den Hinweis. Aber leider hat dies auch nicht
weitergeholfen.
Nach dem ersten Byte ist schluss.
Hier ist nochmal die Funktion "receiveString()":
1
// RECEIVE STRING FROM UART------------------------------------------------------------------------
2
voidreceiveString(unsignedchar*string){
3
unsignedinti=0;
4
while(SBUF!=13){
5
LED_W=1;
6
LED_R=0;
7
wait(5);
8
9
while(RI!=1);// wait until the serial port signals a new character has arrived
10
string[i]=SBUF;// read the value in the serial buffer
// RECEIVE STRING FROM
UART--------------------------------------------------------------------
----
void receiveString(unsigned char *string)
{
unsigned int i;
unsigned char tmp;
for(i = 0; i < resLen; i++)
{
LED_W = 1;
LED_R = 0;
// wait(5); // weg mit dem Schrott
while(RI != 1); // wait until the serial port signals a new
character has arrived
tmp = SBUF;
RI = 0; // free to receive a new character
if(tmp==13) { string[i]=0; break; }
string[i] = tmp; // read the value in the serial buffer
LED_R = 1;
LED_W = 0;
// wait(5); // weg mit dem Schrott
}
}
Was glaubst du eigentlich wieviel Zeichen bei so einem wait(5)
flöten gehen ? Dein Modem wird sicherlich kein wait(5) ausführen.
Das sendet munter weiter.
Hallo Holger,
habe mal alle waits entfernt und den Code nach deinem Vorbild
implementiert. Jedoch wieder ohne Erfolg.
Auch am MC liegt es nicht, den habe ich auch mal ausgetauscht.
Aber werden daten die in SBUF stehen wenn sie nicht abgerufen werden
einfach überschrieben? Wartet da nicht der Sender auf den Empfänger?
Naja, also ich vermute ganz stark, dass es doch an meiner
Initialisierung liegt. Habe zwar die Initialisierungswerte von dem
Assemblerprogramm übernommen, aber irgendwas scheint dort dennoch faul
zu sein.
Die die Formel zur Baudratengenerierung mit hilfe des internen
Baudratengenerators ist ja folgende:
Baudrate = CCLK⁄((BRGR1, BRGR0)+16)
Nur weiß ich nicht genau, wie ich sie anwenden muss, mit dem Komma
zwischen BRGR1 und BRGR0?
Habe auch schon probiert den Timer1 zur Baudratengenerierung zu
benutzen.
Dann sollte die Initialisierung ja so aussehen:
Die Formel für TH1 und PCON = 0x80:
baudrate = CCLK⁄((256−TH1)32)
TH1 = 256-(CCLK/(32*9600))= 250
Aber er bleibt wieder irgendwo stehen.
Es ist doch zum Verzweifeln!
Du solltest deine Schaltung erst mal mit
einem PC verbinden um die Baudrate zu kontrollieren.
Solange die nicht stimmt klappts auch nicht mit dem Modem :(
Evtl. braucht dein Modem auch noch die Handshake Leitungen.
Aber das sollte im Datenblatt stehen.
Das Modem hat Baudraten Autodetection. Ist also über Hyperterminal mit
zu mindest allen Standardbaudraten ansprechbar und reagiert auch.
Das Problem ist der MC und wie du schon vielleicht richtig vermutet
hast, müssen die Handshakeleitungen verwendet werden.
Ich will es morgen mal nachlesen. Wo nach müsste man dann suchen? UART
Handshake?
Besten Dank!
Harry
So, der MC sendet nun endlich Zeichen und das Modem empfängt sie! :)
Habe mal nen Oszilloskop dran gehängt und die Baudrate überprüft und sie
stimmte.
Dann habe ich mir noch einen Max232 besorgt und den an TxD und RxD
geklemmt und siehe da, auf einmal sah ich Zeichen in Hyperterminal und
auch das Modem schaltete sich bei dem Shutdown-Befehl brav aus. :)
Aber fragt mich nun nicht, was ich verändert habe, eigentlich ist alles
beim Alten.
Das einzige Problem was ich nun noch habe ist, dass der MC immer noch
nicht die Daten richtig empfängt...
Aber da komme ich schon hinter!
Erstmal ein dickes Dankeschön an alle die geholfen haben!
Wenn ich wieder nicht weiter komme, nerv ich euch weiter... ;)
Gruß Harry
Hallo MC-Freunde!
Die Freude war nur von kurzer Dauer.
Habe nun herrausgefunden, dass es nur funktioniert, wenn ich die RxD
Leitung vom PC an die TxD Leitung des MCs anschließe und mithöre. In
diesem Falle schaltet sich auch das Modem durch AT#SHDN\r\n aus.
Wenn ich die RxD Leitung des PCs entferne, tut sich gar nichts.
Was macht die RxD Leitung, damit es funktioniert? Sie dürfte doch
eigentlich lediglich mit hören und nicht in die Kommunikation einwirken.
MfG
Harry
Hatte grade auch das Problem keine Uart Vebindung zu bekommen.
Das Problem war Tauschen von RXD und TXD...
so gehts:
(Master ist PC)
Leitung vom PC zum GM862 heisst MOSI und geht auf TXD vom GM
Leitung vom GM862 zum PC heisst MISO und geht auf RXD vom GM
Schon seltsam, ich benenne doch keine Leitung die empfängt TXD !??!!
egal nun gehts
Gruß,
Daniel