I believe there is a bug in the WiFi programming for SimpleIDE and the terminal output

idbruce · 2020-02-21 07:31

I have attached a sample program which demonstrates what I believe is a bug, but I could be wrong and I may not being doing something properly. The sample program retrieves text from a web page on the internet. The text from the web page is the word "SUCCESS", which is 7 letters long. After retrieving the response from the website, the program breaks the response down to the content of the webpage, which as I said is 7 letters long. The program then determines the length of the content (7 letters) and outputs this number to the terminal.

Problem #1: The program is an endless loop, but only runs 7 times.
Problem #2: An extra square character is added to the front of the output occassionally.

iseries · 2020-02-21 11:04

This is technically not a bug.
The handle you got when you started the connection needs to be closed otherwise it doesn't know to release it.
You need to call wifi_disconnect(handle) to release the connection back to the pool of 5 connections.

Mike

idbruce · 2020-02-21 23:48

@iseries

This is technically not a bug.
The handle you got when you started the connection needs to be closed otherwise it doesn't know to release it.
You need to call wifi_disconnect(handle) to release the connection back to the pool of 5 connections.

I tried that function before I posted my new thread

The following code produces the same result.

#include <stdbool.h>
#include <stdint.h>
#include "simpletools.h"
#include "wifi.h"
#include <string.h>

int main()
{
  char chOldContent[10];
  char chResponse[512];
  char chNewContent[11];
  
  char * pCharacterPointer;
  
  int nHandle;
  int nSizeOfResponse;
  int nBeginningOfContent;
  int nContentLength;  
  int nContentIndex;
 
  while(1)
  {
    nHandle = 0;
    nSizeOfResponse = 0;
    nBeginningOfContent = 0;
    nContentLength = 0;
    nContentIndex = 0;
    
    memset(chNewContent, 0, strlen(chNewContent));
    memset(chResponse, 0, strlen(chResponse));
    
    wifi_start(9, 8, 115200, USB_PGM_TERM);
    wifi_setBuffer(chResponse, sizeof(chResponse));

    nHandle = wifi_connect("novelsolutionsonline.com", 80);
             
    char chRequest[] = "GET /success.txt HTTP/1.1\r\nAccept: text/html\r\nHost: novelsolutionsonline.com\r\n"
      "Connection: Keep-Alive\r\nCache-Control: no-cache\r\n"
      "User-Agent: Mozilla/5.0\r\n"
      "\r\n";
      
    wifi_print(TCP, nHandle, "%s", chRequest);
  
    pause(1000);

    wifi_scan(TCP, nHandle, "%s", chResponse);   
  
    pCharacterPointer = strrchr(chResponse,'\n');
  
    nSizeOfResponse = strlen(chResponse);
    nBeginningOfContent = pCharacterPointer - chResponse + 1;
    nContentLength = nSizeOfResponse - nBeginningOfContent;  
    nContentIndex = 0;
  
    while(nContentLength > 0)
    {
      chNewContent[nContentIndex] = chResponse[nBeginningOfContent];
      ++nContentIndex;
      ++nBeginningOfContent;
      --nContentLength;
    }
    
    print("%u", strlen(chNewContent));
    
    wifi_disconnect(nHandle);
    
    /*    
    print("%s\n", chNewContent);
    */
  }  
}

EDIT: And that is why I am testing string length instead of the string itself

I believe it is a BUG

tjw314 · 2020-02-22 01:13

I've also seen the square character.

A possible third bug is associated with pin 0. Pin 0 outputs a short pulse about once every few seconds.

iseries · 2020-02-22 11:57

I have reported this bug:
Using the tcp connect command cause a connection to be allocated from the pool but if there is a DNS error or connection error this pooled connection gets orphaned. After 5 bad connection attempts the pool is exhausted and no further connections are possible.
In sscp-tcp.c there should be sscp_close_connection(c); added before returning an error code to the calling application.

That is being worked on. I don't have this issue since I patched my version of the board already.

An easy way to check if this is happening is to watch the handle that come back from the connect command. If it changes on each connect there is a problem. Also there is a debug web page that shows a lot of good information about what is going on.

Mike

idbruce · 2020-02-22 13:57

@iseries

An easy way to check if this is happening is to watch the handle that come back from the connect command. If it changes on each connect there is a problem. Also there is a debug web page that shows a lot of good information about what is going on.

