Read into the buffer, shift it out only when write() says it's
written those bytes, and then don't read new data if the buffer is
full.

This properly implements WONT/DONT support which we were lacking,
and fixes negotiation with NetBSD telnetd (such as sdf.org) by
responding to ENCRYPT with DONT rather than WONT.

Keep reading while we're connected or there is data available.

The Ruby web server will now generate the MD5 and serve the built
binary, rather than doing it ahead of time and then running a web
server. This allows me to repeatedly make changes with just 'gmake'
and let another serve_ota process stay running, rather than having
to re-run serve_ota after every change to re-generate the MD5
ota.txt.

There's no point in trying to stay compatible with WiFi232, and
these are easier to remember/guess.

Anything over ~50 is blinding anyway, so reduce max brightness and
let at$led=1 be usable

These are AT*LED in the WiModem232 ROM but we use $ for these types
of commands.

From its manual:

RED – No WiFi connection
YELLOW – COMMAND mode, not connected to a server
GREEN – ONLINE (connected to server)
TEAL – COMMAND mode, connected to server
PURPLE – UPDATE mode, firmware is being downloaded/flashed
WHITE – WPS mode
BLUE – Baud rate reset (by shorting jumper pads)
BLUE/RED flashing – WiModem232 settings reset to factory defaults

We don't yet do white/blue.

Also add a 'serve_ota' make target that creates an OTA text file and
serves it. This should speed up development and allow others to
update their devices from repos other than mine.

Just remember if we had DTR during the call and if it drops, hangup,
but don't require DTR to talk.

If we get non-ASCII garbage at the start of a connection, assume
it's a new connection (without DTR) sending stuff to us at the wrong
baud rate and perform an autobaud.

Shrink cur/lastcmd buffers to save a bit of memory.

After sending AT (which serial_autobaud() will eat), most
communications software will expect an OK back, so print one to help
them move along.

Rather than continue making my own board based on the Pololu 23201a,
adapt WiFiPPP to the hardware in the ESP8266-based WiModem232.

This device has an ESP8266-12F module on a custom PCB with DB25
connector, along with an optional I2C-based SSD1306 monochrome OLED
screen (though it has separate areas on it that draw in blue or
yellow), and a NeoPixel 5050 multi-color LED with an integrated
WS2811 controller.

So far I have the screen and NeoPixel working, as well as basic
RS232 input and output with the DTR line mapped. I still need to
map out the remaining RTS, CTS, DSR, and DCD lines.

Unify on *_start() and *_stop() module names

Reconfigure ATI responses to be more like other modems, moving WiFi
scanning to ATI5 and general info to ATI4.

With echo enabled, only print \r after accepting a command, and once
the command wants to start output, it should print the \n. With ATQ
set (quiet mode), that \n is not printed since the OK or ERROR is
not printed.

Also loop through all command input so chained command sequences
like "ATEQ1" will be parsed as "ATE0" and "ATQ1".

A Pololu 23201a board based on the MAX3238 is doing RS232 to TTL
serial for us.

Start on supporting hardware flow control by only sending when RTS
is asserted.

Assert DSR and CTS after init.

Assert DCD when we're connected to telnet or PPP.

This will eventually be a port of most of my sockhole Ruby code

Static server and client IPs can be configured with AT$PPPS= and
AT$PPPC=, defaulting to 10.10.10.10 and 10.10.10.20.

There is another on GPIO 2 but this is being used by the RS232
board.

https://github.com/esp8266/Arduino/commit/47b8947e724b7441d1ad7c7eefdd6fdf691b19c1

When the CP2104 USB serial chip on the Feather ESP8266 board sees
the DTR line go low, it causes a reset of the ESP8266. This is
needed for software (esptool) to be able to put the ESP8266 into its
bootloader mode.

Unfortunately this means any serial connection closing causes a
reboot, which has to reset the MCP23S18, which can cause garbage on
its GPIO lines going to the DB25 port.

When sendload is used to upload flashloader, it sends the program
over and then closes the serial connection, causing the WiFiStation
to reboot at the same time flashloader is executing and looking for
input (the size of the program it's about to write to flash). This
can cause flashloader to read bogus size bytes, but then sendload is
used again to upload the actual program being written and now it's
writing the two size bytes to flash plus the entire program being
offset by 2 bytes.

To work around this, delay 5 seconds on startup to ignore any
potential changes on the ack/busy lines.

For some reason when WSLoader receives the final byte it's expecting
and then does its 'jp 0x8000', the ack line doesn't go low and
ms_write() has to timeout waiting for that, which looks like a
failed upload to sendload.

This could be worked around by ms_write ignoring the ack on the
final byte, but every byte counts so if it properly fails to ack, it
should be an error.

Until I can figure out why this happens (without adding a delay
before WSLoader's final jump), send WSLoader one extra null byte so
we can ignore the result of that ms_write() and still see the proper
response to the real last byte of what sendload sent.

Differentiate between failing to poll, failing to read, and failing
to compare when checksum fails.