AME Hardware: Difference between revisions

From IoT with AME
Jump to navigation Jump to search
No edit summary
 
(One intermediate revision by the same user not shown)
Line 24: Line 24:
Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):
Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):


* Serial interface: O, 1 become Transmit Data (TXD), Receive Data (RDX)
* Serial interface: I/O pins 0, 1 become Transmit Data (TXD), Receive Data (RDX)
* External interrupts: 2, 3
* External interrupts: I/O pins 2, 3
* Serial Peripheral Interface (SPI): 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus. Slaves must be selected using a digital I/O pin, but there is no protocol overhead.
* Serial Peripheral Interface (SPI): I/O pins 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus with transfer in both directions at the same time. Slaves must be selected using a digital I/O pin, but there is no protocol overhead. Very efficient, but uses a few pins plus one pin for each device.
* Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol.
* Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): I/O pins A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol. More talkative, but uses only two pins for any amount of devices.
 
Standard-use of pins:
 
* 7: Logsury on/off (optional if you don't want to use the runtime-configuration option of Logsury)
* 8: ESP8266 reset (optional if you don't want to make use of the reset option of AC_ESP8266)
* 9: Status LED (optional if you don't want to use the LED-version of AC_EventFacility)


==ESP8266==
==ESP8266==

Latest revision as of 12:05, 26 June 2018

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).

The pins:

  • ACC: +5V (if you use the 5V variety of the Arduino, otherwise 3.3V)
  • RAW: This feeds the internal voltage regulator. You may apply a higher voltage then on the ACC pin, supposedly up to 12V, but I would not overdo it. In this case, +5V may be obtained on the ACC pin, but the small regulator can't supply much.
  • GND: Connect to GND of the ESP8266
  • RST: Reset
  • TXD: Transmit data (another name for I/O pin 0). Connect to RX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
  • RXD: Receive data (another name for I/O pin 1). Connect to TX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
  • 2-13: Digital I/O Pins. Pin 13 is connected to the internal LED (which does not hurt if you want to use the pin for your own purposes).
  • A0-A7: Analog I/O Pins (can be used for digital I/O as well)

Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):

  • Serial interface: I/O pins 0, 1 become Transmit Data (TXD), Receive Data (RDX)
  • External interrupts: I/O pins 2, 3
  • Serial Peripheral Interface (SPI): I/O pins 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus with transfer in both directions at the same time. Slaves must be selected using a digital I/O pin, but there is no protocol overhead. Very efficient, but uses a few pins plus one pin for each device.
  • Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): I/O pins A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol. More talkative, but uses only two pins for any amount of devices.

Standard-use of pins:

  • 7: Logsury on/off (optional if you don't want to use the runtime-configuration option of Logsury)
  • 8: ESP8266 reset (optional if you don't want to make use of the reset option of AC_ESP8266)
  • 9: Status LED (optional if you don't want to use the LED-version of AC_EventFacility)

ESP8266

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

The ESP8266 is IP- and WLAN-connectivity 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.

The pins:

  • Vcc: 3.3V (using a voltage converter if you use a 5V power supply). Really recommended to avoid strange behavior: Use a 100uF or larger electrolytic capacitor between Vcc and GND to buffer power spikes the ESP generates during operation (I'm using 1000uF).
  • GND: Connect to GND of the Arduino
  • RST: Reset. Tie to 3.3V (optional, but just to make sure OR connect to Arduino pin for allow for programmable hardware resets).
  • CH-PD: Chip enable. Tie to 3.3V (mandatory, otherwise the chip won't listen).
  • GPIO0: Digital I/O pin 0. Tie to 3.3V (optional, but just to make sure as this pin is used in conjunction with RST to program the ESP).
  • GPIO2: Digital I/O pin 2. You can use this pin for your own programs; otherwise just don't connect it.
  • TX: Transmit. Connect to RXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).
  • RX: Receive. Connect to TXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).

Regarding the level shifting and voltage conversion: I am using a small COTS board that does both (it's the larger blue board that the smaller black ESP8266-board is plugged into). That is not a requirement; I've been using separate level shifters and voltage converters in some projects. It just means more manual wiring and no cost savings.

ESP Troubles

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMNSHO as I spent many hours on dealing with this).

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" all I/O pins, to find out which number corresponds to which pin. After that the ESP did not interact with the programmer any more :-(.

The AME Stack