The handle remains the same with every iteration.

This is really disappointing to have this problem. I bought the WiFi module specifically for this task.

EDIT: It won't even run an endless loop. If I had just burnt my money, at least I would not have had several hours of aggravation.

iseries · 2020-02-22 14:37

Well I have check the WiFi and it is working just fine. I will try to find the bug in your code. I don't use the WiFi library from Parallax and use my own so I will need to do a little digging.

So far the answer is there.

Also you need to do "pCharacterPointer = strstr(chResponse,"\r\n\r\n");" to find the end of the Header data.

Mike

iseries · 2020-02-22 16:15

Ok, the problem with your code is that the "wifi_start" is inside the while loop which causes the opening of a serial port each time through the loop. Each serial port open uses a cog to do the processing and hence you run out of cogs.....

The garbage character you are seeing is from the code disabling the serial port when it runs the "wifi_scan" code. It doesn't need to do this but it does. This is outside the WiFi data though and does not show up in the data.

Here is some revised code that worked for me:

#include <stdbool.h>
#include <stdint.h>
#include "simpletools.h"
#include "wifi.h"
#include <string.h>

void test_print(char *, int);

char chOldContent[10];
char chResponse[512];
char chNewContent[11];
char chBuffer[512];
  
char * pCharacterPointer;
  
int nHandle;
int nSizeOfResponse;
int nBeginningOfContent;
int nContentLength;  
int nContentIndex;

int i;
char url[] = "novelsolutionsonline.com";
char chRequest[] = "GET /success.txt HTTP/1.1\r\nAccept: text/html\r\nHost: novelsolutionsonline.com\r\n"
      "Connection: Keep-Alive\r\nCache-Control: no-cache\r\n"
      "User-Agent: Mozilla/5.0\r\n"
      "\r\n";

 
int main()
{

  wifi_start(3, 4, 115200, USB_PGM_TERM);
  wifi_setBuffer(chResponse, sizeof(chResponse));

 
  while(1)
  {
    nHandle = 0;
    nSizeOfResponse = 0;
    nBeginningOfContent = 0;
    nContentLength = 0;
    nContentIndex = 0;
    
    memset(chNewContent, 0, strlen(chNewContent));
    memset(chResponse, 0, strlen(chResponse));
    
    nHandle = wifi_connect(url, 80);

    wifi_print(TCP, nHandle, "%s", chRequest);

    pause(1000);

    i = wifi_recv(nHandle, chBuffer, sizeof(chBuffer)-1);

    pCharacterPointer = strstr(chBuffer,"\r\n\r\n");
    if (pCharacterPointer != NULL)
    {
      pCharacterPointer += 4; //skip over end of header
      test_print(pCharacterPointer, 512);  //avoid sending command codes to wifi module
      nSizeOfResponse = strlen(pCharacterPointer);
      strcpy(chNewContent, pCharacterPointer);
    }

    printi("%u\n", strlen(chNewContent));
    
    wifi_disconnect(nHandle);
    
    /*    
    print("%s\n", chNewContent);
    */
  }  
}

void test_print(char *data, int size)
{
  for(int n = 0; n < size; n++)
  {
    if(data[n] <= 128 && data[n] >= ' ')
    {
      printi("%c", data[n]);
    }      
    else if(data[n] == 0)
    {
      printi("[%x]", data[n]);
      break;
    }      
    else if(data[n] == '\n')
    {
      printi("%c", '\n');
    }
    else
    {
      printi("[%x]", data[n]);
    }      
  }  
}

Mike

idbruce · 2020-02-22 20:39

@iseries

After changing the DO and DI pins, I ran your revised code, but the terminal screen doesn't show anything but a blinking cursor.

However, your TestPrint function has given me an idea that is worth checking.

EDIT: Additionally, moving wifi_start outside of the loop did allow the program to continue. Thank you for that. I appreciate it.

iseries · 2020-02-22 21:35

I have a display connected to my Propeller Mini attached to the ESP8266 unit to access the openweathermap.org data on the internet so I can get the latest weather data along with forecast information for the next 12 hours.

It runs 24x7 with no problem so yours should have no issues as well.

Mike

idbruce · 2020-02-22 23:21

@iseries

I am finally getting to the bottom of this, with your help of course. I sincerely thank you for your time and effort that you have put into assisting me.

