AME Hardware

The AME Stack

AME Stack (Hardware)

Voltage controller (left), Arduino (top right), and ESP8266 (bottom right)

Arduino

The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory for data (EPROM, non-volatile, runtime-programmable), counters, timers, I/O pins, and various interfaces (shared with the I/O pins; interrupts, serial, I2C, SPI). Different models offer different amounts of assets.

Cheap versions can be ordered from Chinese suppliers for 2.50€ a piece. I'm using them all the time, and they just work fine (didn't have a single dud in 20+ Arduinos).

ESP8266

Work in progress, stand by. Some information may be plain wrong, so... Last edit 19.06.2018.

The ESP8266 is IP and WLAN on a chip - SSL, TCP, UDP, WLAN, as a client or even as an access point (limited to 4 connections).

The chip supports a number of modes that exclude each other:

• Single/ multiple connection. Determines if only a single connection can be active at the same time, or up to four connections. The mode can only be changed if there currently is no connection. For SSL only single connection mode is supported (I guess SSL is too demanding for multiple connections). Multiple connection mode is required for server mode. Why would you limit yourself to a single connection? I don't know, but I use single connection mode because I need only one connection (to the MQTT broker), and sending out commands and parsing replies is more complex in multiple connection mode.
• IP client/ server mode. Determines if the chips opens connections as a client or if it accepts incoming connections as a server. The latter requires multiple connection mode.
• WLAN station/ AP mode. Determines if the chip acts as a client that logs into an existing WLAN or if the chip acts as a WLAN access points which other clients can connect to.

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMHO!). With "misbehave" I mean:

• Simply not reacting as expected (replying to a command in unexpected ways)
• Not be able to establish a WLAN or TCP connection
• Being stuck in some internal odd state that produces gobs of output
• Random reboots

These problems can all be addressed though. Sometimes a software rest helps (a command sent via the serial interface). Sometime a hardware reset is required. On rarer occasions the power needs to be cycled. My software stack uses software and hardware resets. In order to perform hardware resets I connect an Arduino I/O pin to the ESP reset pin (the library supports this). It would be easy to extend that scheme to cycling the power by using another I/O pin, and a transistor that switches the chip off and on again.

The ESP is its own computer on a chip, just like the Arduino. And it can be programmed by you, just like an Arduino. For why I don't use it instead of an Arduino, please see the next section.

Why not just an ESP8266?

Good question! Less hardware, more memory, direct function calls instead of serial communications all sound good. But, the Arduino has more I/O pins. I found programming the ESP is slow, and the ESP is less forgiving when it is handled the wrong way, be it hardware or even software. I fried an ESP by just trying to blink on all I/O pins, to find out which number corresponds to which pin. After the ESP did not interact with the programmer any more.

The AME Stack