[Solved] WiFiEsp.h Library Error with Wemos D1 Mini and Arduino Pro Mini Connection

sebekk95 wrote:

So it can't be done with this WiFiEsp.h library only I have to use AT commands?

.
You don't have to. If the communication between the Wemos and the Pro Mini is to take place over the UART, then even the Serial class functions are sufficient for this purpose. However, you already implement WiFi access from the wemos natively using the ESP8266WiFi library.

khoam wrote:

You do not need to. If the communication between the Wemos and the Pro Mini is to take place over the UART, then even the Serial class functions are sufficient for this purpose. On the other hand, you already implement WiFi access from the wemos natively using the ESP8266WiFi library.

.

I don't really understand this. From what I understand the ESP8266WiFi library only works if I have wemos selected as the board on the COM port. And I can't select both the Arduino and Wemos board at the same time in one project .

sebekk95 wrote:

And I can't select both an Arduino and a Wemos board at the same time in one project

.
Yes, because then you must have two independent projects, on the pro mini and on the wemos.

sebekk95 wrote:

From what I understand the ESP8266WiFi library

.
This is the library for the ESP8266, or wemos.
https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/readme.html

So how do you think I should solve this problem?

In my opinion, you should purchase a NodeMCU v3 board or something similar. You will be able to realise the whole project on one board. Ultimately also with multitasking capability, which is important when dealing with multiple sensors. Sticking to artefacts such as the Pro Mini really doesn't make sense.

If you want to use ESP as a standalone uC with a self-written program there is an article here: https://www.elektroda.pl/rtvforum/topic3338096.html.
After installing the core for the ESP8266, you have a new board with ESP to choose from in Arduino. You choose Wemos and in Arduino fashion start by tapping the digitalWrite, delay, digitalWrite blob. The same with messages on the UART Serial.begin and then Serial.println. You start the Arduino IDE a second time (not the second sketch window), open a new project, this time selecting UNO and tapping the same thing. In one instance of the program you operate on port e.g. COM1 of the UNO, in the other on port e.g. COM2 of the ESP. In this way, you can write to both uCs at the same time. The procedure is the same as for the UNO. Some libraries work in both uCs, some are dedicated, some are reworked for ESP, some work differently and you have to get used to it.
The Node MCU V3 has 9 pins (and sometimes less - if you want to put it to sleep) to use with the Arduino + 2 for UART and one ADC.

khoam wrote:

In my opinion you should purchase a NodeMCU v3 board or something similar. You will be able to realise the whole project on one board. Ultimately also with the possibility of multitasking, which is important in the case of handling many sensors. Sticking to artefacts such as the Pro Mini really doesn't make sense.

.

And will I be able to use the pins from the SPI i.e. S0,S1,S2,S3,SC,SK in the NodeMCU v3 as a normal GPIO e.g. for a ds18b20 sensor or RGB diode?

sebekk95 wrote:

And will I be able to use the pins from SPI i.e. S0,S1,S2,S3,SC,SK in NodeMCU v3 as a normal GPIO e.g. for ds18b20 sensor or RGB diode?

.
I think yes as long as you don't use SPI.
Here you have it explained for the different ESP8266 models: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

In my opinion you won't use these pins in Arduino, they are for embedded flash. The first test is to pick a NodeMCU target board and use those pins, compile. They're not defined at all in core Arduino, so probably nothing will come out at this stage. You can dig up in the documentation which IO pins these are and by the numbers use them. I haven't tried it on ESP8266, but on ESP32 it compiles, but after uploading it causes an immediate chip reset - I bought myself a Polish board a la UNO for ESP32 and my colleague brought out the SPI shared with flash on pins 11-13.

kaczakat wrote:

In my opinion you won't use these pins on the Arduino, they are for the embedded flash.

.
You can use these pins with a caveat about the CS pin (GPIO15), which should be connected via a 10k resistor to ground. This is all explained in the link I provided to post #38.

.

kaczakat wrote:

These are not defined at all in the Arduino core, so probably nothing will come out at this stage.

.
This is obviously not true. Even if these pins were not defined by the appropriate constants, direct GPIO numbering could be used.
.

khoam wrote:

This is obviously not true. Even if these pins were not defined by appropriate constants, direct GPIO numbering could be used.

.
This doesn't even compile for the NODE MCU with the ESP8266.
Pins 12-15 are within the 11 available on the ESP8266. This is the same number of available pins for Node MCU and WeMos.
.
Using SPI used for flash ends up with a hang (pins 6-11).
So that still leaves a total of 11 pins I've written about, including 2 for the UART, + 1 extra ADC, well and keeping an eye on those necessary for pull up/down operation/start up and wake up.

kaczakat wrote:

This doesn't even compile for NODE MCU with ESP8266.

.
No problem, for SS, MOSI, MISO or SCK .

Added after 10 [minutes]:

kaczakat wrote:

Using the SPI used for flash ends in a hang (pins 6-11).

.
It all depends on the flashing mode set (DIO, QIO or DOUT). In fact, if you only work with the Arduino IDE and select the NodeMCU or Wemos board, there is no way to change this mode.

Added after 4 [minutes]: .

kaczakat wrote:

So in total there are still 11 pins

