Hi, I am currently planning a garden irrigation controller, with Wi-Fi access. And I'm faced with a dilemma: Is it better to use some ARM + control via AT commands with an ESP8266/ESP-07 module ? Or using the ESP-12F as the main processor + extending it with some expander for additional GPIOs?...

Name: Irrigation controller: ARM + ESP8266/ESP-07 or ESP-12F + GPIO expander?
Uploaded: 2019-09-06T09:11:50+02:00
Description: Hi, I am currently planning a garden irrigation controller, with Wi-Fi access. And I'm faced with a dilemma: Is it better to use some ARM + control via AT commands with an ESP8266/ESP-07 module ? Or using the ESP-12F as the main processor + extending it with some expander for additional GPIOs?...

If you want to use ST then you have the option of using ESP 01, so nothing is wasted.

ESP32 - I've heard but I'm totally unfamiliar with it. How do you program it besides Arduino? That's if I add the argument that I assume this is not a hobby project and I will want to develop it? Is it worth leaning on ESP then?

The difficulty of programming in Arduino ESP is so much less as there are off-the-shelf products, e.g.: The screen could simply be a tablet/smartphone managing the device via WIFI and the WWW. Older devices tend to get dusty in drawers somewhere and are just waiting for such a chance.

. Normally, on foot, using esp-idf. Anyway, the RTOS for the 8266 is slowly being rewritten in esp-idf style. So, currently you program both ESPs the same way. There are only a few nuances due to hardware differences. And not all features have been rewritten for the 8266, e.g. the https server.

. It will be as long as the TFT has a high resolution. What resolution of the display? What communication interface?

3.2 inches, SPI or 8 bit depending on processor and amount of gpio. Resolution is 320 x 240 and I have tested on ESP and Stm32. Performance is sufficient for me on the plus side in stm32 that I can Use DMA

. Pushing over 150kB (that's what the buffer in the microcontroller should be) through SPI will take over 80ms assuming an SPI clock of 15MHz (which is what the controllers in the displays usually allow). DMA required, eventually RTOS sending piece by piece. Parallel mode in ESP is out, as it has no hardware interface. You can supposedly generate CS, WR by swiping a pin but then forget the benefit of DMA. In the case of STM32 parallel mode and . When you use SPI in the display then ESP will suffice as long as the SPI has DMA and enough RAM for a buffer. Other solutions can also work (no buffer, swiping pins) but expect effects similar to . Added after 8 [minutes]: As for the refresh, I don't have a video ready, I would have to record. With SPI, the screen refresh in 80ms seems fast (12FPS) but unfortunately you can see the screen drawing. To make the de-scratching unnoticeable it needs to be done in 30ms max. For 320x240 this requires a parallel interface but @Ba_rt-projects ver @niveasoft is able to get 20FPS on the Xmega: and in the video this and 50FPS is possible. Naturally you have to tacitly assume that @niveasoft has to overclock the SPI in the display to about 25MHz (about 70% - as if working not after 8h but after about 14 or the Fiat126p had to move at 170km/h - it would probably fall apart) and 50FPS is on a small part of the screen or by other tricks. The question is what trick to use for the whole screen cleaning operation when it is necessary? So if the device is to look professional STM32 (preferably with SFMC/FMC) + ESP-01, as in the Arduino way (as in the video above) or even worse (as below - ArduinoMega2560 + IL9486 at full power 0.08FPS) . then you have complete freedom, even on an ArduinoUNO you will do.

. As much as possible on ESP32 And even if you decide to use the 'hobby' Arduino HAL, it just happens to be 100% RTOS based on this platform, so it will be all the more fun to program .

I have a PV installation with a new SMA inverter. What is surprising - in an expensive and branded unit the display has been removed - there are only 3 LEDs. The rest of the information (very abundant) via the network only - mainly via WiFi of course. The device works both in AP mode and as a standard web server on the local network. It can also work in the cloud. The installer told me that the display was removed because it was the component that broke most often (inverters can even work outside in very variable weather conditions). I think this is a good direction. In general we have two types of users: 1. It's supposed to work and I don't care about anything - to them, LEDs are enough - power supply, correct operation, failure. If something is wrong, they call a professional, but with cloud or remote access, problems can be diagnosed remotely. More affluent people tend to think about watering their garden in an advanced way, and these are often among this group of users. 2) They like to know what and how (this applies to almost all electrode users )- but they don't mind rich information on a computer or smartphone instead of a display. I say rich because it's not just configuration, but also statistics, operation graphs, humidity sensor analysis, downloading weather information, water consumption analysis, etc. In the absence of a display, such an ESP12 should suffice. You can, of course, use an ESP32 especially if you are thinking about touch control or the need for analogue inputs (e.g. to determine valve failures).

