[WiFi] added support for ESP32 architecture and XIAO ESP32C3 board

[jnsbyr]

features:

• support for ESP32 architecture with WiFi interface (WiFiStream, Firmata.h, StandardFirmataWiFi)
• support for Seed Studio XIAO ESP32C3 board (Boards.h)
• support for Firmata applications without Servo.h (Boards.h, StandardFirmataWiFi)

notes:

• new library version should be fully backward compatible with existing Firmata applications and previous architectures and boards (not tested)
• new library requires code changes in existing Firmata applications when used with ESP32 architecture, see modifications of example StandardFirmataWiFi:
  • The occurrences of the constants INPUT and OUTPUT have to be replaced with PIN_MODE_INPUT/PIN_MODE_OUTPUT when used in Firmata context, as the ESP32 SDK does not use the same constant values as e.g. the Atmel SDK. This fixes a long standing inconsistency that can be found in (all?) Firmata examples, probable due to historic reasons.
  • Servo.h will not be included, because it is not provided by ESP32 SDK. A skeleton definitions had to be added to Boards.h to allow building StandardFirmataWiFi.
  • Method detachServo() had to be modified to support MAX_SERVOS=0.
  • Introduced new define DEFAULT_ANALOG_RESOLUTION, as the ESP32 SDK defaults to 12 bits.
  • Only build diagnostic code in method printWifiStatus() if SERIAL_DEBUG is defined to avoid compiler warning.
• PWM support not yet implemented, as the ESP32 SDK does not support analogWrite(). A possible solution could be a set of preprocessor defines for pinMode() and analogWrite(). Give a thumbs up for me to continue or suggest alternative approach.

[zfields]

I appreciate the hard work. It would be WAY better if you would break this down into multiple PRs (e.g. one for the addition of the Seed Studio XIAO ESP32C3, another to add Wi-Fi support, and yet another to add servo support for ESP32).

It will be MUCH easier to review, understand, rework and merge.

[jnsbyr]

Breaking down this PR does not seem conclusive for me. It may look like a mulit-feature commit, but it is simply not possible to add the ESP32 architecture and the XIAO board without making all these changes at the same time. The example will simply not build for the new board.

If breaking down is a requirement to continue I suggest 3 parts:

• doing without Servo.h (need recommendation how to implement, see comment above)
• fixing usage of INPUT and OUTPUT
• adding ESP32 / XIAO ESP32C3

[pgrawehr]

@jnsbyr Are you aware that ConfigurableFirmata already has all of this, including PWM? The only thing that might be missing is the XIAO board definitions, but that's the easiest part here.

[jnsbyr]

@pgrawehr

Are you aware that ConfigurableFirmata already has all of this, including PWM? The only thing that might be missing is the XIAO board definitions, but that's the easiest part here.

Thanks for the info. I did not look, but ConfigurableFirmata was always a little more progressive, so no surprise here.

My history with this PR is quite simple. I have a working project for an ESP8266 board, but I needed an external antenna and I had an unused XIAO ESP32C3 in my box. Initially I thought adding the board definition should be all it needs. Took a few hours more than expected, but once I started there was no reason for me to look for alternatives ;-)

[jnsbyr]

also:

• renamed DEFAULT_ANALOG_RESOLUTION to DEFAULT_ADC_RESOLUTION to make it compatible to the solution for ConfigurableFirmata from @pgrawehr
• added another ESP32 board: W32-ETH01 (to be able to continue developing and testing)

todo:

• Find a solution for the ESP32 PWM implementation (currently disabled): The solution in ConfigurableFirmata is using the modular design to provide an implementation that is specific for the ESP32 SDK. This approach cannot be applied directly to StandardFirmata. My suggestion: define macros in Boards.h h for the relevant functions (init, write), either with the necessary code directly in Boards.h or in separate header file like utility/PwmImplementation.h.

[jnsbyr]

Did another code review and several tests, see latest 2 commits.

[jnsbyr]

Tried to define a generic board for the chip ESP32-C3 as fallback, as there are so may board variants, but it seems to me that the Arduino build system does not have a chip specific define. ARDUINO=10819 and ARDUINO_ARCH_ESP32 and ESP32 are more or less equivalent, and most of the remaining defines refer to a specific board.

It does not make sense to define a generic board for the ESP32 using absolute pin values. E.g. the ESP32-C3 has 22 GPIOs and the ESP32-S3 has 47 GPIOs.

Best option I see is to use the common constants from variants/../pins_arduino.h (e.g. NUM_DIGITAL_PINS) and to leave some slack.

[jnsbyr]

• made WiFiStream::status const mapping explicit
• synced example code
• protected SPI flash pins in generic ESP32 board definition

Notes:

A) Examples

With the synced examples it should be possible to use StandardFirmata and StandardFirmataPlus directly with the ESP32. StandardFirmataBLE needs additional work, but I do not have the setup to provide it. StandardFirmataEthernet will probably work with the Ethernet modules that are already supported, but for the Ethernet chip on the WT32-ETH01 additional changes are needed.

There are 7 other examples not staring with "Standard..." that have not been changed so far.

B) Generic ESP32 board

Defining a generic board for the ESP32 like ConfigurableFirmata does makes sense as there are too many ESP32 board variants around to add and maintain separately.

On the other hand the generic definition in ConfigurableFirmata 3.2.0 does not take into account that there is a difference in pin count and pin function between ESP32(S1), ESP32S2/3 and ESP32C3. This is something that should be revised in ConfigurableFirmata.

C) Digital pins default to output mode

Additionally any board can have manufacturer or user specific mods. This can be problematic, as StandardFirmata examples forces all non-analog digital pins to output mode in systemResetCallback(), while the board may require an input only configuration for the same pin to avoid damage. Defining board specific exceptions in ignorePins() is error prone and hard to maintain. A CPU typically configures input mode on all pins on reset so there is no good reason for Firmata to do differently. This is the first thing I change when starting a new Firmata projects to keep my hardware healthy. This should be considered as a separate change request.