.
Plus the added bonus of GPIO9 and GPIO10 for those not using the Arduino IDE .

OK, so we are getting closer to a common understanding that there are 11 available I/O pins though, both in Wemos and in Node MCU. I agree that in some flash usage modes, on some boards, two more pins can be added, but these are not the pins described on the NODE MCU board S0,S1,S2*,S3*,SC,SK. * - for good reason admittedly two of these are described as GPIO9 and GPIO10, but their use http://smarpl.com/content/esp8266-esp-201-module-freeing-gpio9-and-gpio10 is unlikely to happen on a NODE MCU with ESP12E, at least without the use of specialised equipment.
MOSI MISO AND SCK are the pins on the other side of the NodceMCU board.
.

kaczakat wrote:

OK, so we're getting close to a common understanding that there are 11 available I/O pins though

.
No, there are 13 I/O pins available on the NodeMCU v3. I ran a simple test (in the Arduino IDE) as follows. The lights blink merrily, without the use of specialised equipment .
.

kaczakat wrote:

but their use http://smarpl.com/content/esp8266-esp-201-module-freeing-gpio9-and-gpio10 is unlikely to happen

.
This article is about the ESP-201 module and is not related to the NodeMCU v3. I would rather advise against purchasing the ESP-201 module.

In the article about pins IO9 and 10 from the link the ESP-201 board was used because there was easy access to the flash, you could desolder it, remove the pads of pins IO9 and IO10, connect these flash pins to VCC and after defining the flash as double it is possible to use the released ESP8266 pins 9 and 10. In ESP12E additionally you have to remove the metal cover and fight in tighter circumstances. If you want to use the pins connected to the flash in the ESP-12E/F module you may damage the board, make it behave unpredictably. Maybe not always, maybe the pins used as output will work when it's not using flash (have you connected an oscilloscope to see what ESP is doing on those pins?). Do yourself an experiment (I don't recommend it to anyone ), now set pins 9 and 10 as inputs, connect to GND (simulating a pressed button) and do a reset. You have a lot of points then order yourself a new NodeMCU module from the electrode shop. But don't recommend others to do stupid things.

@sebekk95 .
The NodeMCU v3 module is currently the module with the ESP8266 that has the most I/O pins to use. If you feel that this may not be enough, then I would suggest using the ESP32 DevKit (image below). Whichever module you choose, this will be a better solution than the so-called 'hybrid' solution of combining the Pro Mini with the small ESP8266 module over the serial link. Less hassle for commissioning and testing.

.

kaczakat wrote:

But to others, don't recommend doing stupid things.

With such knowledge and manners, then I suggest that Dear Colleague confine his past juggling performances to the Arduino Poland forum. For my part, I will follow Dear Colleague's advice, which Dear Colleague posts in his footer in his posts from time to time, and will not continue any further discussion with Dear Colleague.

khoam wrote:

With such knowledge and manners, then I suggest that Dear Colleague confine his past juggling performances to the Arduino Poland forum. For my part, I will follow Dear Colleague's advice, which Dear Colleague puts in his footer in his posts from time to time, and will not continue any further discussion with Dear Colleague.

.
Why did you insist on the 9 pins of the ESP8266 NodeMCU. Even if he took this module apart and made it safe to use IO9 and IO10 there wouldn't be enough pins:
2 to the UART of the BT module
2 for DS18B20 and DHT
9 to the RGB LED
2 for the LCD on I2C (possibly more for another type of screen).
To me, that comes out to somehow 15 IOs here.
And for that you admit that IO9 and IO10 should not be used (which you yourself posted in the link of post #38)
.
I don't count.
After all, Sebek was just asking about those pins:

sebekk95 wrote:

And are the pins from SPI i.e. S0,S1,S2,S3,SC,SK...

- these are the derived pins connected to flash GPIO6-11
and you wrote back that

khoam wrote:

kaczakat wrote:

In my opinion you will not use these pins in the Arduino, they are for the embedded flash.

.
You can use these pins with a caveat about the CS pin (GPIO15), which should be connected via a 10k resistor to ground. This is all explained in the link I provided to post #38.

.

kaczakat wrote:

These are not defined at all in the Arduino core, so probably nothing will come out at this stage.

.
This is obviously not true. Even if these pins were not defined by the appropriate constants, direct GPIO numbering could be used.

Code: C / C++

Log in, to see the code

.
What does the above prove since these are not the S0,S1,S2,S3,SC,SK (GPIO6-11) pins?
Anyone can have a bad day or the simplest mistake, you can apologise and correct your statement. But it is better to insult people, no? Even if someone gets damaged by it later or simply the action is unpredictable.
And nowhere do I claim to be an authority on Arduino or ESP, I do something completely different on a daily basis, so yes - I am an amateur and I learn among other things here on the forum.

khoam wrote:

If you think this may not be enough, then I suggest using ESP32 DevKit (image below).

.
Addendum:
If you opt for ESP32 you will still be able to use Arduino HAL and the Arduino IDE. An additional benefit is that the Arduino HAL on ESP32 is based on FreeRTOS. If you plan to support multiple peripherals, using FreeRTOS with Arduino will make it easier to support them.

The problem has been solved