Of course I could still be wrong, but the bug now appears to be in the communication with the SimpleIDE terminal and not in the WiFi module or the response or the actual content.

The program below does an actual comparison of the known string, in this case, the word "SUCCESS". If the comparison is equal, I instruct the terminal to output "It is equal". If the comparison is unequal, I instruct the terminal to output "It is unequal". When running the program, the output is always "It is equal", so the data is indeed intact, however the pesky little square still remains, and is output every other line.

#include "simpletools.h"
#include "wifi.h"

int main()
{
  char chResponse[512];
  char chContent[10];
  
  char * pCharacterPointer;
  
  int nHandle;

  wifi_start(9, 8, 115200, USB_PGM_TERM);
       
  while(1)
  {
    nHandle = 0;
    
    memset(chResponse, 0, strlen(chResponse));        
    memset(chContent, 0, strlen(chContent));    

    wifi_setBuffer(chResponse, sizeof(chResponse));

    nHandle = wifi_connect("novelsolutionsonline.com", 80);
             
    char chRequest[] = "GET /success.txt HTTP/1.1\r\nAccept: text/html\r\nHost: novelsolutionsonline.com\r\n"
      "Connection: Keep-Alive\r\nCache-Control: no-cache\r\n"
      "User-Agent: Mozilla/5.0\r\n"
      "\r\n";
      
    wifi_print(TCP, nHandle, "%s", chRequest);
  
    pause(1000);

    wifi_scan(TCP, nHandle, "%s", chResponse);   

    pCharacterPointer = strstr(chResponse,"\r\n\r\n");
    
    if(pCharacterPointer != NULL)
    {
      pCharacterPointer += 4;
      strcpy(chContent, pCharacterPointer);
    }      
    
    wifi_disconnect(nHandle);
    
    if(strcmp(chContent, "SUCCESS") == 0)
    {
      print("%s\n", "It is equal");
    }
    else
    {
      print("%s\n", "It is unequal");
    }
  }  
}

David Betz · 2020-02-22 23:30

idbruce wrote: »

    memset(chResponse, 0, strlen(chResponse));        
    memset(chContent, 0, strlen(chContent));

I doubt this has anything to do with your problem but these lines should probably be:

    memset(chResponse, 0, sizeof(chResponse));        
    memset(chContent, 0, sizeof(chContent));

idbruce · 2020-02-22 23:52

@David Betz

I doubt this has anything to do with your problem but these lines should probably be:

I agree completely. I don't know what I was thinking

Thanks for that catch David, I appreciate it.

iseries · 2020-02-23 11:22

The 0xFF characters you are seeing is coming from WiFi library function shown here:

void wifi_simpletermSuspend(void)
{
  if(wifi_comSelectPin != USB_PGM_TERM)                      
  {
    if(wifi_comSelectPin >= 0)
      high(wifi_comSelectPin);
  
    // Input prevents spurious nonprinting character in Wi-Fi-only mode on close.  
    input(wifi_pin_di);  
    simpleterm_close();
  }    
}

This is putting the input pin into high mode causing the serial driver to input a bunch of 0xff characters into the terminal connection. They don't effect the data coming from the WiFi module so all is good.

I guess this is a bug since the variable "wifi_comSelectPin" is never changed and is always zero.

Mike

idbruce · 2020-02-23 11:44

@iseries

The 0xFF characters you are seeing is coming from WiFi library function shown here:
void wifi_simpletermSuspend(void)
{
if(wifi_comSelectPin != USB_PGM_TERM)
{
if(wifi_comSelectPin >= 0)
high(wifi_comSelectPin);

// Input prevents spurious nonprinting character in Wi-Fi-only mode on close.
input(wifi_pin_di);
simpleterm_close();
}
}

This is putting the input pin into high mode causing the serial driver to input a bunch of 0xff characters into the terminal connection. They don't effect the data coming from the WiFi module so all is good.

I guess this is a bug since the variable "wifi_comSelectPin" is never changed and is always zero.

Mike

Now that we have gotten to the bottom of this problem, mostly you

, hopefully Parallax will fix it, which will help prevent future users of the WiFi module from going "BONKERS" and wasting time on a futile endeavor.

Thanks Mike

I believe there is a bug in the WiFi programming for SimpleIDE and the terminal output

Comments