PropGCC program to use with telnet - help

Rsadeika

The program below is not working as expected. When it first starts up, I get a lot of garbage characters. When I type in 'help', I get the menu, but I also get an 'Invalid Command' after that. Not sure why that is occurring. Is the menu() somehow sending a garbage character after the subroutine runs?

I tested this with Putty and Tera Term, and I get similar results. Anybody have any suggestions as to what is going on.

Thanks

Ray

/*
  flip_telnet.c
  June 23, 2020
*/
#include "simpletools.h"
#include "simpletext.h"
#include "fdserial.h"
serial *telnet;

void crMenu();

int main() 
{
  // Add startup code here.
  //char inBuff[40];
  int inBuff;
  telnet = fdserial_open(31, 30, 0, 115200);
  
  //print("Type 'help' to see system menu.\n");
  writeStr(telnet,"Type 'help' to see the system menu.\n");
  //print("Type 'help' to see system menu.\n");
 
  while(1)
  {
    // Add main loop code here.
    
    writeStr(telnet,"> ");
    //print("> ");   
    readStr(telnet,inBuff,sizeof(inBuff));
    //getStr(inBuff,40);
    if(!strcmp(inBuff,"help"))
    {      
      crMenu();
    }       
    else
    {
      writeStr(telnet,"Invalid Command!\n");
      //print("Invalid Command!\n");
    }
    //inBuff = 0;
    //pause(500);      
    
  }  
}


void crMenu()
{
  writeStr(telnet,"\n          System Menu\n");
  writeStr(telnet,"help - Show the System Menu.\n");
  //print("          System Menu\n");
  //print("help - Show the system menu.\n");
}  

Telnet terminal

#H¾gáJl=Ö,®rRi_^úñm¼ôZ»Aô&ëype 'help' to see the system menu.
helplp
System Menu
help - Show the System Menu.
>
Invalid Command!
>

ersmith

"inBuff" is declared as an integer (4 bytes) but you're treating it as a string and presumably trying to store at least 5 bytes ( the string "help", including its terminating zero) into it. This will not go well .

Rsadeika

I changed "inBuff'" to "char inBuff[20];". It seems like typing in 'help' the first time worked, the second entry I get Invalid Command. It looks like somehow the readStr() is not working as expected, I think. Not sure what other function I could use to accomplish the same thing.

Ray

gáJl=Ö,®rRiZúñm´ôZ»Aô&ëype 'help' to see the system menu.
> help

System Menu
help - Show the System Menu.
> help
Invalid Command!
> help
Invalid Command!
>

ersmith

I find it's usually helpful to echo what you just read when trying to debug this kind of thing (i.e. to print out inBuff to see what was actually read).

Rsadeika

There is something weird going on between PropGCC, the SimpleIDE simpletools version and how Tera Term and Putty handles the C code, I think.

In my simple program, it seems that the terminal programs are not interpreting the 'else' part correctly. It looks like when I type in 'help', it does the crMenu() function, as expected, and then it does the 'else' also. I am expecting that when the 'help' part is processed it is supposed to bypass the 'else' part. I could be wrong about this.

Ray

ersmith

The terminal program used will have no effect on the code itself, but it may affect what data the code reads. Again, try printing out the contents of inBuff before trying to compare it, so you can see exactly what your program read and compare it with what you expect it to read. I think it's clear that inBuff does not contain the string "help" the second time through, so the question is what is in there? Are there some extra carriage returns or line feeds, or some garbage characters?

Rsadeika

Yes, I already tried that and it shows 'help' no extra chars or spaces or anything.

What I am doing is a print("%s\n,inBuff") and I have the simpleide terminal window opened up. In the simpleide terminal window I see what was typed in on the Tera Term window. This is getting to be complicated just test this out.

Ray

ersmith

There must be some extra invisible characters (like spaces) after the 4 letters h, e, l, p. Try printing strlen(inBuff); also, for debug I would normally do something like printf("[%s]\n", inBuff) so that the [] shows how the string is delimited. Whatever you have may look like "help", but if strcmp(inBuff, "help") is not returning 0 then it is not the 5 characters that match the C string "help" + trailing 0.

Rsadeika

I think I located the problem. It looks like a setting in Tera Term.

