Add Gravitech Cucumber R board definition (updated)

[cotdp]

This PR replaces my earlier one from August, #3349

Adding the board definition for Gravitech Cucumber R ESP32-S2 board (https://www.gravitech.us/curesdebo.html).

[tannewt]

board.h has moved. I think you'll need to add a board_deinit as well.

[tannewt]

Suggested change

	#include "boards/board.h"
	#include "supervisor/board.h"

[skieast]

I had requested this PID for the Cucumber RIS variant. Its basically the same except for added onboard sensors (All I2C connected).
Does this matter as I think the code for all these will be the same? The module used is the WROVER one.

The M variants use the WROOM moulde, requiring a differing sdkconfig. (No PSRAM)

[tannewt]

I'd do different boards for WROOM vs WROVER and sensors vs no sensors. The saola is an example of the first and the feather nrf regular vs sense are of the second. I wouldn't do separate versions for the antenna.

[skieast]

I'd do different boards for WROOM vs WROVER and sensors vs no sensors. The saola is an example of the first and the feather nrf regular vs sense are of the second. I wouldn't do separate versions for the antenna.

Thanks, what I thought as well. In that case I'll ask for some more PIDs from espressif for the variants.

[skieast]

I have received new PIDs from Espressif for the various cucumber variants.

These should be used for the non-sensor R variants (R and RI)
0x80A0 | GRAVITECH CUCUMBER R ESP32S2 - Arduino
0x80A1 | GRAVITECH CUCUMBER R ESP32S2 - CircuitPython
0x80A2 | GRAVITECH CUCUMBER R ESP32S2 - UF2 Bootloader

These are for the non-sensor M variants (M and MI)
0x80A3 | GRAVITECH CUCUMBER M ESP32S2 - Arduino
0x80A4 | GRAVITECH CUCUMBER M ESP32S2 - CircuitPython
0x80A5 | GRAVITECH CUCUMBER M ESP32S2 - UF2 Bootloader

These are for the sensor M variants. (MS and MIS)
0x80A6 | GRAVITECH CUCUMBER MS ESP32S2 - Arduino
0x80A7 | GRAVITECH CUCUMBER MS ESP32S2 - CircuitPython
0x80A8 | GRAVITECH CUCUMBER MS ESP32S2 - UF2 Bootloader

The original PIDS should be used for the R sensor variants (RS and RIS)
0x800C | GRAVITECH CUCUMBER RIS ESP32S2 - Arduino
0x800D | GRAVITECH CUCUMBER RIS ESP32S2 - CircuitPython
0x800E | GRAVITECH CUCUMBER RIS ESP32S2 - UF2 Bootloader

[skieast]

Is this PR moving forward? Not to rush it but I'm using my version for testing as the board has connectors for USB native and USB serial and onboard I2c devices. All good for testing without needing a ton of wiring and bits that fall off when I move it around.

[cotdp]

Hi @skieast , I only have a Cucumber M to test with. Happy to make the amendments to the PR to get it building. Though don't have the R boards to confirm/test with.

[skieast]

Hi @skieast , I only have a Cucumber M to test with. Happy to make the amendments to the PR to get it building. Though don't have the R boards to confirm/test with.

I have the RIS board so can test the R variants with that. The only difference should be the PSRAM on the R variants.
Thanks,

[anecdata]

I have R[I] (and R[I]S), and can test that specifically. I'd expect the build to be identical except for PID and board name. Technically, the R[I] (and M[I]) don't require designated I2C, but the pre-soldered header pins and pinout doc are color-coded for 40/41 the same as the RIS. Saola builds of course run fine on Cucumber, just lack the conveniences like LED, SDA, and SCL.

[skieast]

I believe in my build I disable the check for pull-ups in the i2c as the cucumber doesn't have any on the internal bus. At least I was getting errors when creating an instance. Will have to check again when I have a chance

[anecdata]

Pins 40 and 41 are also JTAG pins, so they're set to never reset for the port if DEBUG || JTAG, and trying to init I2C gets ValueError: IO40 in use. So no I2C and DEBUG=1. Is there any flexibility with that? DEBUG log is super helpful.

[dhalbert]

I believe in my build I disable the check for pull-ups in the i2c as the cucumber doesn't have any on the internal bus. At least I was getting errors when creating an instance. Will have to check again when I have a chance

The pull-up check is meant to check for external pullups. Adafruit microcontroller boards don't generally have pullups unless there are on-board I2C sensors. All our breakouts do have sensors. So we don't disable pull-up detection, and I would not expect you to either, since the typical external I2C breakout has pull-ups.

[skieast]

I've only done this on my internal build as its otherwise painful to use the sensors on the board. Would be far better if gravitech had pullups on the internal (on board) i2c bus. when i have more time maybe i'll just bodge on some resistors.

[anecdata]

With non-DEBUG build, this RS seems fine reading the sensors with nothing external:

I2C addresses:
0x5f HTS221x5F
0x68 MPU6050x68
0x76 BMP280x76
Temp=83.8F Hum=19.9% Press=1004.8hPa 

[dhalbert]

Hi folks, would you like to keep working on this? It sounds like there might be some pin cleanup needed, but otherwise it's close.

[anecdata]

The Cucumber boards are basically Saola boards, with different form factor, an LED, and second USB-C connector (and sensors on the "S" versions). Saola firmware runs just fine on these boards.

In this PR, are we doing 1 board (R/RS), 2 boards (R and RS, or M/MS and R/RS), or all 4 boards (M, MS, R , RS)?

If R & RS are combined, I think it's OK as is to define SDA and SCL, but not I2C, though on the R version, it's just Gravitech's color coding and compatibility with the RS version that would dictate those pins as I2C. But with separate definitions, I think we'd want the I2C singleton on the RS version.

I'm not sure why SPI pins are defined other than Gravitech's color-coding.

Are there any other Adafruit pin naming conventions (like board.LED) we should add extra pin names for in board? Saola is bare-bones pins.c, only IO pins, RX/TX, and NEOPIXEL. Should we try to normalize pin naming longer-term across all ESP32-S2 boards?

There are other differences from Saola R in mpconfigboard.h (these currently missing in this PR):

#define CIRCUITPY_BOOT_BUTTON (&pin_GPIO0)

#define BOARD_USER_SAFE_MODE_ACTION translate("pressing boot button at start up.\n")

[dhalbert]

Are there any other Adafruit pin naming conventions (like board.LED) we should add extra pin names for in board? Saola is bare-bones pins.c, only IO pins, RX/TX, and NEOPIXEL.

If there is a single-color LED, definitely add board.LED. In general we try to make the pin names correspond to the board silkscreen names. It is not necessary to add board.TX, etc., if they are not labeled as such.

Should we try to normalize pin naming longer-term across all ESP32-S2 boards?

The ESP32-S2 boards are not necessarily consistent about their silkscreen names, so this does nnot need to be a goal.

[skieast]

Makes sense to me. I did two definitions, for the M variants and the R variants. As you said basically the Saola with an additional led. (and I2C sensors.
Although some pins are not specifically labelled on the board they are on the pin-out diagram so it makes sense to me (fwiw) to define them.

[anecdata]

I did two definitions, for the M variants and the R variants.

@skieast can you commit the M/MS version? Are there material differences besides in ports/esp32s2/boards/gravitech_cucumber_*/sdkconfig?

[skieast]

I did two definitions, for the M variants and the R variants.

@skieast can you commit the M/MS version? Are there material differences besides in ports/esp32s2/boards/gravitech_cucumber_*/sdkconfig?

I don't have an M board to test so my version for that board is theoretical.
The only changes should be in sdkconfig, mpconfigboard.c (MICROPY_HW_BOARD_NAME), mpconfigboard.mk (USB_PID and USB_PRODUCT). As I can't test this board I would not commit my initial changes

[anecdata]

I don't have an M board either. @cotdp are you still around? If not, maybe we stick with the R-variants for this PR.

[anecdata]

I'm unavailable next week, but if there's no progress on this, I should be able to get all four boards sorted hopefully the week after. We should be able to test and release the R boards. The M boards could be held for someone with an M board to test (or put out there to see if any issues arise - they should be minor).

[tannewt]

Closing in favor of #5097