Mit ESP8266 und STM32 Nucleo können keine Daten an Thingspeak gesendet werden

Ich verwende den mbed-Compiler von ARM, um meinen STM32 Nucleo zu programmieren. Ich verwende auch ein ESP8266 als mein WLAN-Modul.

Meine Verbindungen sind wie folgt:

  • Rx des ESP8266 ist mit D8 auf dem Nucleo verbunden.
  • Tx des ESP8266 ist mit D2 auf dem Nucleo verbunden.
  • Gnd des ESP8266 zum Gnd auf der Platine. Alle anderen Pins des ESP8266 sind am Nucleo mit 3,3V verbunden.

Folgendes ist mein mbed-Code:

#include "mbed.h"  

Serial esp(D8, D2);  
DigitalOut myled(LED1);

void flush(void) {  
  while (esp.readable()) {  
    (void)esp.getc();  
  }    
}  

int main() {  
  esp.baud (115200);
  char server[]="GET /update?key=NR************2Z&field1=7";
  flush();  

  esp.printf("AT+RST\r\n");
  wait(2);  

  esp.printf("AT+CWMODE=1\r\n");  
  wait(3);  

  esp.printf("AT+CWJAP=\"Harsha\",\"*****\"\r\n"); 
  wait(3);  

  esp.printf("AT+CIPMUX=1\r\n");
  wait(3); 

  esp.printf("AT+CIPSTART=4,\"TCP\",\"184.106.153.149\",80\r\n");  
  wait(3);

  esp.printf("AT+CIPSEND=4,%d\r\n", sizeof(server)+2);  
  wait(2);

  esp.printf("%s\r\n", server); 
  wait(3);

  esp.printf("AT+CIPCLOSE\r\n"); 

  while(1) {  
    myled = 1;
    wait(0.1);

    myled = 0;
    wait(0.1);
   } 

  return 0;  
}

Ich kann mich mit meinem WLAN-Hotspot verbinden, was bedeutet, dass es kein Problem mit der Verbindung gibt. Aber die Daten, die ich übergebe, werden in Thingspeak überhaupt nicht aktualisiert. Ich habe es auch mit HTTP/1.0 und HTTP/1.1 in der Zeichenfolge „Server“ versucht, immer noch nichts. Übersehe ich etwas?

Wie können Sie sicher sein, dass Ihre AT-Befehle funktionieren? Ich sehe überhaupt keine Fehlerprüfung
Ich habe versucht, eine Fehlerprüfung mit einer langen Verzögerung zu vermeiden. Ich weiß, es ist nicht nützlich, aber ist die Fehlerprüfung so wichtig? Ich habe andere Codes gesehen, bei denen AT-Befehle einfach blind gesendet werden.
Verzögerungen nützen nichts, wenn das Gerät innerhalb weniger Millisekunden auf ERROR antwortet...
Okay, nehmen wir an, es gab einen Fehler, es wird immer noch nicht gesagt, um welchen Fehler es sich handelt. Es bedeutet, dass irgendwo mit den AT-Befehlen etwas nicht stimmt. Dafür brauche ich Meinungen.
Diese AT-Befehle müssen irgendwo angegeben werden. Beispielsweise kann die Antwort für einfache Befehle OK oder ERROR lauten und für einige Befehle einen Fehlercode enthalten. Was sagt das Datenblatt? (z. B. bei diesem Modul sollte AT + RST irgendwann mit "bereit" antworten, nachdem ich 2 Minuten lang gegoogelt habe)
Es antwortet mit einem bereiten Versionsnamen und seinen Herstellerdetails usw., um genau zu sein. Das ist alles in Ordnung. Es stellt sogar eine Verbindung zu meinem Hotspot her, wie ich in der Frage angegeben habe. Das Problem ist, dass die Daten nicht zu Thingspeak gehen. Ich bin sicher, dass einige andere Körper ähnliche Probleme haben sollten. Daher bitte ich um ihre Meinungen und Erfahrungen. Wenn Sie googeln, was AT + RST gibt, dann bin ich mir ziemlich sicher, dass Sie das Modul noch nie zuvor verwendet haben, oder?
Das blinde Senden von AT-Befehlen, ohne das Handbuch zu lesen, fordert Ärger. Ich habe versucht, Sie in die richtige Richtung zu weisen (RTFM). Ich habe dieses Modul noch nie verwendet und habe auch nicht die Absicht, dies zu tun. Seltsamerweise hatte ich gerade die gleiche Diskussion mit einem Kunden und sie würden alles tun, um das Handbuch nicht zu lesen ... während sie sich immer noch beschwerten, dass die Dinge nicht funktionieren würden. Andere Leute das Debuggen für Sie erledigen zu lassen, wird Sie nicht sehr weit bringen. Entschuldigung, aber Sie müssen Ihre Hausaufgaben machen (was beantwortet das Modul?).
Möglicherweise müssen Sie das ESP aus dem Befehlsmodus schalten. Bei alten Hayes-Modems mussten wir etwa 200 ms warten, bis der Befehlsmodus abgelaufen war, bevor wir Daten senden konnten. Wir haben mit +++ zurückgeschaltet. Bei einigen Geräten gibt es einen Modus-Pin. Das Protokoll hat sich möglicherweise geändert, überprüfen Sie es.

Antworten (1)

Ich habe es gelöst, indem ich die Verzögerung für den Aufbau der WLAN-Verbindung nach dem Zurücksetzen erhöht habe. Für diejenigen, die dies hilfreich finden könnten, ist der Arbeitscode wie folgt:

#include "mbed.h"  

Serial esp(D8, D2);  
DigitalOut myled(LED1);

void flush(void) {  
    while (esp.readable()) {  
        (void)esp.getc();  
    }    
}

char server[]="GET /update?api_key=9FL*********C2&field2=";

int main() {  
    int x=7;
    esp.baud(115200);
    flush();  

    esp.printf("AT+RST\r\n"); /* reset module */  
    wait(2);  
    flush();  

    esp.printf("AT+CWMODE=3\r\n");  
    wait(1);  
    flush();  

    // The huge delay was key to obtaining the IP address, so that further commands don't interfere with the ongoing process
    esp.printf("AT+CWJAP=\"Harsha\",\"*******\"\r\n"); /* configure as access point */  
    wait(20);  
    flush();  

    esp.printf("AT+CIPMUX=1\r\n");
    wait(5);
    flush();  
    //response();
    esp.printf("AT+CIPSTART=0,\"TCP\",\"api.thingspeak.com\",80\r\n");  
    wait(5);
    flush();  
    //response();

    esp.printf("AT+CIPSEND=0,%d\r\n", sizeof(server)+15);  
    wait(3);
    flush();  
    //response();

    esp.printf("%s", server);
    esp.printf("%d", x);
    esp.printf(" HTTP/1.0\r\n\r\n\r\n\r\n\r\n");
    wait(2);
    flush(); 

    while(1) {  
        //To indicate completion
        myled = 1;
        wait(0.1);
        myled = 0;
        wait(0.1);
    }   
    return 0;  
}