Irrigation controller: ARM + ESP8266/ESP-07 or ESP-12F + GPIO expander?

RometFan;p 1641 12

Treść została przetłumaczona

Zobacz oryginalną wersję tematu

Report a violation of the law

Reply | New topic

#1 18153578 05 Sep 2019 22:43

RometFan;p RometFan;p

Level 26

» | Topic author

Post #1
18153578 05 Sep 2019 22:43

Hi,
I am currently planning a garden irrigation controller, with Wi-Fi access.
And I'm faced with a dilemma:
Is it better to use some ARM + control via AT commands with an ESP8266/ESP-07 module ?
Or using the ESP-12F as the main processor + extending it with some expander for additional GPIOs?

The ESP-12F WiFi module is a pretty good processor, and it seems to me that putting 2 processors into a device is a bit pointless.
On the other hand, writing quite an extensive program (wifi communication + watering zones + some kind of work schedule + control of valves + TFT display + reading from sensors) seems to me to be a pain in the Arduino IDE. Timers, no debugger, slow programming....

Using STM32 in LQFP-64 enclosure will raise the comfort of writing code, and solve the GPIO problem, but will raise the cost + ESP module will be wasted.

What is your opinion?

Druk 3D w 2026 - przegląd drukarek 3D do domu lub firmy [sponsorowane]
ADVERTISEMENT
#2 18153656 05 Sep 2019 23:32

jakubek56 jakubek56

Level 32

» | Helpful post? (0)

Post #2
18153656 05 Sep 2019 23:32

If you want to use ST then you have the option of using ESP 01, so nothing is wasted.
ADVERTISEMENT
#3 18153662 05 Sep 2019 23:35

tos18 tos18

Level 42

» | Helpful post? (0)

Post #3
18153662 05 Sep 2019 23:35

How about ESP32 ?
#4 18153698 06 Sep 2019 00:08

RometFan;p RometFan;p

Level 26

» | Topic author Helpful post? (0)

Post #4
18153698 06 Sep 2019 00:08

ESP32 - I've heard but I'm totally unfamiliar with it. How do you program it besides Arduino?

That's if I add the argument that I assume this is not a hobby project and I will want to develop it? Is it worth leaning on ESP then?
#5 18153705 06 Sep 2019 00:19

kaczakat kaczakat

Level 34

» | Helpful post? (0)

Post #5
18153705 06 Sep 2019 00:19

The difficulty of programming in Arduino ESP is so much less as there are off-the-shelf products, e.g.: https://github.com/n0bel/ESPrinkler2/tree/master/data. The screen could simply be a tablet/smartphone managing the device via WIFI and the WWW. Older devices tend to get dusty in drawers somewhere and are just waiting for such a chance.

Helpful post? Buy me a coffee.
ADVERTISEMENT
#6 18153814 06 Sep 2019 07:50

Nagus Nagus

Level 27

» | Helpful post? (0)

Post #6
18153814 06 Sep 2019 07:50

Quote:
ESP32 - I've heard but don't know total. How to program it apart from the Arduino?
.
Normally, "on foot", using esp-idf. Anyway, the RTOS for the 8266 is slowly being rewritten in esp-idf style.
So, currently you program both ESPs the same way. There are only a few nuances due to hardware differences. And not all features have been rewritten for the 8266, e.g. the https server.
#7 18153863 06 Sep 2019 08:35

Anonymous Anonymous

Level 1

» |

Post #7
18153863 06 Sep 2019 08:35

RometFan;p wrote:
On the other hand, writing a fairly elaborate program (wifi communication + watering zones + some kind of work schedule + valve control + TFT display + sensor reading) seems to me to be a pain in the Arduino IDE.
.
It will be as long as the TFT has a high resolution.
What resolution of the display?
What communication interface?
#8 18153888 06 Sep 2019 08:46

