Hallo,
habe GSM-Modul SIM800L mit TMS320F28062 in Betrieb. Habe folgendes
Problem: Wenn ich z.B. den Bef. AT&V gebe, dauert es eine Weile, bis
alle Daten im 28062 sind. Während dieser Zeit darf der 28062 nichts an
den SIMM800L geben. Wie erkenne ich, dass die Daten vom SIM800L zu Ende
gesendet sind. Das gleiche Problem besteht z. B. bei AT+CPIN=4711.
Hiermit
loggt sich der SIM800L in das Netz ein. Der SIM800L stellt nur TX und RX
zur
Verfügung. Mit XON/XOFF habe ich das probiert, aber ich sehe kein XON
hex11 oder XOFF hex13 im Datenstrom.
Hat jemand einen TIPP zur Lsg.?
VG Walter Lohmann
Ich verstehe das Problem nicht.
Ein AT Befehl hat immer eine definierte Antwort.
Die Antworten stehen im AT Datenblatt des Moduls.
Also Befehl senden und auf die definierte Antwort warten, ob die Antwort
komplett ist erkennt man am Newline.
Jack schrieb:> Na gut, dann sind die Pins wohl spontan vom Chip abgefallen
Nein, die sind auf der Trägerplatine nicht verdrahtet. Das ist
verbreitet. Und da die "Pins" keine Pins sind, sondern Lötpads auf der
Unterseite des Sim800l, ist ein nachträgliches Kontaktieren auch nicht
möglich.
Verbreitet sind "Breakout Boards" wie dieses hier:
https://nettigo.eu/system/images/1935/original.jpg?1479816092
Das Software-Handshake (XON/XOFF) auf der seriellen Schnittstelle kann
mit
AT+IFC=1,1
aktiviert werden. Danach sollte mit AT&W die Konfiguration gespeichert
werden, oder es muss nach jedem Reset erneut das Softwarehandshake
aktiviert werden.
(Siehe Seite 53 in
https://www.elecrow.com/download/SIM800%20Series_AT%20Command%20Manual_V1.09.pdf)
Allerdings sollten die Ausgaben von AT&V etc. mit einem "OK"
abgeschlossen werden. Statt nun XON/XOFF zu implementieren, könnte es
genügen, genau darauf zu warten.
fritzler:
Ich gehe davon aus das Du mit newline LF meinst.
Der sim800L antwortet auf AT+CPIN=4711 mit
AT+CPIN=4711\r\r\n
OK\r\n
+CPIN: Ready\r\n
\r\n
Call Ready\r\n
\r\n
SMS Ready\r\n
Du siehst, da sind ne Menge LFs drin. Somit auf LF zu warten und zu
meinen, das jetzt der next Bef. gesendet werden kann, ist kein guter
Rat. Ich müsste also auf "SMS Ready" warten (auswerten). Dieser Bef. hat
auch kein OK am Ende. Auch wenn ich "SMS Ready" auswerten würde, ist das
Problem generell noch nicht gelöst.
Rufus:
Danke für Deine Antwort.
AT+IFC=1,1 sende ich bevor ich AT+CPIN=4711 gebe, und bekomme auch das
OK
>Siehe Seite 53 ...
Mit dem Dokument arbeite ich ständig.
In der obigen Antwort ist kein XOFF enthalten.
Soweit ich das bisher beurteilen kann, haben die AT-Befs kein
definiertes ständig gleiches Ende in der Antwort, das man einfach
auswerten kann. Die Software muss aber wissen, ob der nächsten Bef.
abschickt werden kann.
Vielleicht hat hier jemand das HANDSHAKE mit XON/XOFF schon mal gefahren
und kann darüber berichten.
VG Walter
Walter L. schrieb:> In der obigen Antwort ist kein XOFF enthalten.
Nö, warum auch? Du scheinst eine falsche Vorstellung davon zu haben, was
Handshake macht.
Mit Handshake wirst Du zwar davon abgehalten, die serielle Schnittstelle
des SIM800l zu "überfahren", aber das hat nichts mit der Vollständigkeit
von Modem-Antworten zu tun.
Wenn Du ständig Daten in das Modem pumpst, wird irgendwann der interne
Empfangspuffer voll sein, und dann aktiviert das Modem den Handshake, um
Dich vom Senden weiterer Daten abzuhalten.
Das aber läuft auf einer untergeordneten Protokollebene unterhalb der
AT-Kommandos.
Zur einfacheren Auswertung der Resultate der AT-Kommandos kannst Du das
Modem auf numerische Antworten konfigurieren (ATVn, siehe Handbuch Seite
43).
Ob Dir das aber in jedem Einzelfall hilft, wage ich zu bezweifeln; Du
wirst Dir für jedes gesendete Kommando einzeln ansehen müssen, was als
Resultat erwartet werden kann, und Deine Software entsprechend darauf
anpassen.
Lesen und verstehen!
Ich hab nicht gesagt, dass stur auf \r\n gewartet werden soll sondern
auf die jeweils spezifische Antwort.
Also nach jedem AT Befehl muss die Software wissen welche Antwort
erwartet wird, das ist nicht anders lösbar.
Meine Lib arbeite ja auch so, auch wenn die eher gruselig ist.
(Ich wollt die schon immer mal neuschreiben aber die funktioniert ja...)
http://fritzler-avr.de/HP/Librarys/sim900d_his.php
Eine Antwort sieht IMMER so aus: \r\n<Antwortstring>\r\n
Das kann man jetzt "Antwortpaket" nennen.
Einige AT Befehle geben auch 2 Antwortpakete, eines welches OK sagt
(Befehl ausgeführt) und dann die Antwort.
Im Anhang ein Bild wo mans ganz deutlich sieht.
>Nö, warum auch? Du scheinst eine falsche Vorstellung davon zu haben, was
Handshake macht.
Wo meinst Du, wo das XOFF=0x13 erscheint.
Es kann nur über TX vom SIM800L an den 28062 gesendet werden, also in
die AT-Antwort mit "eingespleißt" werden. Deswegen funktioniert ja auch
das XON/XOFF nur bei ASCII und nicht bei rein digitaler Übertragung, in
der alle Kombinationen von 2**8 enthalten sein können. Da das Empfangen
bei mir im 28062 über IRQ erfolgt, kann ich sofort auf ein XOFF
reagieren.
Vielleicht hat hier jemand das HANDSHAKE mit XON/XOFF schon mal gefahren
und kann darüber berichten, wie der SIM800L reagiert.
VG Walter
fritzler:
>Meine Lib arbeite ja auch so, auch wenn die eher gruselig ist
Genau dies hatte ich auch angedacht, ist aber keine Lösung für mich.
Ich werde es nicht in sinnvoller Zeit schaffen, alle AT-Befs mit allen
Antwortvarianten softwaremäßig zu implementieren. Die Gefahr, eine
Variante nicht implementiert zu haben, und damit einen Softwareabsturz
zu provozieren, ist für mich nicht akzeptabel.
Wofür gibt es den HANDSHAKE.
Vielleicht hat hier jemand das HANDSHAKE mit XON/XOFF schon mal gefahren
und kann darüber berichten, wie der SIM800L reagiert.
VG Walter
Walter L. schrieb:> Ich werde es nicht in sinnvoller Zeit schaffen, alle AT-Befs mit allen> Antwortvarianten softwaremäßig zu implementieren
Musst Du ja auch nicht. Es genügt, sich um die zu kümmern, /die Du
verwendest/. Und da gibt es so viele zu erwartende Antworten nicht.
> Wofür gibt es den HANDSHAKE.
Habe ich Dir schon erklärt. Der Handshake löst nicht Dein Problem.
OK.
Man kommt offensichtlich ich nicht drum herum, die möglichen
Antworttexte zu hinterlegen, dann mit den empfangenen zu vergleichen und
entsprechend zu reagieren. Danke für die fruchtbringende Diskussion.
VG Walter
Walter L. schrieb:> Man kommt offensichtlich ich nicht drum herum, die möglichen> Antworttexte zu hinterlegen, dann mit den empfangenen zu vergleichen und> entsprechend zu reagieren.
Auch das ist in der Ausführlichkeit nicht nötig. Es genügt, den
erwarteten Antworttext zu hinterlegen; weicht die Antwort ab, liegt
ein Fehler vor. Nur an einigen kritischen Stellen ist der Fehler selbst
tatsächlich interessant und eine ausdifferenzierte Auswertung nötig, an
anderen Stellen genügt ein Abbruch und eine Neuinitialisierung des
Modems.
