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
Walter L. schrieb: > Der SIM800L stellt nur TX und RX > zur > Verfügung. Laut Datenblatt http://wiki.seeedstudio.com/images/4/46/SIM800L_Hardware_Design_V1.00.pdf hat er RTS/CTS. Dazu sogar noch DTR, RI und DCD. Also ich würde nochmal genau schauen und Hardware Flow-Control einschalten und benutzen.
Hallo, es geht hier um ein ähnliches MODUL (Beitrag "GSM Modul SIM800l an allen Pins gleiche Signale"). >SIM800L GPRS GSM MODUL QUAD BAND mit hochwertiger Antenne Arduino. Wie ich schon schrieb, hat nur TX und RX! VG Walter
Na gut, dann sind die Pins wohl spontan vom Chip abgefallen und du musst Software Flow-Controll zum Laufen bekommen. Ansonsten bist du gekniffen.
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.
Angehängte Dateien:
-
AT_IPR_38400.png
6,2 KB
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.
Beitrag #5038557 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.