GPIO.input voltage levels vs edge detection

[tlfong01]

7. Here is uploader.lua. This will let you telnet to your esp8266 which is much cleaner that the serial port. You will have had to establish your wifi connection before this

I am a little bit confused.

Is it true that your FTDI USB to TTL UART serial cable is noisy therefore your LUA script uploading using ESPlorer is not reliable?

As I mentioned earlier, one TaoBao shop said that many people have noisy USB to TTL cable and one solution is to buy their cable with a big 1000uF cap on board.

I actually bought their cable but not using it, because it is using the 8 pin connector which is standard for ESP01 board, but not for my ESP12 board.

For my ESP12 board, my PL230x USB to TTL cable seems OK, but I am not too sure, because I am playing with very short LUA programs.

Actually most of the time I am using a plain USB cable, because my ESP12 board has CH340 USB to TTL converter chip on board. I guess the on board converter is very clean and does not have noticeable noise problem.

I don't understand what you are saying below. Are you using telnet/ftp instead of using ftdi cable to upload the script? Or are you testing WiFi uploading/downloading your 24VDC pump status data Rpi to/from ESP8266?

RE: GPIO.INPUT VOLTAGE LEVELS VS EDGE DETECTION Postby petermeigs » 2018-Oct-05 Fri 9:15 pm
Earlier, I have posted a script to let you telnet to the esp and that will help a lot but does not solve the upload issue.
If you find a proper ftp to be able to upload (and download) please post it here. That would be super useful.

[Brandon92]

I am a little bit confused.

Is it true that your FTDI USB to TTL UART serial cable is noisy therefore your LUA script uploading using ESPlorer is not reliable?

As I mentioned earlier, one TaoBao shop said that many people have noisy USB to TTL cable and one solution is to buy their cable with a big 1000uF cap on board.

This sounds more like a power problem them a noise problem. Because when you place that capacitor on the data line. You don't have the data any more. Or they are have a (cheap) cable that is not designed for this purpose. Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

[petermeigs]

I have had the best luck using a 6" cable (~15 cm for you metric guys) from a raspberry pi running debian and ESPlorer. I like this because I have used a usb-serial but need something to take ttl levels to 3.3v. For a RPI, you just need 4 wires to communicate with esp8266 huzzah and it can take 5v or 3.3v as the huzzah has a power regulator. The ADAFruit FTDI friend works pretty well too from windows, linux desktop, or even USB from RPI.
I'm not a big fan of long rs232 cables as it is just asking for trouble, but if you do that you'll probably want to run ttl levels the length of the cable. I recall that ttl rs232 runs -10v to +10v and this is specifically done for long cable runs. The serial connection that the esp8266 runs is 0v to 3.3v so a long cable here could be a huge problem. Thinking about the serial signal from the esp8266 if you are using a ttl to cmos converter (perhaps with a MAX3232 chip on it) I'm not sure where it would get the -10v to +10v from for responses from the esp8266. There is a lot I don't understand about the MAX3232 so being a lazy guy, I just avoid it.

With regard to:

I am a little bit confused.

Is it true that your FTDI USB to TTL UART serial cable is noisy therefore your LUA script uploading using ESPlorer is not reliable?

I don't think I had noise issues at all. I think what is going on is that the transmission from the PC or RPI, can overrun the serial processing of the ESP8266. Since there is no checksum, CRC or any error detection protocol built into the esp8266 serial port, the transmission needs to be 100% solid. That is why I liked the idea to have a minimum bootstrap-like communication using serial port and then use wifi (which does have error handling protocol) with telnet, or http: You do have to get enough software onto the esp8266 to implement that infrastructure.

[petermeigs]

I don't understand what you are saying below. Are you using telnet/ftp instead of using ftdi cable to upload the script? Or are you testing WiFi uploading/downloading your 24VDC pump status data Rpi to/from ESP8266?

For my 24vac status reading, I won't be using the esp8266 at all. I was just suggesting that to you as a cheap way to separate your i2c from your big computer without running long wires. Then you would have wifi to communicate with the esp8266.

Alternatively, you could just get a raspberry pi zero-w. It has wifi, is low power and is about USD$10.00. Or course, you still have to buy a suitable micro-SD card and that will more than double the cost. If the cost is not a show-stopper, you would be able to program it with more familiar tools. I still like event-driven callbacks in python as well as in nodemcu (and nodejs for that matter)

[tlfong01]

I don't think I had noise issues at all. I think what is going on is that the transmission from the PC or RPI, can overrun the serial processing of the ESP8266.

Quick and dirty reply on ESP8266 Upload Problem - Part 1

1. I forgot what exactly is 'overrun'. I understand UART has no clock, so at high speed for long string of characters, 'out of sync' would occur. This reminds me that the TaoBao ad on their high class USB to TTL cable says their board has a crystal which means their clock is very stable, and therefore not so easy to out of sync.

(USB to TTL cable with big cap and crystal) RE: GPIO.INPUT VOLTAGE LEVELS VS EDGE DETECTION tlfong01 2018-Sep-30 Sun 2:16 pm
https://www.raspberrypi.org/forums/view ... 5#p1371541

2. I googled randomly and read the following post about ESP8266 upload problem. I do't understand the details, because I don't have any upload problem at all.

Often failling upload to ESP8266 - 2015dec05
https://github.com/esp8266/Arduino/issues/1145

[tlfong01]

Quick and dirty reply on ESP8266 Upload Problem - Part 1

Quick and dirty reply on ESP8266 Upload Problem Part 2

I have not yet tried microPython, but I think their advice on flash is good.

1. Getting started with MicroPython on the ESP8266
https://docs.micropython.org/en/latest/ ... intro.html

1.4. Deploying the firmware - MicroPython 1.9.4

If you have a board that has a USB connector, a USB-serial convertor, and has the DTR and RTS pins wired in a special way then deploying the firmware should be easy as all steps can be done automatically. Boards that have such features include the Adafruit Feather HUZZAH and NodeMCU boards.

For best results it is recommended to first erase the entire flash of your device before putting on new MicroPython firmware.

Using esptool.py you can erase the flash with the command:

esptool.py --port /dev/ttyUSB0 erase_flash

And then deploy the new firmware using:

esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash --flash_size=detect 0 esp8266-20170108-v1.8.7.bin

1.7. Troubleshooting installation problems

If you experience problems during flashing or with running firmware immediately after it, here are troubleshooting recommendations:

Be aware of and try to exclude hardware problems.

There are 2 common problems: bad power source quality and worn-out/defective FlashROM.

