The Spectrum Next wouldn’t be a complete machine without the ability to talk to the world around it, and as part of the Kickstarter stretch goal, we’re working on its internet connectivity and tools.
In this first article, we’ll explain how the ESP8266 WiFi module works on the Next, regardless if your computer has it by default or if you socketed one yourself.
Let’s start with explaining how the RS232 (the Next serial port where the ESP module fits in) works on a hardware level.
Technically it’s not a real “RS232” because it doesn’t use analog voltages in this connector, going for digital (TTL) instead, but it uses the same protocol nonetheless, just like an Arduino, Raspberry Pi, and other recent boards.
You can even use this connector with your own TTL/RS232 module (thousands available on eBay) for the comms, but for now, our main use will be for ESP8266, the wifi module selected for the Next.
The ESP module uses the “AT instruction set” of a typical modem and the official PDF is available here:
It’s worth noting this article refers to the off-the-shelf ESP module with the standard firmware, which can be plugged at the Next board, no changes or extra firmware needed and it should work out of the box. If you mess around with third-party firmware, it’s another story…
The UART on Next board (built inside the FPGA logic) can control the RX/TX lines from 2400 bps up to 115200 bps (the default speed).
The UART has a buffer an can receive 256 chars asynchronous, so the Next can be doing other tasks and the buffer will be filled anyway (multitasking!)
Note the ESP doesn’t have flow control, so after the buffer is filled you will start losing data if you not empty the buffer to make way for incoming data.
The ports are 0x143b = 5179 for RX and 0x133b = 4923 for TX.
A write on RX port configures the UART speed:
0 = 115200 (default at reset)
1 = 57600
2 = 38400
3 = 31250
4 = 19200
5 = 9600
6 = 4800
7 = 2400
Regardless of how you configure the speed, the “data bits”, “parity bit”, and “stop bit” are always in the “8N1” format. We made this fixed to keep things simpler and standard.
Writing a byte on TX port send it in a serial form immediately at the selected UART speed.
On the RX, the buffer it’s a common FIFO and even when you are reading (each read takes one byte from the buffer and make room from another byte) the buffer can still receive new data.
My suggestion is to move the data from the buffer to memory when you need big chunks of data. Reading the buffer is a LOT faster than the maximum UART speed, so it’s easy to empty the buffer even during an RX session.
A read on the TX port shows the status of the FIFO buffer and the TX line
bit 0: returns ‘0’ if the FIFO buffer is empty or ‘1’ if there is data to be collected.
bit 1 returns the TX status: ‘1’ when the TX still transmitting the last byte or ‘0’ when the TX is idle.
bit 2: return the FIFO buffer status: ‘1’ if the buffer is full, or ‘0’ when the buffer have space to hold another incoming byte.
This makes implementing your own app talking to the module a breeze. Once you connect the module to a WiFi access point, it has TCP functions via the AT command set enabling communications to any services on the web.
As a side note, most ESP modules come with 115200 bps set by default, but some older ones come configured at 57600 and there are even odd ones at 19200 bps. Thus, if you can’t get a proper response from the module at first (get garbled responses instead), try another speed to start talking to it, then use the AT command set to permanently set its speed to 115200.
Check the first test of the module and UART: