Go Down

Topic: How do I parse Arrow Keys from Telnet Client (Read 1 time) previous topic - next topic

MF4040

I want to control servos of my wifi enabled robot using the arrow keys of my control node.
Currently I have the robot communicating with the node viva puTTY (telnet window) over a wifi connection. I can parse and control the robot with all other word commands I have however I wish to increment the speed slightly each time an arrow keys are pressed. I understand there is no ASCII code for the keys and they send two bytes instead of the standard one byte for other ASCII keys. Is there a method where I can achieve this ?

The code I am using to test looks like this
Code: [Select]

//-------Headers---------------------------------------------------------
#include <SPI.h>
#include <WiFi.h>
#include <Wire.h>

//-------Varriables---------------------------------------------------------
char ssid[] = "TEST NETWORK";     //  Broadcasted SSID
int status = WL_IDLE_STATUS;
WiFiServer server(23);            // Default Port 23
boolean alreadyConnected = false; // Flag to detect if already connected
char ch ='0';

//-------Setup---------------------------------------------------------
void setup() {
  Serial.begin(9600);   // Initialize Serial 9600 BAUD
  while (!Serial) {;}   // Wait for Serial to connect

  if (WiFi.status() == WL_NO_SHIELD) {           // If WiFi shield is not detected
    Serial.println("WiFi shield not present");   // Print error to Serial
    while(true);  }                               // Lock Up and wait for reset
  while ( status != WL_CONNECTED) {
    Serial.print("Attempting to connect to SSID: ");
    Serial.println(ssid);   
    status = WiFi.begin(ssid);                   // Start session for given SSID
    delay(10000);                }                // Wait 10 seconds for response
  server.begin();
  printWifiStatus();

}

//-------Main Loop---------------------------------------------------------
void loop() {
  WiFiClient client = server.available();
  if (client)
    {
    if (!alreadyConnected)
    { client.flush();
      Serial.println("Laptop has connected to Arduino");
      client.println("Hello Laptop, From Rover!");
      alreadyConnected = true;  }
 
   
       
    while(client.connected())
    {  if (client.available())
        {   
            ch = client.read();             //Read Byte

            if((int)ch == 279165)
            {  Serial.print("UP ARROW RECIEVED");
            }
            Serial.print((int)ch);

        }
      }
      delay(1000);
      client.flush();
      ch = '0';
    }
}



pylon

Code: [Select]
            ch = client.read();             //Read Byte

            if((int)ch == 279165)


You're reading one byte and then check for a long integer constant?

You have to read byte after byte. If you're recognizing the start byte of the arrow key sequence, store that information in a status variable. In the next round check if the next character received is one the second characters in the arrow key sequences. If not reset the status variable to the default value.

MF4040

Sorry reading the long integer was just something I was playing around with while trying to get this.
I tried treating the code as two seperate bytes earlier and it didnt work. But oddly treating the key as three bytes seems to work.

Code: [Select]
           
            ch = client.read(); 

            if(ch==27)
            { ch=client.read();
              if(ch==91)
              { ch=client.read();
                if(ch==65)
                {  Serial.print("UP ARROW DETECTED");
                }
              }
            }


Im not sure why this is though

pylon

Because all data is transferred as bytes. This is not oddly, this is how everything works. The first byte (27) is the Escape character which initiates a special sequence.

Your code is not as robust as it might be though:

Code: [Select]
    {  if (client.available())

You're testing if one character is available at least but afterwards you're reading up to 3 characters without checking again if one is available. Because usually these characters are sent in the same packet in a telnet session, this will seldom crash your sketch but if the client side is not a human typing in on a keyboard (but a program automating things a bit), you might get a problem.

PaulS

#4
Feb 13, 2013, 08:25 pm Last Edit: Feb 13, 2013, 08:43 pm by PaulS Reason: 1
Quote
You're reading one byte and then check for a long integer constant?

Yeah, but there is a cast to int.  :)

Go Up