[Grbl_Esp32 PR#649] Pin class – alpha version

I’m not going to lie, this is a massive change, and most of it has NOT been tested on an ESP32 yet. Custom code has not been checked either for pin usage.

Current state:

Before installing this, know that this PR will add a MASSIVE number of settings: one for each pin used in the code. In total, it will be roughly a hundred settings that will be registered in the Settings class. We really should hide pins from users if they are irrelevant for them.

Also, since it is not tested on real hardware yet, things might just blow up in your face or not work at all. I really would not recommend running this on a real CNC machine before testing individual components.

That being said, I suspect most of the code to either actually work, or crash the esp32 with an error almost immediately.

What this code does:

In short, this code adds configurable, extensible, verifiable pins.
– Configurable here means that pins can be configured with a simple setting string. These strings follow the pattern “[type].[number]:[flags]”. Type can be GPIO, I2S or whatever we define. Number is the pin number. And [flags] are the flags that are relevant for the pin, such as external pullup resistor, pull-down, active high, active low, etc.
– Extensible means that new types of pins can be defined in the future. I2S already uses this. Non-native (non-GPIO) pins claim a slot, and all digitalWrite / digitalRead / setMode will be transparantly forwarded to the right calls.
– Verifiable means that pins can be verified before they are used. For example, not all pins support DAC or OUTPUT. When a pin mode is set, the pin capabilities are verified, and the appropriate action is taken.

This also means that there will be no more need for invert masks (active low/high) in the future, because this is handled by the pin class, and can be configured.

Changes:

The changes have been split into 3 separate commits:
1. Adding the pin class itself and the basic pin infrastructure.
2. Making everything compile with the pin settings.
3. Adding automatic unit tests for pins. These can be run using gtest on x64 (native), or on an esp32 by using pio test -e test. All unit tests are currently green, and cover the majority of the pin class code.

The test infrastructure is just a few files, and is quite isolated on disk and can safely be ignored for a code review. It is only compiled when doing automatic unit testing (and if it contains an error, the test will just go red in the worst case). For a code review of pin class, I can recommend just looking at the first 2 commits. The MD file explains how to use the tests. I chose to add it to this PR, because (A) it can make reviewing a lot easier, just by looking at what is tested and how, and (B) because the pin test code really belongs to this PR.

How the pin tests work:

Tests work on two separate levels:

– ESP32 tests require the user to put a wire between pin 16 and 17. The unit tests are then compiled as Unity tests, and can be run by PlatformIO. Currently, only GPIO/Undefined pins and error pins are properly tested.
– Native x64 tests use the Google Test Framework. A virtual circuit is used that acts the same as the wire between 16 and 17. The unit tests are then compiled as Google Tests’s, and can be ran directly from VStudio. (VSCode has a GTest plugin and should support this as well, but isn’t tested yet!). The small part of the Arduino library that’s used, is simulated in code. Native tests are very fast, easy to debug and easy to check for leaks and test coverage.

Both types of tests generate stack traces if something goes wrong. This stack trace is currently disabled in release mode (non-test mode), in which case an extremely light-weight version of Assert is used.

Shelved, but mostly implemented:

I have more code related to pins already implemented, but shelved for the moment, in an attempt to keep this already-big-change a bit smaller:

– UART.
– PWM. Note that Pin Detail classes already has the required PWM stubs; this has to do with that code.