ESP and Serial
The Next reaches the network through an ESP8266 WiFi module on its first serial port, UART 0, which software drives with AT commands. Bizmuth wires that serial line to one of four endpoints. Nothing is attached unless you ask, so a guest program opens no host connection by default.
bizmuth --machine next --esp espEndpoints
--esp | Far end of the serial line |
|---|---|
null | nothing; the default |
loopback | the line itself: every byte the guest sends comes back |
bridge | a TCP port on the host, for a real module or another program |
esp | a virtual ESP8266 inside Bizmuth, which opens connections with host sockets |
--esp and --esp-port apply to one run. The esp.endpoint and esp.port keys in the config keep a choice; see Config File.
Bytes cross the line at the baud rate the guest programs, whichever endpoint is attached.
Virtual ESP
--esp esp answers the AT commands NextZXOS’s network software uses, in the exact byte form an ESP-01S module running AT firmware 1.3.0.0 sends, and carries the connections through the host’s network.
| Command | Answer |
|---|---|
AT, ATE0, ATE1 | OK; ATE0 and ATE1 turn echo off and on |
AT+RST | OK, then the module restarts; see Reset |
AT+CIPMUX=0 | OK |
AT+CIPSTART="TCP","HOST",PORT | CONNECT, then OK, once the host connection opens |
AT+CIPSTART="UDP","HOST",PORT | the same, for a datagram target. Any link type other than TCP or UDP, lowercase included, answers Link type ERROR |
AT+CIPSEND=N | the > prompt, then the next N bytes are sent |
AT+CIPCLOSE | CLOSED, then OK; ERROR when nothing is open |
AT+CIPSTATUS | STATUS:3 with a connection open, STATUS:4 without; after a reset, STATUS:5 until it rejoins and STATUS:2 until the first connection |
AT+CWJAP? | joined to an access point named Bizmuth |
AT+CIPSTA? | address 10.0.2.15, gateway 10.0.2.2, netmask 255.255.255.0 |
AT+GMR | the 1.3.0.0 firmware’s version lines |
Any other command, and an empty line, answers ERROR.
A line is read as the module reads it. It is complete at LF, and the command runs from the first AT or at in it to the first CR after that; anything before the prefix or after the CR is ignored. Only the prefix may be lowercase, so atE0 is accepted and ate0 is not, and a line with no CR, or a trailing space, answers ERROR.
Echo matches the module. Every byte but LF comes back, and a line holding AT is followed by CR LF before its reply: AT sent with CR LF returns AT\r\r\n\r\nOK\r\n.
Data arriving from the host is delivered as +IPD,N: followed by N bytes, and CLOSED follows when the far end hangs up.
The virtual module reports itself joined to a network, with an access point and addresses that are coherent and not real, so software that checks for a network before connecting proceeds. There is no radio: AT+CWLAP and joining a named network are not provided.
Echo starts off. A real module powers up echoing, and NextZXOS never turns it off: its boot sends only AT+UART=115200,8,1,0,0. An application that does not send ATE0 itself would read its own commands back as replies.
One connection is open at a time, as AT+CIPMUX=0 sets on real firmware.
Reset
AT+RST answers OK and restarts the module, taking the time an ESP-01S does:
After OK | The module sends |
|---|---|
| 100 ms | the boot ROM’s banner, the start-up output garbled by its other baud rate, then ready |
| 1.0 s | WIFI CONNECTED |
| 1.8 s | WIFI GOT IP |
A command sent before ready has gone out is lost. An open connection is dropped without CLOSED. The restarted module echoes, as real firmware does, and reports STATUS:5 and No AP until WIFI GOT IP. NextZXOS’s .http waits for WIFI GOT IP after a reset and then sends ATE0 again.
Bridge
--esp bridge listens on 127.0.0.1, port 11002 unless --esp-port says otherwise, and joins whatever connects there to the guest’s serial line. With a USB serial adapter and socat, the guest talks to a real ESP module:
bizmuth --machine next --esp bridge --esp-port 11002
socat TCP:localhost:11002 /dev/ttyUSB0,b115200,rawA port that cannot be opened is reported, and the run continues with nothing attached.
Faults
Overruns, framing errors, breaks, dropped bytes and a silent far end can be produced on demand with the ADP serial commands or the matching script functions; see ADP.