Esp8266 & String untersuchen

Selbst wenn ich nach dem senden des CMD in der while ganze Zeit den Buffer abfrage tut sich nichts.
Da muss doch irgendwas faul sein.



CodeBox C
int main(void)
{
  uart1_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU));
   uart_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU));
   
   sei();   
   
   uart1_puts("AT\r\n");


  while (1)
  {
     uart_puts(ReBuff.Buff);   
  }
}
 
Also da passt was ganz und garnicht o_O:
Leider kommt da nichts rein, erst wenn ich es in der while() zyklisch aufrufe. Woran kann das liegen?
Selbst wenn ich nach dem senden des CMD in der while ganze Zeit den Buffer abfrage tut sich nichts.

Die Ursache kann an vielem liegen. Die Routinen usart1_init und usart_init kenne ich nicht, stimmt die Konfiguration der Usarts? Gesendet wird über Polling des UDRE Flags, empfangen über Interrupt?
 
Hier ist die Init


CodeBox C
void uart1_init(unsigned int baudrate)
{
  UART1_TxHead = 0;
  UART1_TxTail = 0;
  UART1_RxHead = 0;
  UART1_RxTail = 0;
   

  /* Set baud rate */
  if ( baudrate & 0x8000 )
  {
     UART1_STATUS = (1<<U2X1);  //Enable 2x speed
  baudrate &= ~0x8000;
  }
  UBRR1H = (unsigned char)(baudrate>>8);
  UBRR1L = (unsigned char) baudrate;

  /* Enable USART receiver and transmitter and receive complete interrupt */
  UART1_CONTROL = _BV(RXCIE1)|(1<<RXEN1)|(1<<TXEN1);
   
  /* Set frame format: asynchronous, 8data, no parity, 1stop bit */   
  #ifdef URSEL1
  UCSR1C = (1<<URSEL1)|(3<<UCSZ10);
  #else
  UCSR1C = (3<<UCSZ10);
  #endif
}/* uart_init */


Selbst wenn ich das in der while() habe, kommt es mal so und mal so... bekomme selten zwei mal den gleichen string... mal fehlt ein zeichen mal ist es verschoben :(
 
Du hast dir wahrscheinlich die beiden Init-Routinen angepasst an USART1 und USART0, hast du auch 0 und 1 richtig angepasst? Wahrscheinlich schon, sonst würde überhaupt keine Übertragung stattfinden.

usart_puts gibt sicherlich ein String aus, der mit 0 abgeschlossen ist. Wenn du das einfach permanent in der while(1) Schleife aufrufst, passiert das ja während der Buffer gefüllt wird und bei dem Buffer ist ja ein Stringende nicht definiert. Da ist also die Ausgabe nicht klar, zufallsbedingt.
Du musst also erst einmal dafür sorgen, dass der Eingangsbuffer richtig gefüllt wird. Dann ein Stringende erzeugen (0) und dann dem Hauptprogramm mitteilen, dass gültige Daten vorhanden sind.
 
Woher weiß ich denn das ich neue Daten bekommen habe? Du meinst wenn z.B die Routine 2 mal aufgerufen wurde oder wenn der Buffer voll ist?
 
Also Buffer voll geht nicht, weil ja die Antwort nicht immer die selbe Länge hat. Das ist nun abhängig vom Protokoll, da musst du mal schauen, welche Daten nach einem bestimmten Kommando zurückgesendet werden können. Eventuell gibt es je nach gesendetem Kommando eine feste Zeichenzahl oder es wird eine Abschlusssequenz gesendet ("\r\n"). Gibt es nicht zufällig fertigen Soucecode (Arduino oder so), da muss man nicht das Datenblatt so sehr durcharbeiten ;)
 
Jetzt bekomme ich zumindest schon mal die korrekte Antwort, das auch in der main()



CodeBox C
  uart1_puts("AT\r\n");
   while(!ReBuff.NewData)
   {
   }
   uart_puts(ReBuff.Buff); 




CodeBox C
ISR(USART1_RX_vect)
/*************************************************************************
Function: UART1 Receive Complete interrupt
Purpose:  called when the UART1 has received a character
**************************************************************************/
{
   DDRB |= (1<<PB7);
   ReBuff.Buff[ReBuff.Cnt++] = UART1_DATA;
   if (ReBuff.Cnt >= 11)
   {
     ReBuff.Buff[12] = '\0';
     ReBuff.NewData = 0x01;
     ReBuff.Cnt = 0x00;
   }
}
 
Also ich habe es jetzt erstmal sehr unflexibel hinbekommen, dass ich über Internet ne LED ein und ausschalten kann.
Leider musste ich feststellen, dass wenn ich über PC Daten sende, er mir ein paar andere Zeichen dazwischen haut. Daher ist das was ich aktuell treibe, mit den Strings vergleichen ziemlich doof, dass würde jetzt aktuell bedeuten, ich könnte es nur vom Handy aus steuern...



