RC2014

The initial testing of the ESP8266 board with the RC2014 was pretty good, and fundamentally it worked.  However, it wasn’t quite right, and I suspected that the problem was to do with CR or LF.

The code I was using was found here; https://github.com/tzapu/WebSocketSerialMonitor (Thanks Tzapu!).  It uses web sockets, and allows an external web page to connect through to the ESP8266.  So, by going to http://tzapu.github.io/WebSocketSerialMonitor/ and connecting to ws://x.x.x.x:81/ws (where x.x.x.x is my external IP address and a firewall rule is set up to forward port 81 through to the internal address of the ESP) it will display everything the ESP receives on its Rx pin.  Well, almost everything, but not quie everything.

If, for example, I did a directory listing which was 2 full lines and a little bit more on the 3rd line, only the first 2 lines would show up.  If I’m playing Zork, sometimes it would show the whole chunk of text as it came in, other times it would miss the last line.

The code itself is fairly easy to read, although the complicated web sockets stuff is hidden away in libraries.  This is the part of the routine that reads the serial input until it detects a CR (the ‘\n’ part), where upon it then sends the line;

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    if (inChar == '\n') {
      stringComplete = true;
      return;
    } else {
      inputString += inChar;
    }
  }
}

I figured that adding a check for a LF would do the job;

if (inChar == '\n' || inChar == '\r') {

But, sadly, it didn’t.  If anything, it made it worse.  So, instead, I tried just reading a set amount of characters (10 initially) and sending them regardless of a CR or LF, but that didn’t work either.  When I got it to send every character without checking, it worked much much better, although if I sent a very large chunk of text it would miss random bits of it.

So, the problem seemed to be speed related.  The checking for CR was a nice idea by the original author, but it wasn’t something I needed, so time to strip out all the surplus code.  It went from this;

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    if (inChar == '\n') {
      stringComplete = true;
      return;
    } else {
      inputString += inChar;
    }
  }
}


void loop() {
  serialEvent();
  if (stringComplete) {
    
    String line = inputString;
       // clear the string:
    inputString = "";
    stringComplete = false;

    //line += '\n';
    webSocket.broadcastTXT(line);
    Serial.println(line);
  }
  webSocket.loop();
}

to this;

void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();
    inputString += inChar;
  }
}

void loop(){
  serialEvent();
  webSocket.broadcastTXT(inputString);
  inputString="";
  webSocket.loop();
}

Much simpler, and it seemed to work perfectly!

All the testing up until this point was done either on my laptop or mobile.  Although they are on the same wifi network as the ESP, it’s connecting out to an external web page before coming back in, so it should be a reasonable test.  But there’s nothing like real people connecting in to really see if it works.  So, I put a shout out on Twitter, and on Saturday evening, 4 willing volunteers sat there watching me do random things on the RC2014.

Feedback was pretty good, and it all seemed to work as expected.  Thanks Thilo for this screenshot;

I messed about with simple programs in BASIC, directory listings, and the opening moves in Zork, with success.  In a moment of madness, I fired up Wordstar.  When the RC2014 is connected to a VT100 terminal, it works great by using escape codes to set where things are on the screen and what colours are used.  However, these escape codes don’t render at all well on the web sockets interface.  Thanks Dave for showing my just how bad it looked!

So, yes, I should have known that Wordstar would be pushing it a bit far.  But otherwise, I was very pleased with the performance.

The biggest problem I had, though, was that of feedback when interacting with the “audience”.  I could type short sentences in to Zork that the viewers would see and understand, even if the Zork engine couldn’t interpret it.  But, of course, there was no live feedback from the viewers.

I’m not sure what the solution to that will be, but it could be as simple as keeping Twitter open on my phone.  Alternatively, things like IRC or Slack could be used (although I don’t want viewers to have to jump through hoops to get connected to me).  Skype might be an option too, although, at the moment, I think it’s more likely I’ll set up a YouTube live stream and use the chat feature in that.

For those wondering about the set up that I’m using, it’s pretty much a stock RC2014 Pro with a Pi Serial Terminal and the ESP8266 prototype I built for this project.  The Pi Zero is connected via a HDMI > VGA adapter, and then to a 17″ monitor.  The keyboard is this Cherry keyboard from the last Retro Challenge.  Note that the key layout is sufficiently different from what I’m used to that typos aren’t too uncommon yet.

The laptop is there to program the ESP, and to monitor it’s output.

I am aiming to have a live run through on Friday, so that gives me a few days to look in to the feedback options.