Speaking of power source, not just raw amperage is important, but also low ripple and noise/EMI in general.

If you experience issues with self-made or wall-wart style power supply, try USB power from a computer.

Unearthed power supplies are also known to cause problems as they source of increased EMI (electromagnetic interference) - at the very least, and may lead to electrical devices breakdown.

So, you are advised to avoid using unearthed power connections when working with ESP8266 and other boards.

In regard to FlashROM hardware problems, there are independent (not related to MicroPython in any way) reports (e.g.) that on some ESP8266 modules, FlashROM can be programmed as little as 20 times before programming errors occur.

This is much less than 100,000 programming cycles cited for FlashROM chips of a type used with ESP8266 by reputable vendors, which points to either production rejects, or second-hand worn-out flash chips to be used on some (apparently cheap) modules/boards.

You may want to use your best judgement about source, price, documentation, warranty, post-sales support for the modules/boards you purchase.

The flashing instructions above use flashing speed of 460800 baud, which is good compromise between speed and stability. However, depending on your module/board, USB-UART convertor, cables, host OS, etc., the above baud rate may be too high and lead to errors. Try a more common 115200 baud rate instead in such cases.

If lower baud rate didn’t help, you may want to try older version of esptool.py, which had a different programming algorithm:

pip install esptool==1.0.1

This version doesn’t support --flash_size=detect option, so you will need to specify FlashROM size explicitly (in megabits). It also requires Python 2.7, so you may need to use pip2 instead of pip in the command above.

The --flash_size option in the commands above is mandatory. Omitting it will lead to a corrupted firmware.

To catch incorrect flash content (e.g. from a defective sector on a chip), add --verify switch to the commands above.

Additionally, you can check the firmware integrity from a MicroPython REPL prompt (assuming you were able to flash it and --verify option doesn’t report errors):

import esp

esp.check_fw()

If the last output value is True, the firmware is OK. Otherwise, it’s corrupted and need to be reflashed correctly.

If you experience any issues with another flashing application (not esptool.py), try esptool.py, it is a generally accepted flashing application in the ESP8266 community.

If you still experience problems with even flashing the firmware, please refer to esptool.py project page,
https://github.com/espressif/esptool for additional documentation and bug tracker where you can report problems.

If you are able to flash firmware, but --verify option or esp.check_fw() return errors even after multiple retries, you may have a defective FlashROM chip, as explained above.

[tlfong01]

This sounds more like a power problem them a noise problem.

Because when you place that capacitor on the data line. You don't have the data any more. Or they are have a (cheap) cable that is not designed for this purpose.

Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

ESP8266 Power Supply Problem

Yes, I read that ESP8266 power supply is often a cause of trouble. And ESP8266 itself is also generating noise, as described by Big Dan The Blogging Man:

ESP8266 Generated Noise on the Power Supply - Big Dan The Blogging Man 2015sep03
https://bigdanzblog.wordpress.com/2015/ ... er-supply/

... Putting a scope on the power supply, sure enough I was seeing short voltage sags. My 3.3V power supply would drop to close to 3.0 volts.

After lots of probing, I found the culprit was the ESP8266. If I held the reset pin high (with a 1000K pullup), no noise. As soon as the ESP8266 fires up, lots of noise.

I have followed the standards of placing caps on the ESP8266 VCC and the power regulator VCC. Made no difference. I proceeded to try about every combination of cap sizes and locations trying to solve the problem.

I decided to put the ESP8266 on its own dedicated LM3940 regulator. That helped a lot, but there was still some flicker.

After a lot more trial and error I discovered that simply tying the new 3.3V regulator’s GND into the GND bus wasn’t enough.

I actually need to place the ESP8266’s ground near the new regulator’s ground as well (though it is still tied to the common ground as well).

In reviewing the problem, having a larger regulator (more current) might have helped, but for reasons I won’t go into here, that would have been difficult. If you are having this problem, I suggest that first.

If that doesn’t resolve the problem, I suspect adding a dedicated regulator for the ESP8266 will work for most people. Any voltage drops caused by the ESP8266 are isolated to it.

If that still doesn’t help, then try connecting the regulator’s ground near to the ESP8266. I suspect I needed this additional step only because of my particular project, but maybe others will find they need it too.

As of this fix, the main power supply is clean and the LCD is flicker free.

Update 2018oct24hkt1637

Comparison of ESP8266 NodeMCU development boards - 28th September, 2015 3rd April, 2018 Marcel Stör 53 Comments
https://frightanic.com/iot/comparison-o ... nt-boards/
cc young says: 23rd September, 2016 at 10:22
On the LoLin “v3” board – IMPORTANT! The usb connector is only soldered by the pins. The legs are inadequately soldered, if at all. ..
Make sure to solder the four legs to stabilize the connector. Solder can be applied from back with a hotter fine tipped iron.
I spent hours of frustration, changing cables, using different software, baud rates, and cursing different parts of the universe, before I noticed that the USB connector was not secure.

[tlfong01]

1. I don't think I had noise issues at all. I think what is going on is that the transmission from the PC or RPI, can overrun the serial processing of the ESP8266.

2. Since there is no checksum, CRC or any error detection protocol built into the esp8266 serial port, the transmission needs to be 100% solid.

3. That is why I liked the idea to have a minimum bootstrap-like communication using serial port and then use wifi (which does have error handling protocol) with telnet, or http: You do have to get enough software onto the esp8266 to implement that infrastructure.

Sweet Dreams are made of Huzzah32 (with built-in USB to TTL converter)

I think all upload problems will disappear when Huzzah32 comes to town. But for now only Arduino IDE and no LUA!

Eurythmics - Sweet Dreams Are Made Of This - 252,421,092 views
https://www.youtube.com/watch?v=qeMFqkcPYcg


Adafruit HUZZAH32 – ESP32 Feather Board - £17.70
https://shop.pimoroni.com/products/adaf ... escription

Aww yeah, it's the Feather you have been waiting for!

The HUZZAH32 is the ESP32-based Feather, made with the official WROOM32 module . Adafruit packed everything you love about Feathers: built in USB-to-Serial converter, automatic bootloader reset, Lithium Ion/Polymer charger, and just about all of the GPIOs brought out so you can use it with any of our Feather Wings.

That module nestled in at the end of this Feather contains a dual-core ESP32 chip, 4 MB of SPI Flash, tuned antenna, and all the passives you need to take advantage of this powerful new processor. The ESP32 has both WiFi and Bluetooth Classic/LE support. That means it's perfect for just about any wireless or Internet-connected project.