RometFan;p RometFan;p

Level 26

» | Topic author Helpful post? (0)

Post #8
18153888 06 Sep 2019 08:46

3.2 inches, SPI or 8 bit depending on processor and amount of gpio. Resolution is 320 x 240 and I have tested on ESP and Stm32. Performance is sufficient for me on the plus side in stm32 that I can Use DMA
#9 18153906 06 Sep 2019 09:11

Anonymous Anonymous

Level 1

» |

Post #9
18153906 06 Sep 2019 09:11

RometFan;p wrote:
Resolution 320 x 240.
.
Pushing over 150kB (that's what the buffer in the microcontroller should be) through SPI will take over 80ms assuming an SPI clock of 15MHz (which is what the controllers in the displays usually allow). DMA required, eventually RTOS sending piece by piece.
Parallel mode in ESP is out, as it has no hardware interface. You can supposedly generate CS, WR by "swiping a pin" but then forget the benefit of DMA. In the case of STM32 parallel mode and
jakubek56 wrote:
you have the possibility to use ESP 01
.
When you use SPI in the display then ESP will suffice as long as the SPI has DMA and enough RAM for a buffer.

Other solutions can also work (no buffer, swiping pins) but expect effects similar to

.

Added after 8 [minutes]:

As for the refresh, I don't have a video ready, I would have to record.
With SPI, the screen refresh in 80ms seems fast (12FPS) but unfortunately you can see the screen "drawing". To make the de-scratching unnoticeable it needs to be done in 30ms max. For 320x240 this requires a parallel interface but @Ba_rt-projects ver @niveasoft is able to get 20FPS on the Xmega: https://bart-projects-forum.cba.pl/viewtopic.php?f=9&t=5 and in the video this and 50FPS is possible. Naturally you have to tacitly assume that @niveasoft has to overclock the SPI in the display to about 25MHz (about 70% - as if working not after 8h but after about 14 or the Fiat126p had to move at 170km/h - it would probably fall apart) and 50FPS is on a small part of the screen or by other tricks. The question is what trick to use for the whole screen cleaning operation when it is necessary?

So if the device is to look professional STM32 (preferably with SFMC/FMC) + ESP-01, as in the "Arduino way" (as in the video above) or even worse (as below - ArduinoMega2560 + IL9486 at full power 0.08FPS)

.
then you have complete freedom, even on an ArduinoUNO you will do.
#10 18154397 06 Sep 2019 14:20

Anonymous Anonymous

Level 1

» |

Post #10
18154397 06 Sep 2019 14:20

RometFan;p wrote:
If I were to add the argument that I assume this is not a hobby project and I will want to develop it? Is it worth relying on ESP then?
.
As much as possible on ESP32 And even if you decide to use the 'hobby' Arduino HAL, it just happens to be 100% RTOS based on this platform, so it will be all the more fun to program .
#11 18154953 06 Sep 2019 20:14

krzbor krzbor

Level 29

» | Helpful post? (+1)

Post #11
18154953 06 Sep 2019 20:14

I have a PV installation with a new SMA inverter. What is surprising - in an expensive and branded unit the display has been removed - there are only 3 LEDs. The rest of the information (very abundant) via the network only - mainly via WiFi of course. The device works both in AP mode and as a standard web server on the local network. It can also work in the cloud. The installer told me that the display was removed because it was the component that broke most often (inverters can even work outside in very variable weather conditions). I think this is a good direction. In general we have two types of users:
1. It's supposed to work and I don't care about anything - to them, LEDs are enough - power supply, correct operation, failure. If something is wrong, they call a professional, but with cloud or remote access, problems can be diagnosed remotely. More affluent people tend to think about watering their garden in an advanced way, and these are often among this group of users.
2) They like to know what and how (this applies to almost all electrode users )- but they don't mind rich information on a computer or smartphone instead of a display. I say "rich" because it's not just configuration, but also statistics, operation graphs, humidity sensor analysis, downloading weather information, water consumption analysis, etc.

In the absence of a display, such an ESP12 should suffice. You can, of course, use an ESP32 especially if you are thinking about touch control or the need for analogue inputs (e.g. to determine valve failures).
ADVERTISEMENT
#12 18195038 30 Sep 2019 21:12