In Tera Term, it has a Terminal Setup window, and that contains some choices for "New-line". The Receive - CR, CR+LF,LF,AUTO. The Transmit - CR,CR+LF,LF.

I had the Transmit set to "CR+LF", so, I guess when I hit "enter" on the keyboard it was sending a CR+LF. I thought that readStr() needed a CR+LF, but I guess all it needs is either a CR or an LF.

Now with Putty I did not see that kind of Setup window, and I think it sends a CR+LF when the "enter" key is keyed.

That was some subtle stuff that had to be worked out. In this particular case it seems that readStr() works correctly with either a CR or an LF.

Ray

Rsadeika

Some further testing, I noticed that the WX WiFi SIP module becomes unresponsive after it sits idle for awhile. I could not determine what that idle time is, but to get it too become responsive again, you need to power off the WX WiFi SIP module. Not sure if this means I have a faulty module or if this is some built in feature for the module.

In the Settings for the WX module I did not notice anything that addresses that, maybe like an always responsive choice. The cure, so far is to power off the WX module and then power on the module.

Ray

Rsadeika

Below is the program that I am using to work with the telnet.

So far I tried out Tera Term, Putty, and Windows telnet. The Tera Term program, once you make the correct settings, seems to work OK. Putty and Windows telnet have CR+LF tied to the "enter" key, which does not work as expected.

The WX WiFi SIP module, is still a mystery, as to why it is becoming unresponsive to the terminal programs, after being idle for some time. I guess nobody from Parallax is reading this thread to propose a solution.

For a solution to the CR+LF, I was thinking probably that the readStr() function should be improved to provide some kind of parsing or manipulation of the input string to make readStr() work as expected.

Now to see what else trips up readStr(), the WX SIP module, or even the FLiP module.

Ray

/*
  flip_telnet.c
  June 23, 2020
*/
#include "simpletools.h"
#include "simpletext.h"
#include "fdserial.h"
serial *telnet;

void crMenu();

int main() 
{
  // Add startup code here.
  char inBuff[20];
  telnet = fdserial_open(31, 30, 0, 115200);
  
  writeStr(telnet,"Type 'help' to see the system menu.\n");

  while(1)
  {
    // Add main loop code here.    
    writeStr(telnet,"> ");  
    readStr(telnet,inBuff,20);
    if(!strcmp(inBuff,"help"))
    {  
      crMenu();
    }       
    else
    {
      writeStr(telnet,"Invalid Command!\n");
    }

    pause(500);      
    
  }  
}


void crMenu()
{
  writeStr(telnet,"\n          System Menu\n");
  writeStr(telnet,"help - Show the System Menu.\n");
}  

Wuerfel_21

For a command parser like this, you likely want to just strip off any trailing whitespace/control characters.
Something like this:

void strip_trailing(char *str) {
    char *ptr = str+strlen(str);
    while(*--ptr <= 0x20 && ptr >= str) *ptr = 0;
}

macca

Rsadeika wrote: »

So far I tried out Tera Term, Putty, and Windows telnet. The Tera Term program, once you make the correct settings, seems to work OK. Putty and Windows telnet have CR+LF tied to the "enter" key, which does not work as expected.
[...]
For a solution to the CR+LF, I was thinking probably that the readStr() function should be improved to provide some kind of parsing or manipulation of the input string to make readStr() work as expected.

The source for the readStr function is in Learn/Simple Libraries/TextDevices/libsimpletext files getStr.c and safe_gets.c. As far as I can tell (haven't tested) it doesn't handle LF correctly: when you type a string it ends the loop with CR however LF is still in the receive buffer so when readStr is called again it ends immediately returning en empty string, so you have an alternance of typed/empty strings when CR/LF is enabled.

The problem with telnet is probably due to it sending a NUL character (0x00) after each line, so after the first typed string, the first character it puts on the buffer is a NUL, which is a string terminator, and all your comparisons fails. You can easily verify this if you print a hex dump of your string buffer after readStr, after the first string you should see \0 H E L P \0 every time.

Unfortunately I don't think there is way to prevent telnet from sending that NUL (I think putty does the same) but it can be easily filtered from safe_gets by adding an if before (*buf++) = ch so it adds only printable characters (ch >= 32 && ch <= 127). Or you can try ExtraPutty that has some additional settings.

Hope this helps.

Best regards,
Marco