Because it's part of our Feather eco-system, you can take advantage of the 50+ Wings that Adafruit have designed to add all sorts of cool accessories.

The ESP32 is a perfect upgrade from the ESP8266 that has been so popular. In comparison, the ESP32 has way more GPIO, plenty of analog inputs, two analog outputs, multiple extra peripherals (like a spare UART), two cores so you don't have to yield to the WiFi manager, much higher-speed processor, etc. etc! We think that as the ESP32 gets traction, we'll see more people move to this chip exclusively, as it is so full-featured.

Please note: The ESP32 is still targeted to developers. Not all of the peripherals are fully documented with example code, and there are some bugs still being found and fixed. Adafruit got all of their Featherwings working under Arduino IDE, so you can expect things like I2C and SPI and analog reads to work. But other elements are still under development. For that reason, we recommend this Feather for makers who have some experience with microcontroller programming, and not as a first dev board.

Here are specifications from Espressif about the ESP32:

240 MHz dual core Tensilica LX6 microcontroller with 600 DMIPS

Integrated 520 KB SRAM

Integrated 802.11b/g/n HT40 Wi-Fi transceiver, baseband, stack and LWIP

Integrated dual mode Bluetooth (classic and BLE)

4 MByte flash include in the WROOM32 module

On-board PCB antenna

Ultra-low noise analog amplifier

Hall sensor

10x capacitive touch interface

32 kHz crystal oscillator

3 x UARTs (only two are configured by default in the Feather Arduino IDE support, one UART is used for bootloading/debug)

3 x SPI (only one is configured by default in the Feather Arduino IDE support)

2 x I2C (only one is configured by default in the Feather Arduino IDE support)

12 x ADC input channels

2 x I2S Audio

2 x DAC

PWM/timer input/output available on every GPIO pin

OpenOCD debug interface with 32 kB TRAX buffer

SDIO master/slave 50 MHz

SD-card interface support