CodeBox C
    if (ReBuff.newData)
     {   
       DDRB  |= (1<<PB7);
       uart_puts(ReBuff.Buff);
       if (strncmp(ReBuff.Buff,"\n+IPD,0,2:1q",14) == 0)
       {
         PORTB |= (1<<PB7);
       }
       if (strncmp(ReBuff.Buff,"\n+IPD,0,2:0q",14) == 0)
       {
         PORTB &= ~(1<<PB7);
       }
       ReBuff.newData = 0;
     }
 
hmmm...,
wie lautet der orginal string und wie sieht er aus, wenn du ihn empfängst?
addi
 
Wo kommen denn da was für Zeichen?

Das \n gehört eigentlich gar nicht mehr zum empfangenen Telegramm, das solltest Du beim Empfang am UART bereits rausfiltern.
+IPD sagt Dir, daß das Modul irgendwas an Dich weiterleitet, also empfangen hat.
die 0 steht für den ersten Verbindungspartner des Moduls als Sender. Haben mehrere mit dem Modul verbunden, steht dort eben ggf 'ne 1, 2, usw...
die 2 sagt Dir, daß (nach dem Doppelpunkt) zwei Bytes Daten folgen - die sind Dein übertragener String.

Wenn entsprechend eingestellt (AT+CIPDINFO=1), kann vor dem Doppelpunkt auch noch was zur Remote-IP und zum Remote-Port kommen.
Ist das Modul auf Single Connection eingestellt (+CIPMUX=0), kommt nach +IPD gleich die Stringlänge...

Im Prinzip mußt Du auf das +IPD am Anfang reagieren, ggf mehrere Teilnehmer behandeln, die Anzahl der zu lesenden Bytes erfassen, auf den Doppelpunkt warten, und dann die entsprechende Anzahl an Bytes in Deinen Puffer lesen.
DAS ist dann Dein Nutzstring, den Du ggf mit einem eigenen Protokoll schützt/absicherst (-> addi), und bei dem Du jetzt abfragst, welches Deiner Kommandos es ist...
 
Hmmmm...,
Wuerde einen Buffer fuer den uart nehmen, der die max. Datenlaenge plus Header aufnehmen kann.
Ist der Satz komplett im Buffer, dann auslesen und am : splitten. Die linke haelfte des Satzes verwerfen, die rechte
Entsprechend parsen.
Vielleicht so?
Addi
 
Ja, wobei die Informationen links vom Doppelpunkt eben auch interessant sein könnten. Zum Beispiel, wenn mehrere Geräte mit dem Modul verbunden sein können (sollen), und dann unterschiedlich reagiert werden soll. Unter Verwendung bestimmter AT-Kommandos sollte man dann auch mehr über den Verbindungspartner herausbekommen können.
Wenn das alles nicht interessiert, kann mans natürlich ignorieren.

Wenn eh nur mit einem externen Gerät (gleichzeitig) verbunden werden soll, wäre vielleicht der "UART-WIFI passthrough mode" interessant.
 
@LotadaC,
Da hast du recht..mit dem linken teil.
Ich bin vom einfachsten aller faelle ausgegegangen: 1 teilnehmer. Eben kiss.
Beliebig kompliziert geht immer, meistens.
Addi
 
Also das klingt ja alles sehr gut. So ungefähr habe ich mir das auch gedacht.
Leider kommen zwischendurch ein paar Sonderzeichen, was darauf schließen lässt das irgendwas bei der Übertragung schief geht. Wenn ich mich mit einem PC Terminal da zwischen klemme, kommen keine Sonderzeichen. Also muss irgendwann, irgendwie die Kommunikation mal ziemlich Asynchron sein...
 
Hmm...,
Sei so nett und skiziere mal deine verbindung, also wer mit wem und wie
Addi
 
Hallo addi,

Wie meinst du das genau?
Die Leitungen gehen einfach an Rx und Tx.
Natürlich habe ich beides steckbar gemacht, so dass ich entweder nur den USB TTL Adapter dran habe oder den AVR
 
Ich wollte eigentlich nur wissen, von wem dieses modul angesteuert wird.
Und wo deine 'schmierzeichen' auftreten.
Bereits auf der sendeseite odervim empfangszweig?
Addi
 
Achso.
Also... Wenn ich mit einem USB --> TTL Adapter die Daten empfange, ist alles sauber.
Sobald ich mit dem AVR die Daten einlese, kommt es ab und zu, zu Übertragungsfehler.
Mal fehlt da was, mal ist da was mehr... Also muss es beim AVR liegen...

so lese ich aktuell ein



CodeBox C
ISR(USART1_RX_vect)
/*************************************************************************
Function: UART1 Receive Complete interrupt
Purpose:  called when the UART1 has received a character
**************************************************************************/
{   
   ReBuff.Buff[ReBuff.cnt++] = UART1_DATA;
   if (ReBuff.cnt >= ReBuff.awaitBytes)
   {
     ReBuff.Buff[ReBuff.cnt -1] = '\0';
     ReBuff.cnt = 0;
     ReBuff.newData = 0x01;
   }
}
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)