Teensy 3.1 and ESP266 UART communication issue

Status
Not open for further replies.
J

jpatrick62

Well-known member
Hello, I am submitting this hoping someone else has run up against this and can help. I am using the ESP8266 with Teensy3.1, making use of AT communication over serial1. Everything seems to be going well
except for large packet transfers. When I issue an AT+CWLAP command from the teensy, I might expect a list of access points back from the ESP8266, and that list may be up to 640 bytes (if there are 10+ access points).
Here's my issue: I get the first 64 bytes only, and after that nothing. Now I should mention that I employ 2 encoder switches, to which I use 4 interrupts for processing gray scale, 1 interrupt for the MSB and 1 for the LSB. However,
neither of these interrupts is firing at this time (they would fire during the CheckLeftSelectPin -> checkRightRotation funtions if they did) as I have used the encodeers to display the "View Access Points" menu on my LCD.
The LCD is a I2C 2x20 display that will hopefully allow you to roll through the available Access Points (as deleivered by the ESP8266 over the UART to the teensy). Here is the pertinent section of code that I have debugged through -
I have remmed out all but the serial 1 UART commands and Serial writes, but still only 64 bytes.

Code: 
#define UART1 Serial1
char szUartBuffer[MAX_CHANNEL_VALUE] = { 0 };

/////////////////////////////////////////////////////////
void loop()
{
  CheckLeftSelectPin();
  CheckRightSelectPin();
  checkLeftRotation();
  checkRightRotation();
  updateMenu();
  displayMenu();
  
  while(UART1.available())
  {
	  //get stuff from Teensy UART (sent from 8266) DEBUG
          
	  Serial.write(UART1.read());
	

/*
	  iChars = readUART(UART1.read(), szUartBuffer, MAX_CHANNEL_VALUE);
	  if (iChars > 0)
	  {
	      processWifiReply(szUartBuffer);
              memset(szUartBuffer, 0, MAX_CHANNEL_VALUE);
              Serial.println("Outstanding requests is set false");
              UART1.flush();
              bOutstandingUartWifiRequest = false;
              
              //Debug
              if( iNumAPEntries > 0)
              {
                Serial.println("List of AP Entries:");
                for(int i = 0; i < iNumAPEntries; i++)
                {
                   Serial.println(szAPs[i]);
                }
              }
	  }
*/
  }
  

  
  if(Serial.available())
  {
	  UART1.write(Serial.read());
  }
  
  
  delay(150);
}

I have seen other posts where an increase in the buffer size on the teensy3.1 may be needed, is this the only way to go? Thanks in advance for any input!:cool:
 
jwmelvin, thanks for the reply. I could increase the buffer, but then my question is by how much. I suppose I could go 640 if I suspected the max number of Access Points returned from the ESP8266 would be 10.
 
Your program has a delay of 150 ms can you remove that? The problem is probably you're not reading the data from the Serial1 buffer fast enough. If you increase the buffer to 640 you still need to "read" that data out for more data to come in if that buffer fills up, this would give you more headroom in your sketch if there are delays before reading the serial1 buffer though. If your data is packet based and has terminating character I wrote library that gives you interrupt when either the buffer is full or a termination character is found. It is here.
 
Please comment-out this part :
Code: 
  CheckLeftSelectPin();
  CheckRightSelectPin();
  checkLeftRotation();
  checkRightRotation();
  updateMenu();
  displayMenu();

And remove the delay
 
FrankB and Duff, thanks for the replies, much appreciated. Frank, I could comment out those routines, but then the 2 gray scale encoders (which have interrupt events each attached) would not work and thus the menu driven
interface (I2C LCD 2 x 20) would be inoperable. The idea is that the 2 encoders allow the user to choose which Access Point to use (from the list retrieved by the ESP8266), as well as mode of operation, etc. Duff, I'm not up on DMA
as well as you are, but your library may be just what I am looking for. A callback function operated off an event would be ideal, particularly if it signaled the end of a 640 byte UART stream from the ESP8266. I believe the ESP8266 returns each Access
Point found (along with signal strength and type) with a CR and LF (one for each AP found). All other UART communication works ideal, probably because it is very small in nature.
 
You can set the termination character to LF and process each packet individually in that event callback. Or set an event to certian number of chararters recieved or even both with a few detials left out. But did you try getting rid of that delay and see if regular serial works for you?
 
I did not check out the delay fully. My home net only has one AP so the problem doesn't show up there. I will find out Friday when I go to a shop with multiple Aps scattered throughout the building. Thanks
for the library - I'll check that out as well.
 
So I increased the buffer size in serial1.c from 64 to 640 and everything started working correctly, i.e. the ESP8266 returns a list of access points that the user can now choose via dual encoders.
However, I'm really not fully satisfied with this as it doesn't appear to be very dynamic, and limits the return size. So I will try out duff's library in the very near future when I get all the features of the
product implemented. Thanks for all the help!
 
I haven't worked with ESP units these yet - but will by year's end. And haven't done anything with Duff's code.

Question: This huge stream of AP's - could you pre-process the results on the ESP processor and pare down or prioritize the firehose flow of info? Exclude weak signals - or buffer them in the ESP RAM and then request them one at a time?

Also there is a built in interrupt routine serialEvent#() function that will allow you to empty the incoming stream to your own buffer - it is called on any yield() or loop() exit.
 
Status
Not open for further replies.
Back
Top