Comes fully assembled and tested, with a USB interface that lets you quickly use it with the Arduino IDE or the low-level ESP32 IDF. Adafruit also toss in some header so you can solder it in and plug into a solderless breadboard. Lipoly battery and USB cable not included (but we do have lots of options in the shop if you'd like!)

[tlfong01]

...
Then it sent event detection messages. I don't know how to tell ESP8266 not to bother detecting events. I need to read the manual again.

So my experiment of interfacing ESP8266's 3V3 UART Tx Rx signals seems OK. I am thinking what to do next, playing AT commands, or using Rpi/Wind10 LUA5.1.x to send and receive text data at the COM port.

Or should I go back to write my newbie blinky program first?

Newbie LUA Blinky Program Writing Notes - Part 1

I read that ESP8266 serial communication using Rx/Tx is not very reliable, and therefore should not be easy for newbies to troubleshoot. So I decided to start with the easy thing first - Blinky!

I googled around and found most tutorial on LUA blinky programs are almost identical to the one below. Perhaps they are just copying from one another. Anyway, I will first look at one such LUA program. I found the LUA program hard to understand I don't know what the hell is the tmr function() thing doing there!. I guess I need to google again.

LED Blinking using ESP8266 by LUA Tutorial - Robo India
https://roboindia.com/tutorials/esp8266 ... inking-lua

1. Introduction:

This tutorial explains how to use GIPO of ESP8266 using LUA framework.

1.1 Prerequisites: ...

2. Connections

Except basic connection of ESP8266 and FTDI you will need to connect one LED to GND through 1K resistance to one GPIO ( General Purpose Input Output ) pin of ESP8266. Here in this tutorial we are using GPIO13.

- Pin definition
local pin = 7 -- GPIO13
local status = gpio.LOW
local duration = 1000 -- 1 second duration for timer

-- Initialising pin
gpio.mode(pin, gpio.OUTPUT)
gpio.write(pin, status)

-- Create an interval
tmr.alarm(0, duration, 1, function ()
if status == gpio.LOW then
status = gpio.HIGH
else
status = gpio.LOW
end

gpio.write(pin, status)
end)

4. Explaining programme:

We are creating a timer of 1 second interval. Whatever is written in that timer that will be executed every second. We have written to make LED ON/OFF in that timer. Thus LED remains ON for 1 second and remains OFF of another one.

[tlfong01]

I googled around and found most tutorial on LUA blinky programs are almost identical to the one below. Perhaps they are just copying from one another. Anyway, I will first look at one such LUA program. I found the LUA program hard to understand I don't know what the hell is the tmr function() thing doing there!. I guess I need to google again.

Newbie LUA Blinky Program Writing Notes - Part 2

I googled some good references for writing the blinky program, as listed in the appendix below. The following blinky program by Electronic Wing is very good.

The program uses the function tmr.delay() to provide delay in microseconds. And the blinky program is listed below:

Lua Script for LED Blink

LEDpin = 4 -- Declare LED pin no.
delayuS = 500000 -- Set delay in microSecond. here 0.5 second

gpio.mode(LEDpin,gpio.OUTPUT)-- Set LED pin as GPIO output pin

while(1) -- Define infinite while loop
do
gpio.write(LEDpin,gpio.HIGH)-- Set LED pin HIGH i.e. LED ON
tmr.delay(delayuS) -- timer Delay
gpio.write(LEDpin,gpio.LOW)-- Set LED pin LOW i.e. LED OFF
tmr.delay(delayuS) -- timer Delay
end

Electronic Wings then introduces the more advanced timer alarm to do blinky. I need to google further to understand this timer alarm thing.

Appendix - References for writing the blinky program

Blinky - ElectronicWings
http://www.electronicwings.com/nodemcu/ ... plorer-ide

LUA　Code Guidelines
https://dev.minetest.net/Lua_code_style_guidelines

NodeMCU-DEVKIT-V1.0 ESP-12 core (4MBytes flash）
https://github.com/nodemcu/nodemcu-devkit

crelay
http://ondrej1024.github.io/crelay/

lua-periphery
https://github.com/vsergeev/lua-periphery

rpi-gpio-python
https://sourceforge.net/p/raspberry-gpi ... /cpuinfo.c

lua module for rpi
http://andre-simon.de/doku/rpi_gpio_lua ... io_lua.php

lua gpio rpi
https://www.domoticz.com/forum/viewtopic.php?t=17742

[tlfong01]

... Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

Long 30m RS232 Cable Testing Tool

Yes, so I have bought a USD4 sig gen to test the performance of 30m long RS232 cables.

Appendix - Square Wave Gen for testing ESP8266 serial communication

PWM pulse frequency duty cycle adjustable module square wave rectangular wave signal generator XY-LPWM US $4.00/US $6.89 piece
https://www.aliexpress.com/item/PWM-pul ... 58185.html

Module description: PWM output, you can set the frequency, duty cycle;

Frequency is divided into four ranges, automatic switching:

XXX (no decimal point): the smallest unit is 1Hz, the value range of 1Hz ~ 999Hz;

X.XX (decimal point in the hundred) the smallest unit is 0.01Khz, the range of 1.00Khz ~ 9.99Khz;

XX.X (decimal point in ten): the smallest unit is 0.1Khz; value range of 10.0KHz ~ 99.9KHz;

X.X.X (decimal point in ten and hundred): the smallest unit is 1Khz; value range 1KHz ~ 150KHz

Frequency display:

100 indicates PWM output 100Hz pulse;

1.01 indicates PWM output 1.01K pulse;

54.1 indicates that the PWM output has a pulse of 54.1 kHz;

1.2.4 indicates that the PWM output is 124 kHz pulse;

Duty cycle range: 0 ~ 100%; All set parameters, power down save.

Parameter settings

The module has four independent keys, used to set the frequency and duty cycle, support short press (increase or decrease a unit) and long press (fast increase or decrease), very simple, set the parameters automatically save, power failure Lost.

Module parameters:

Working voltage: 3.3 ~ 30V;

Frequency range: 1Hz ~ 150KHz;

Frequency accuracy: the accuracy in each range is about 2%;

Signal load capacity: the output current can be about 5 ~ 30mA;

Output amplitude: PWM amplitude equal to the supply voltage;

Ambient temperature: -20 ~ +70 Celsius

Scope of application:

Used as a square wave signal generator, generate square wave signal for experimental development and use;

Used to generate a square wave signal that controls the motor driver;

Generate adjustable pulse for MCU use;

[tlfong01]

... Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

Long 30m RS232 Cable Testing Tool
Yes, so I have bought a USD4 sig gen to test the performance of 30m long RS232 cables.
Appendix - Square Wave Gen for testing ESP8266 serial communication

Working voltage: 3.3 ~ 30V;
Frequency range: 1Hz ~ 150KHz;
Output amplitude: PWM amplitude equal to the supply voltage;
[/i][/color]

PWM Square Wave Signal Generator Testing Notes

I setup the sig gen and found it easy to do the setting. The very nice thing is that the frequency and duty cycle can be independently set.

I have been using the cheap NE555 based signal generator modules for years. The annoying thing about 555 is that I cannot independently set frequency and duty cycle, setting one parameter would affect the other, and so it takes perhaps a couple of minutes just to set one desired pair of parameter.

Now my new digital toy can be set in less than a minute. From now on I can use this handy tool to test my relays, and esp8266 serial transmission performance.

The time has come to kiss my fair 555 lady good bye.

Petula Clark - Kiss me goodbye - 1,763,554 views
https://www.youtube.com/watch?v=-wulPDIG9Zs

（555 Timer Module) RE: SWITCH ON/OFF 12V 7A Post by tlfong01 » 2018-Aug-20 Mon 4:19 pm
https://www.raspberrypi.org/forums/view ... 5#p1355194

[petermeigs]

1. I forgot what exactly is 'overrun'.

I had to write drivers once a long time ago for an ancient pc serial port. I had to deal with noisy lines due to long cable and overrun issues.

On a simple uart chip, you will get an interrupt telling you that a character is available to process. You have until the next character arrives to read that character and clear the interrupt. If you don't read a character in time, you lose it. You can easily figure how how long you have to process a character by calculating the time between characters given a baud rate.

More modern uarts have a buffer so that several characters can be processed in a single interrupt. However, if the character arrival rate is faster than the processing rate for a sustained period of time, the queuing resources available to stack up characters to be processed later will be exhausted because there is no "later"

In order words, in the average input rate is greater than the average processing rate, you are in trouble. In fact, in a system with highly random arrival rates for characters, you would be happy if you can process a 50% rate. This is a little surprising but consider if you are close to 100%. If you get behind, you never have time to catch up.

So for our esp8266, it has to receive the characters, buffer them and then do something with them. If you have echo turned on, theres that much more to do for every character.'

Anyway, async transmission is old but sometimes useful.

I hope this helps.

[tlfong01]

1. just suggesting that to you as a cheap way to separate your i2c from your big computer without running long wires. Then you would have wifi to communicate with the esp8266.

2. Alternatively, you could just get a raspberry pi zero-w. It has wifi, is low power and is about USD$10.00. Or course, you still have to buy a suitable micro-SD card and that will more than double the cost.

Wemos D1 Mini Pro vs RpiZW

Ah, one thing RpiZW cannot compete with ESP8266 is that ESP's Wifi range is much larger. The D1 Mini Pro now has 4MB (Errata - should read 16MB) on board and with external antenna connector is only USD5!

ESP8266 Range Test with and without External Antenna - 111,075 views
https://www.youtube.com/watch?v=KYLN9qH0C84

Appendix - Wemos D1MiniPro
https://www.aliexpress.com/item/1PCS-D1 ... b5e598a6-0

WEMOS D1 Mini Pro 16M Bytes External Antenna Connector NodeMCU Based ESP8266 ESP-8266EX CP2104 WIFI Development Board Micro USB

US $4.30 - 4.98 / piece Total Price: Depends on the product properties you select
US $2.97 to Hong Kong,china via AliExpress Standard Shipping
Estimated Delivery Time:15-25days
Sincere Company Store Open:6 years

What's new with D1 mini Pro
16M bytes(128M bit) Flash
External antenna connector
Built-in ceramic antenna
New CP2104 USB-TO-UART IC
Same size as D1 mini, but more light

[tlfong01]

1. I forgot what exactly is 'overrun'.

1. a simple uart chip, you will get an interrupt telling you that a character is available to process. You have until the next character arrives to read that character and clear the interrupt. If you don't read a character in time, you lose it.

2. modern uarts have a buffer so that several characters can be processed in a single interrupt. However, if the character arrival rate is faster than the processing rate for a sustained period of time, the queuing resources available to stack up characters to be processed later will be exhausted because there is no "later"

3. In order words, in the average input rate is greater than the average processing rate, you are in trouble. In fact, in a system with highly random arrival rates for characters, you would be happy if you can process a 50% rate. This is a little surprising but consider if you are close to 100%. If you get behind, you never have time to catch up.

4. So for our esp8266, it has to receive the characters, buffer them and then do something with them. If you have echo turned on, theres that much more to do for every character.'

ESP8266/NodeMcu Uploading Problem Part 1 (Overrun)

Many thanks for your UART chip explanation. Now I am not so confused. Let me summarize.

1. Old days UART chip only process one character at a time.

2. Nowadays UART chip has a buffer (I guess 1 to 64 characters long FIFO queue/stack). UART chip input characters as they come from Rx wire and queue them into the buffer. At the same time UART output characters from the buffer to the Tx wire. If characters come quicker than ESP can handle, then we have buffer/stack/queue overflow, or overrun.

3. I know we can control the character flow by the RTS (Request to Send), CTS (Clear To Send) control signals. But for ESP8266/NodeMcu boards, the RTS and CTS (actually RTS and DTR) signals are not used to control the character flow, but to control the ESP8266 hardware (chip reset and flash mode).

4. In other words, we cannot used RTS and CTS to control the flow.

5. But if we can lower the baud rate from say 115,200 to 9,600, or even 4,800, then ESP can have enough time to process the characters (moving them from UART chip to flash perhaps), then the upload software will be solved?

6. I noticed that the ESP8266 uploader, NodeMcu uploader, ESPlorer has a lowest rate of 9k6 or 115k2, so we cannot lower the data rate to solve the problem.

7. Of course we can write Arduino C++, NodeMcu LUA/C/C++ programs to do software or hardware RTS/CTS sort of control. But that would be very messy, and I am not capable or interested to learn how to do that.

I might need to think harder, or google further, ...

/ to continue, ...

[tlfong01]

This sounds more like a power problem them a noise problem. Because when you place that capacitor on the data line. You don't have the data any more. Or they are have a (cheap) cable that is not designed for this purpose. Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

ESP8266 Upload Problem Part 3 (Flash not properly/completely erased)

I am testing a couple more NodeMcu boards I just bought. I found one board problematic. Esptool chip_id, write_flash completed OK, but no reset message when tested with ESPlorer. I repeated chip_id, write_flash twice but still no luck. I remember once read about the advice of erasing flash first before writing. So I tried my luck and happily found it fixed the no reset problem.

esptool upload problem troubleshooting notes
https://github.com/espressif/esptool#troubleshooting

... Flashing problems can be fiddly to troubleshoot.

Erase Flash record
PS D:\work\rpi_forum\nodemcu\nodemcu_firmware> esptool erase_flash

esptool.py v2.5.1
Found 1 serial ports
Serial port COM10
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: b4:e6:2d:3b:d3:04
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 10.5s
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\nodemcu_firmware>

[tlfong01]

ESP8266 Upload Problem Part 3 (Flash not properly/completely erased)

ESP8266 Upload Problem Part 2 (Power Supply)

I wrote Part 2 but forgot to submit. So I copied the draft.

RE: GPIO.INPUT VOLTAGE LEVELS VS EDGE DETECTION Post by Brandon92 » 2018-Oct-05 Fri 11:43 pm
https://www.raspberrypi.org/forums/view ... 0#p1373753
This sounds more like a power problem them a noise problem. Because when you place that capacitor on the data line. You don't have the data any more. Or they are have a (cheap) cable that is not designed for this purpose. Or the tx / rx lines are to long, so that the signal are not received correctly at the other end.

esptool upload problem troubleshooting notes
https://github.com/espressif/esptool#troubleshooting

Insufficient Power

The 3.3V power supply for the ESP8266 and ESP32 has to supply large amounts of current (up to 70mA continuous, 200-300mA peak, slightly higher for ESP32). You also need sufficient capacitance on the power circuit to meet large spikes of power demand.

Insufficient Capacitance

If you're using a pre-made development board or module then the built-in power regulator & capacitors are usually good enough, provided the input power supply is adequate.

Try swapping in a 3.3V supply with a higher current rating, add capacitors to the power line, and/or shorten any 3.3V power wires.

The 3.3V output from FTDI FT232R chips/adapters or Arduino boards do not supply sufficient current to power an ESP8266 or ESP32 (it may seem to work sometimes, but it won't work reliably). Other USB TTL/serial adapters may also be marginal.


Appendix - esptool user guide
https://github.com/espressif/esptool

esptool.py A Python-based, open source, platform independent, utility to communicate with the ROM bootloader in Espressif ESP8266 & ESP32 chips.

Linux permission denied error message

In Linux, the current user may not have access to serial ports and a "Permission Denied" error will appear. On most Linux distributions, the solution is to add the user to the dialout group with a command like sudo usermod -a -G dialout <USERNAME>. Check your Linux distribution's documentation for more information.

Baud rate

The default esptool.py baud rate is 115200bps. Different rates may be set using -b 921600 (or another baudrate of your choice). A default baud rate can also be specified using the ESPTOOL_BAUD environment variable. This can speed up write_flash and read_flash operations.

The baud rate is limited to 115200 when esptool.py establishes the initial connection, higher speeds are only used for data transfers.

Most hardware configurations will work with -b 230400, some with -b 460800, -b 921600 and/or -b 1500000 or higher.

If you have connectivity problems then you can also set baud rates below 115200. You can also choose 74880, which is the usual baud rate used by the ESP8266 to output boot log information.

Troubleshooting

Flashing problems can be fiddly to troubleshoot. Try the suggestions here if you're having problems:

Bootloader won't respond

If you see errors like "Failed to connect" then your chip is probably not entering the bootloader properly:

Check you are passing the correct serial port on the command line.

Check you have permissions to access the serial port, and other software (such as modem-manager on Linux) is not trying to interact with it. A common pitfall is leaving a serial terminal accessing this port open in another window and forgetting about it.

Check the chip is receiving 3.3V from a stable power source (see Insufficient Power for more details.)

Check that all pins are connected as described in Entering the bootloader. Check the voltages at each pin with a multimeter, "high" pins should be close to 3.3V and "low" pins should be close to 0V.

If you have connected other devices to GPIO pins mentioned above section, try removing them and see if esptool.py starts working.

Try using a slower baud rate (-b 9600 is a very slow value that you can use to verify it's not a baud rate problem.)

write_flash operation fails part way through

If flashing fails with random errors part way through, retry with a lower baud rate.

Power stability problems may also cause this (see Insufficient Power.)

write_flash succeeds but program doesn't run

If esptool.py can flash your module with write_flash but your program doesn't run, try the following:

Wrong Flash Mode

Some devices only support the dio flash mode. Writing to flash with qio mode will succeed but the chip can't read the flash back to run - so nothing happens on boot. Try passing the -fm dio option to write_flash.

See the SPI Flash Modes wiki page for a full description of the flash modes and how to determine which ones are supported on your device.

Insufficient Power

The 3.3V power supply for the ESP8266 and ESP32 has to supply large amounts of current (up to 70mA continuous, 200-300mA peak, slightly higher for ESP32). You also need sufficient capacitance on the power circuit to meet large spikes of power demand.

Insufficient Capacitance

If you're using a pre-made development board or module then the built-in power regulator & capacitors are usually good enough, provided the input power supply is adequate.

This is not true for some very simple pin breakout modules - similar to this. These breakouts do not integrate enough capacitance to work reliably without additional components.. Surface mount OEM modules like ESP-WROOM02 and ESP-WROOM32 require an external bulk capacitor on the PCB to be reliable, consult the module datasheet.

Power Supply Rating

It is possible to have a power supply that supplies enough current for the serial bootloader stage with esptool.py, but not enough for normal firmware operation. You may see the 3.3V VCC voltage droop down if you measure it with a multimeter, but you can have problems even if this isn't happening.

Try swapping in a 3.3V supply with a higher current rating, add capacitors to the power line, and/or shorten any 3.3V power wires.

The 3.3V output from FTDI FT232R chips/adapters or Arduino boards do not supply sufficient current to power an ESP8266 or ESP32 (it may seem to work sometimes, but it won't work reliably). Other USB TTL/serial adapters may also be marginal.

Missing bootloader

Recent ESP8266 SDKs and the ESP32 esp-idf both use a small firmware bootloader program. The hardware bootloader in ROM loads this firmware bootloader from flash, and then it runs the program. On ESP8266. firmware bootloader image (with a filename like boot_v1.x.bin) has to be flashed at offset 0. If the firmware bootloader is missing then the ESP8266 will not boot. On ESP32, the bootloader image should be flashed by esp-idf at offset 0x1000.

Refer to SDK or esp-idf documentation for details regarding which binaries need to be flashed at which offsets.

SPI Pins which must be disconnected

Compared to the ROM bootloader that esptool.py talks to, a running firmware uses more of the chip's pins to access the SPI flash.

If you set "Quad I/O" mode (-fm qio, the esptool.py default) then GPIOs 7, 8, 9 & 10 are used for reading the SPI flash and must be otherwise disconnected.

If you set "Dual I/O" mode (-fm dio) then GPIOs 7 & 8 are used for reading the SPI flash and must be otherwise disconnected.

Try disconnecting anything from those pins (and/or swap to Dual I/O mode if you were previously using Quad I/O mode but want to attach things to GPIOs 9 & 10). Note that if GPIOs 9 & 10 are also connected to input pins on the SPI flash chip, they may still be unsuitable for use as general purpose I/O.

In addition to these pins, GPIOs 6 & 11 are also used to access the SPI flash (in all modes). However flashing will usually fail completely if these pins are connected incorrectly.

Early stage crash

Use a serial terminal program to view the boot log. (ESP8266 baud rate is 74880bps, ESP32 is 115200bps). See if the program is crashing during early startup or outputting an error message.

---

esptool chip_id sample run

PS D:\work\rpi_forum\nodemcu\ai_firmware> esptool chip_id
esptool.py v2.5.1
Found 1 serial ports
Serial port COM9
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 5c:cf:7f:78:15:ab
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x007815ab
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\ai_firmware>

---

NodeMcu Firmware upload sample record

PS D:\work\rpi_forum\nodemcu\nodemcu_firmware> esptool --port=COM10 write_flash -fm=dio -fs=4MB 0x00000 nodemcu-master-9-modules-2018-09-21-08-05-08-float.bin
esptool.py v2.5.1
Serial port COM10
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: b4:e6:2d:3b:d3:04
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0240
Compressed 589824 bytes to 358361...
Wrote 589824 bytes (358361 compressed) at 0x00000000 in 31.8 seconds (effective 148.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\nodemcu_firmware>

---

AI Thinker Firmware sample upload record

PS D:\work\rpi_forum\nodemcu\ai_thinker_firmware> esptool --port=COM10 write_flash -fm=dio -fs=4MB 0x00000 ai-thinker-0.9.5.2-115200.bin
esptool.py v2.5.1
Serial port COM10
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 84:f3:eb:7b:2d:55
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0240
Compressed 520192 bytes to 165300...
Wrote 520192 bytes (165300 compressed) at 0x00000000 in 14.7 seconds (effective 283.4 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\ai_thinker_firmware>

[tlfong01]

ESP8266 Upload Problem Part 3 (Flash not properly/completely erased)

ESP8266 Upload Problem Part 4 (BootLoader Problem)

Now I have tested a couple of ESP12 boards from 3 different vendors and quickly concluded that they have different versions of bootloaders, and that the firmware originally uploaded to the board is not AI Thinker's AT interpreter, nor NodeMcu's LUA interpreter, but something I don't know. So I need to upload my own firmware in order to start testing.

Now I am testing my newbie version of blinky program and found it working in my newbie built NodeMcu LUA firmware. But I don't understand the bootloader's message. So I took a record to study it and also for later reference and comparsion.

This reminds me my newbie experience with Arduino. I read the experts mentioning modifying the arduino bootloader to solve their problems. But I did not find any problems for newbies, so I never touched the arduino bootloader. Now this time for ESP12 is different. I need to know more about what the bootloader is doing, such as where the firmware is loaded, where my Lua program is loaded, why I need to erase flash before loading firmware etc.

Code: Select all

ESPlorer v0.2.0-rct by 4refrOnt test record tlfong01 2018oct09hkt1252

PORT OPEN 115200

Communication with MCU..Got answer! Communication with MCU established.
AutoDetect firmware...

Can't autodetect firmware, because proper answer not received (may be unknown firmware). 
Please, reset module or continue.

--- rubbish characters ---

dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100

_flash_used_end:40290000
fs.start:90000,max:36b000
_flash_used_end:40290000
fs.start:90000,max:36a000
_flash_used_end:40290000
fs.start:a0000,max:35b000
_flash_used_end:40290000
fs.start:a0000,max:35a000

mount res: 0, 0

Task task_lua started.

Flash sig not correct: 0 vs fafaaf50

nul mode, fpm auto sleep set:enalbe

NodeMCU custom build by frightanic.com
	branch: master
	commit: 3661b8d5eb5b42ed2d5ff51fa8e9628c17270973
	SSL: false
	modules: file,gpio,i2c,net,node,spi,tmr,uart,wifi

 build created on 2018-09-21 08:04

 powered by Lua 5.1.4 on SDK 2.2.1(6ab97e9)

lua: cannot open init.lua

> Heap size:42992.


lua: cannot open init.lua
> Heap size:42992.

 EVENT_DBG(wifi_event_monitor_handle_event_cb): was called (Event:7)

...

 EVENT_DBG(wifi_event_monitor_handle_event_cb): was called (Event:7)

---

-- *** Blinky2018oct0805 tlfong01 2018oct08hkt2305 *** --

-- *** Contents *** --

--   References
--   Configuration
--   Function definitions
--   Main

-- *** References ***

-- https://github.com/nodemcu/nodemcu-firmware (NodeMcu v2.2.1)
-- https://nodemcu.readthedocs.io/en/master/
-- https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_examples
-- https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_examples/mcp23008
-- http://www.electronicwings.com/nodemcu/nodemcu-gpio-with-esplorer-ide (with blinky example)
-- https://dev.minetest.net/Lua_code_style_guidelines

-- *** Configuration *** --

-- ** Print titles ***

programTitle = 'blinky2018oct0706'

-- ** Pin numbering **

pinNum = {}
pinNum[4] = 4

-- *** Functions *** --

-- ** Print Functions ***

function printProgramTitle(programTitle)
  local threeStars = '***'
  local fourNewLines = '\n\n\n\n'
  print(fourNewLines, threeStars, 'Begin program =', programTitle, threeStars, fourNewLines, fourNewLines)
  return
end

-- ** GPIO Functions ***

function setPinOutput(pinNum)
  gpio.mode(pinNum, gpio.OUTPUT)  
  return
end

function setPinHigh(pinNum)
  gpio.write(pinNum, gpio.HIGH)  
  return
end

-- *** Timer Functions ***
-- Reference - https://nodemcu.readthedocs.io/en/master/en/modules/tmr/
-- Notes 
--   tmr.delay() - busy loop timers
--   tmr.alarm() - call back timer, combining tmr.register() and tmr.start()


function setPinLow(pinNum)
  gpio.write(pinNum, gpio.LOW)  
  return
end

-- ** Toggle Pin Function ***

function togglePin(pinNum)
  lighton=0
  setPinOutput(pinNum)

  tmr.alarm(
    1,500,1,function()
    if lighton==0 then
        lighton=1
        setPinHigh(pinNum)
    else
        lighton=0
        setPinLow(pinNum)
    end
  end
  )
return
end

function togglePin01(pinNum)
  setPinOutput(pinNum)
  -- pinLevel = pinLevelDict['High']
  pinLevel = 'High'

  tmr.alarm(
    1,1000,1,function()

    if pinLevel == 'High' then
        pinLevel = 'Low'
        setPinLow(pinNum)
    else
        pinLevel = 'High'
        setPinHigh(pinNum)
    end

  end
  )
return
end

function togglePin02(pinNum)
  setPinOutput(pinNum)
  pinLevel = 'High'

  tmr.alarm(
    1,250,1,function()

    if pinLevel == 'High' then
        pinLevel = 'Low'
        setPinLow(pinNum)
    else
        pinLevel = 'High'
        setPinHigh(pinNum)
    end

  end
  )
return
end


function togglePin03(pinNum)
  setPinOutput(pinNum)
  pinLevel = 0

  tmr.alarm(
    1,1250,1,function()

    if pinLevel == 0 then
        pinLevel = 1
        setPinLow(pinNum)
    else
        pinLevel = 0
        setPinHigh(pinNum)
    end

  end
  )
return
end

function togglePin04(pinNum)
  setPinOutput(pinNum)
  High = 1
  Low  = 0
  pinLevel = High

  tmr.alarm(
    1,100,1,function()

    if pinLevel == High then
        pinLevel = not(pinLevel)
        setPinLow(pinNum)
    else
        pinLevel = High
        setPinHigh(pinNum)
    end

  end
  )
return
end

function main()
  printProgramTitle(programTitle)
  togglePin04(pinNum[4])
  return
end  

--- *** Main *** --

main()

[tlfong01]

ESP8266 Upload Problem Part 4 (BootLoader Problem)

ESP8266 Upload Problem Part 5 (NodeMcu exception)

/ to continue,....

[tlfong01]

The D1 Mini Pro now has 16MB on board

WeMos D1 Mini and D1 Mini Pro Testing Notes

Both D1 Mini and D1 Mini Pro are tested OK.

Appendix Flashing Record

*** WeMos D1 Mini Pro ***

PS C:\WINDOWS\system32> esptool chip_id
esptool.py v2.5.1
Found 1 serial ports
Serial port COM17
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:14:17:e9
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x001417e9
Hard resetting via RTS pin...
PS C:\WINDOWS\system32> cd d:\work\rpi_forum\nodemcu\nodemcu_firmware

PS D:\work\rpi_forum\nodemcu\ai_thinker_firmware> esptool erase_flash
esptool.py v2.5.1
Found 1 serial ports
Serial port COM17
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:14:17:e9
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 26.0s
Hard resetting via RTS pin...

PS D:\work\rpi_forum\nodemcu\ai_thinker_firmware> esptool --port=COM17 write_flash -fm=dio -fs=16MB 0x00000 ai-thinker-0.9.5.2-115200.bin
esptool.py v2.5.1
Serial port COM17
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:14:17:e9
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0290
Compressed 520192 bytes to 165300...
Wrote 520192 bytes (165300 compressed) at 0x00000000 in 14.6 seconds (effective 285.7 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\ai_thinker_firmware> cd ..

*** WeMos D1 Mini ***

PS D:\work\rpi_forum\nodemcu\nodemcu_firmware> esptool chip_id
esptool.py v2.5.1
Found 1 serial ports
Serial port COM13
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:20:cb:4b
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x0020cb4b
Hard resetting via RTS pin...

PS D:\work\rpi_forum\nodemcu\nodemcu_firmware> esptool erase_flash
esptool.py v2.5.1
Found 1 serial ports
Serial port COM13
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:20:cb:4b
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.6s
Hard resetting via RTS pin...

PS D:\work\rpi_forum\nodemcu\nodemcu_firmware> esptool --port=COM13 write_flash -fm=dio -fs=4MB 0x00000 nodemcu-master-9-modules-2018-09-21-08-05-08-float.bin
esptool.py v2.5.1
Serial port COM13
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: ec:fa:bc:20:cb:4b
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0240
Compressed 589824 bytes to 358361...
Wrote 589824 bytes (358361 compressed) at 0x00000000 in 31.3 seconds (effective 150.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
PS D:\work\rpi_forum\nodemcu\nodemcu_firmware>

[tlfong01]

Some esp8266 tips:
4. Here is what i use for an init.lua. It lets force a startup baud rate if I uncomment one of the setup lines. Also, it is minimalistic and defers the "real" code to be run elsewhere.

Code: Select all

-- uart.setup(0, 115200, 8, 0, 1, 1)
-- uart.setup(0, 57600, 8, 0, 1, 1)
print("running init.lua")
print("0: " .. uart.getconfig(0))
print("1: " .. uart.getconfig(1))
runfileList = { 
    "uploader.lua",
    "myserver.lua",
    "testserver.lua"
}

function ls()
  for k,v in pairs(file.list()) do
    print("name:" .. k .. ", size: " ..v.. ".")
  end
end

for i, runfile in ipairs(runfileList) do
  if file.exists(runfile) then
    print(i .. " Runfile " .. runfile .. " exists")
    dofile(runfile)
  end
end

5. Here is myserver.lua, ...

nodeMCU init.lua

Many thanks for your ESP8266 tips and code. I have been playing esp8266 for many days and now understand more of what you are saying.

I am moving very slowly, so it is only today that I begin to study what is the init.lua. I still have not completed my lua blinky program. I remember when I started learning with Arduino C++ and Rpi Python, it took me only less than one afternoon to blink the led, using system timer functions such as timer.sleep etc. But for nodeMCU, the the learning curve for tmr is very steep, for newbies with little experience in interrupt/callback, event driven programming etc. Luckily NodeMCU's programming/reference guide is helpful.

All these years playing with Arduino and Rpi, I only played with toy robot car related things, like toy servos, motor, ultrasonic sensor etc. I never played with WiFi server, so I think I will only start esp8266 WiFi things perhaps at least one month from now.

[petermeigs]

I thought I would share my progress with my 16-channel device to read the which of 24vac lines are on. I only have one column of 4 A3700's wired and even then not 100%.
You can see where I'll put the mcp23017. Thank you, forum buddies, for the suggestion to use this chip.

You see a mini-usb connector for power and I'll use a LD1117 to drop a 5vdc power supply (I have many of these left over from old phones and other devices) to 3.3v. I expect that the 800ma mentioned in the datasheet for output will be plenty and I don't risk my rpi's 3.3 volt max. I see that a LM3940 has been mentioned in this forum. This application note http://41j.com/blog/wp-content/uploads/ ... onNote.pdf lead me to use the LD1117 but if someone has a good reason to choose one over the other, I'd love to know.

The green screw blocks will connect with 16 valve solenoids and there will be two common screw blocks. I have not tested with actual solenoids yet so I'm a little worried about the effect of the coil when the power is shut off to the solenoids by the sprinkler controller. I'm hoping that since it is 24vac, it will not cause the issues a dc coil would.

In case there are design issues, I'm only soldering in cheap parts, and not all of them. I'll only wire up enough to do some tests with a rpi located near the rachio controller but far from my workstation. I'll use my laptop to ssh over to the rpi.

There will be a 5 pin terminal strip for GND, INT A, INT B, SCK, and SDA from the MCP23017. My board will have its own power as mentioned above.

I'm learning a lot about board layout as I solder these parts in. At first, I see I am not being economical enough with the holes I'm using for parts. I'm learning how to make these all take less space.

Any comments or concerns would be welcomed.

[tlfong01]

In case there are design issues, I'm only soldering in cheap parts, and not all of them. I'll only wire up enough to do some tests with a rpi located near the rachio controller but far from my workstation. I'll use my laptop to ssh over to the rpi.
There will be a 5 pin terminal strip for GND, INT A, INT B, SCK, and SDA from the MCP23017. My board will have its own power as mentioned above.
I'm learning a lot about board layout as I solder these parts in. At first, I see I am not being economical enough with the holes I'm using for parts. I'm learning how to make these all take less space.

Prototyping Board for MCP23x17

I think prototyping board wiring is a matter of personal taste.

When I first tried MCP23s17, a couple of years back, I used a small board with unconnected through holes, but the the wiring of the back side is very messy and difficult to troubleshoot.

Now I felt very tired of doing boring point to point soldering, I became lazy and use modules instead of chips. Also I use 5 through hole strip or 3 hole strip boards, to save some point to point soldering. Now it is vice versa, front side messy, bottom side clean. I use duPoint female to female wires to do almost all the point to point connections, so hardware wiring swap/troubleshooting is less painful and 10 times faster.

Update 2018oct11hkt0955

Appendix - MCP23017 and 3V3 PSU modules

Serial Interface Module IIC I2C MCP23017 SPI MCP23S17 Bidirectional 16-Bit I/O Expander Pins 10Mhz Serial Interface Module US $1.46
https://www.aliexpress.com/item/Serial- ... 61080.html

2x Ultra Small mini DC 3.7V 4.2V 4.5V 5V to 3.3V Step Down Buck Regulator LDO Module repl AMS1117 for 18650 ESP8266 breadboard US $2.19
https://www.aliexpress.com/item/2x-Ultr ... autifyAB=0


Update 2018oct11hkt2230

The mini 3V3 voltage regulator I have been using has 4 caps, 1 resistor, and 1 diode. I forgot what the back biased diode is for, perhaps for accidentally wrong polarity input. The spec says minimum input is 4.2V, not sure if it means not OK for 3.7V 18650 battery.

5pcs 5V To 3.3V DC-DC Step Down Power Supply Buck Module AMS1117 800MA Automatic Adjustable Boost Board Start Limit Voltage
https://www.aliexpress.com/item/5PCS-5V ... utifyAB=0

[petermeigs]

Thanks for a good tip on the type of boards available. I, too, have become tired of a lot of point to point soldering. I'll look for these boards for my next project.

[tlfong01]

I googled around and found most tutorial on LUA blinky programs are almost identical to the one below. Perhaps they are just copying from one another.
Electronic Wings then introduces the more advanced timer alarm to do blinky. I need to google further to understand this timer alarm thing.

Engineering Garage Blinky Program

Engineering Garage's ESP8266 projects are good for newbies like me.

Getting Started with the ESPlorer IDE | EngineersGarage
https://www.engineersgarage.com/tutoria ... plorer-ide

ESP8266 WIFI HOTSPOT
https://www.engineersgarage.com/tutoria ... fi-hotspot

HOME AUTOMATION USING ESP8266
https://www.engineersgarage.com/contrib ... ng-esp8266

SENDING TEXT MESSAGE USING ESP8266
https://www.engineersgarage.com/contrib ... ng-esp8266

CONNECTION BETWEEN TWO ESP8266
https://www.engineersgarage.com/tutoria ... wo-esp8266