Udios Udios

Level 12

» | Helpful post? (0)

Post #12
18195038 30 Sep 2019 21:12

RometFan;p wrote:
Hey,
I am currently planning a garden irrigation controller, with Wi-Fi access.
.
Hello.
Could you write something more about what your system will have to do and what it will control?
My parents have a greenhouse on their allotment and the thought has also recently crossed my mind to get them some automation to control it. I was thinking of designing a controller for an ESP 32. It has a lot of inputs.
My assumption was that it would control three electric actuators for opening doors and windows - temperature-dependent opening and closing. Monitoring the position of the actuators. And it would control a valve for watering the plants. In addition, I wondered if the system would have some kind of GSM module to monitor temperature, humidity and if something unexpected happened. For example, an actuator would not open, we would run out of water. The plot of land is a long way from where we live.
#13 18198703 02 Oct 2019 21:54

RometFan;p RometFan;p

Level 26

» | Topic author Helpful post? (0)

Post #13
18198703 02 Oct 2019 21:54

Hi,
after reading my colleagues' posts I've started to wonder a bit whether to push for a display.

The general assumptions are that:
- Control of 4-8 watering sections,
- reading the outside temperature,
- rain sensor so as not to water when it rains,
- communication via WiFi (here possible control from the web/smartphone via a web page).

As to which specific functions it implements - download the manuals of several controllers available for sale. There you will find which functions they have and which are worth writing and which you will not necessarily need.

GSM module - I once considered such a solution in a project, but abandoned it because the validity of the card/charging discouraged me.

As for your needs:
You can also implement the actuators' steering on relays. Actuators with limit switches, reading the signal from the limit switches opens the relay, etc....
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Reply | New topic

Report a violation of the law

Topic summary

✨ The discussion revolves around the design of a garden irrigation controller with Wi-Fi capabilities, debating whether to use an ARM processor with an ESP8266/ESP-07 module or to utilize the ESP-12F as the main processor with a GPIO expander. The ESP-12F is noted for its processing power, while concerns about programming complexity in the Arduino IDE are raised. Alternatives like the ESP32 are suggested for their ease of programming and additional features. The conversation also touches on display requirements, communication interfaces, and the potential for remote monitoring and control of irrigation systems. Users express interest in functionalities such as temperature monitoring, rain sensors, and actuator control for automated gardening.
Generated by the language model.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
ESP8266 and ESP32
/
Irrigation controller: ARM + ESP8266/ESP-07 or ESP-12F + GPIO expander?

FAQ

TL;DR: For Wi‑Fi irrigation controllers, SPI at 15 MHz takes ~80 ms per 320×240 frame; "you can see the screen 'drawing'." Choose STM32+ESP‑01 for fast parallel LCDs and many GPIOs. [Elektroda, Anonymous, post #18153906]

Why it matters: This FAQ helps builders choose ESP8266, ESP32, or STM32+ESP‑01 and avoid display bottlenecks, GPIO limits, and tooling headaches.

Quick Facts

320×240 TFT over SPI moves ~150 kB; ~80 ms per full refresh at 15 MHz; <30 ms feels smooth. [Elektroda, Anonymous, post #18153906]
ESP8266/ESP32 can be developed with ESP‑IDF; 8266 lacks some features (e.g., HTTPS server). [Elektroda, Nagus, post #18153814]
"Arduino on ESP32 is 100% RTOS‑based," easing multitasking and growth beyond hobby use. [Elektroda, khoam, post #18154397]
Skip the TFT: manage via Wi‑Fi and a browser; ESPrinkler2 is a working reference design. [Elektroda, kaczakat, post #18153705]
Many vendors dropped LCDs for reliability; devices expose data via AP/local web server. [Elektroda, krzbor, post #18154953]

What’s the best MCU setup for a Wi‑Fi irrigation controller?

ESP32 is a strong single‑chip choice. Even with Arduino HAL, the platform is fully RTOS‑based. That enables clean task separation for networking, scheduling, and I/O. It suits projects that aim to grow beyond hobby scope. [Elektroda, khoam, post #18154397]

How do I program ESP32 without Arduino?

Use ESP‑IDF. It provides RTOS primitives, Wi‑Fi stacks, and drivers. ESP8266 now mirrors this style, but some features remain missing. Expert note: "currently you program both ESPs the same way." For HTTPS, target ESP32 as 8266 support lags. [Elektroda, Nagus, post #18153814]

Is an STM32 + ESP‑01 combo worth it?

Yes, when you need a fast parallel TFT and many GPIOs. STM32 with FMC plus DMA can refresh 320×240 without visible redraw. Pair ESP‑01 for Wi‑Fi transport. This yields a more professional display experience than SPI alone. [Elektroda, Anonymous, post #18153906]

Do I really need a TFT, or can my phone be the screen?

You can go screenless. Serve a web UI over Wi‑Fi and control everything from a phone or tablet. This reduces code and hardware complexity. ESPrinkler2 shows a complete, working approach for irrigation control and UI hosting. [Elektroda, kaczakat, post #18153705]

If I keep a 3.2" 320×240 TFT, will SPI be smooth enough?

Full‑screen SPI pushes ~150 kB; at 15 MHz it takes ~80 ms (~12 FPS). Users notice line‑by‑line drawing; "you can see the screen 'drawing'." To hide redraws (<30 ms), use a parallel interface with DMA or segment updates. [Elektroda, Anonymous, post #18153906]

Does ESP support true parallel TFT (8/16‑bit) with DMA?

Not with a dedicated hardware interface. "Parallel mode in ESP is out," so you end up bit‑banging control lines. That defeats DMA benefits. For clean, fast parallel LCDs, use STM32 with FMC and keep ESP as a Wi‑Fi coprocessor. [Elektroda, Anonymous, post #18153906]

How many zones and sensors should I plan for?

Design for 4–8 irrigation sections, an outdoor temperature sensor, and a rain sensor. Provide Wi‑Fi control via a web page for configuration and manual overrides. This covers typical residential needs with room to expand later. [Elektroda, RometFan;p, post #18198703]

Is adding GSM worth it for remote allotments?

Plan ongoing costs first. GSM needs an active SIM with top‑ups, which can undermine value. Many builders drop GSM and rely on Wi‑Fi plus remote access when available. Budget and site connectivity should drive this choice. [Elektroda, RometFan;p, post #18198703]

What’s a simple way to drive window/door actuators safely?

Use relays to power actuators with built‑in limit switches. Read limit switch signals to confirm end‑travel. Cut power when a limit triggers to prevent stalling. This approach simplifies control and adds basic fault awareness. [Elektroda, RometFan;p, post #18198703]

Wire actuator through relays; include fusing.
Sense both limit switches with GPIOs.
Stop drive when a limit is reached; log status. [Elektroda, RometFan;p, post #18198703]

Any open‑source firmware to jumpstart irrigation control?

Yes. ESPrinkler2 provides scheduling, Wi‑Fi configuration, and a browser UI for ESP. Use it as a learning base or adapt its patterns. A web‑managed design also removes the need for a dedicated physical display. [Elektroda, kaczakat, post #18153705]

Will STM32 improve dev comfort and GPIO versus ESP‑12F + expander?

Yes. An STM32 in LQFP‑64 improves toolchain, debugging, and GPIO headroom. It raises BOM cost but simplifies complex codebases with better peripherals. Choose it when development efficiency and I/O breadth matter most. [Elektroda, RometFan;p, post #18153578]

What about HTTPS or secure web server on ESP8266?

ESP8266’s stack is being aligned with ESP‑IDF, but some features lag. An HTTPS server is one example not fully ported. For secure serving, plan on ESP32 or use a proxy. [Elektroda, Nagus, post #18153814]

Which Wi‑Fi module pairs best with an STM32 main MCU?

Use ESP‑01. It gives Wi‑Fi connectivity without wasting a larger ESP module. Keep STM32 as the main controller and delegate networking to ESP‑01 over UART. [Elektroda, jakubek56, post #18153656]

Should I keep a display, or go headless for reliability?

Consider headless. A branded inverter removed its LCD because it failed most often. It now exposes rich data via Wi‑Fi AP and local web server, with optional cloud. This pattern fits irrigation well. [Elektroda, krzbor, post #18154953]

Generated by the language model.