v2 changes: remove optional Arduino support

Does anyone have a board to test on?

This is a nice board but I don't know if we can get it in for this release. I can try to add it to the wishlist.

I also think @gschorcht is super busy right now.

In fact, there is no functional difference between this board definition and the board definition in PR #11265. Although there is a GPS receiver integrated on this board while there is a display on the board in PR #11265, both components are connected via peripheral interfaces and are not used in the board definitions. The only real difference is the mapping of the GPIOs to the peripheral interfaces.

So the question for me is whether it would be enough to test LoRa functionality with one of these boards and to double check the GPIO/peripheral mapping in the source code.

All other functionalities are the same as for any other ESP32 board.

v3 changes:

• add Arduino support again, as it is mandatory for ESP32 i.e. included from boards/common/esp32/include/board_common.h
• fix some typos

@gschorcht I have just mapped three Arduino pins (UART RX/TX and the LED pin). Is it sufficient for now?

I have ordered the board and I hope that I will have it on Wednesday. I will test the PR later this week.

@gschorcht great, thanks.

I'm trying to implement TTN-Mapper for RIOT (https://github.com/yegorich/ttn-mapper-riot). For now it can only read and parse GPS frames but it should be sufficient for GPS/UART testing.

It seems that I have another version of the board. I don't have a LED at GPIO14. It seems that I don't have a LED at all. I have 3 buttons RST, IO38 and PWR. Instead of GPIO34, GPIO15 is broken out.

Tested successfully:

• example/gnrc_networking with esp_wifi and esp_spi_ram
• tests/driver_sht3x which uses periph_i2c
• tests/driver_sx127x
• tests/periph_gpio
• tests/shell

tests/driver_sht3x failed during the initialization of the sensor since the first two I2C write operations to the sensor show some disruptions with logic analyzer.

SPI can't be tested with external hardware since the according GPIOs are not broken out. However, in example/gnrc_networking compiled with module esp_spi_ram and in tests/driver_sx127x, the SPI is used for SPI RAM and the LoRa module. Maybe, a second SPI that uses the HSPI controller should be defined for external hardware.

@gschorcht thanks for review. Seems like I have the rev0 version (https://www.banggood.com/LILYGO-TTGO-T-Beam-ESP32-433868915Mhz-WiFi-Wireless-bluetooth-Module-p-1320390.html) that provides LED and according to this README (https://github.com/kizniche/ttgo-tbeam-ttn-tracker/blob/master/README.md) they have different pinouts including GPS. Looks like we have to differentiate them.

Have I mixed up the UART pins for 1.0 board?

If I invoke init 1 9600, I get the following output at once:

2019-12-17 12:43:36,041 #  init 1 9600
2019-12-17 12:43:36,045 # Success: Initialized UART_DEV(1) at BAUD 9600
2019-12-17 12:43:36,296 # UARD_DEV(1): test uart_poweron() and uart_poweroff()  ->  [OK]
> 2019-12-17 12:43:36,369 #  Success: UART_DEV(1) RX: [0x91GPGSV,3,1,11,02,30,245,,04,09,085,,05,44,297,18,06,13,205,*7A0x0d]\n
2019-12-17 12:43:36,437 # Success: UART_DEV(1) RX: [$GPGSV,3,2,11,07,71,128,21,09,41,087,,13,11,262,,16,14,029,21*7C0x0d]\n
2019-12-17 12:43:36,493 # Success: UART_DEV(1) RX: [$GPGSV,3,3,11,23,15,088,17,29,04,315,,30,49,194,27*450x0d]\n
2019-12-17 12:43:36,545 # Success: UART_DEV(1) RX: [$GPGLL,5340.04267,N,00959.21224,E,114336.00,A,A*6C0x0d]\n
2019-12-17 12:43:37,136 # Success: UART_DEV(1) RX: [$GPRMC,114337.00,A,5340.04226,N,00959.21284,E,0.634,,171219,,,A*770x0d]\n
2019-12-17 12:43:37,166 # Success: UART_DEV(1) RX: [$GPVTG,,T,,M,0.634,N,1.174,K,A*210x0d]\n

Tested again:

• example/gnrc_networking with esp_wifi and esp_spi_ram
• tests/driver_bmp180 which uses periph_i2c
• tests/driver_sht3x which uses periph_i2c fails
• tests/driver_sx127x
• tests/periph_gpio
• tests/shell

I'm still not happy that tests/driver_sht3x doesn't work, neither in I2C normal mode nor in I2C fast mode. I had never problems with this sensor driver. My logic analyzer recognizes sometimes the wrong slave address. Maybe, the problem is related to AXP192 that is connected to the I2C bus. I have no idea for what purpose, the data sheet is in Chineese 😟

Have I mixed up the UART pins for 1.0 board?

Board configuration:
	UART_DEV(0)	txd=1 rxd=3
	UART_DEV(1)	txd=12 rxd=34

No, GPIO34 can be only an input. That is it has to be RX.

I don't get anything:

> init 1 9600
Success: Initialized UART_DEV(1) at BAUD 9600
UARD_DEV(1): test uart_poweron() and uart_poweroff()  ->  [OK]

According to NEO-6M datasheet, it can operate at the following baud rates: 4800, 9600, 38400 and 57600. The baud rate will be configured via CFG_COM0 and CFG_COM1 pins. Though the default value is 9600. Could you try all these values i.e. does oscilloscope show anything on the TX pin of GPS?

There is nothing. If it would be a problem of baudrate, at least some garbage should be printed out. I can't see anything with logic analyzer too.

It seems that the NEO-6M has no power. It is provided as GPS_VDD by the AXP192. Maybe, the AXP192 has to be programmed. It is also connected to I2C bus. I suppose, this produces also the problems with the SHT3x. Maybe, they use the same address. I will have to take a look into the software in TTGO repository.

Indeed, the AXP192 is an I2C slave with address 0x34 and has to be programmed. It seems that the different power outputs LDO2 and LDO3 can be programmed. Maybe they are off by default.

Enabling on-board modules is something that would have to be done in board's board_init function. It can't be part of a NEO-6M device driver.

Hm.. in order to enable the LDOs, we need to implement a driver for AXP192 link this library does. Perhaps we should split the effort: I rework this PR to support rev0 and rev1 and just mention the upcoming support for V1.0 and then you can make a followup PR with the full V1.0 support? Or we leave it as is and add LDO/GPS support later?

Hm.. in order to enable the LDOs, we need to implement a driver for AXP192 link this library does. Perhaps we should split the effort: I rework this PR to support rev0 and rev1 and just mention the upcoming support for V1.0 and then you can make a followup PR with the full V1.0 support? Or we leave it as is and add LDO/GPS support later?

Principially, it shouldn't be a big thing. One small I2C transaction to write one register should be enough to switch on the GPS. I can try it later today. That is, the board definition for V1.0 would use periph_i2c and the board_init function would just hard-write power on for LDO3. The Lora module at LDO2 seems to be on by default, tests/driver_sx127 is working as expected.

OK, that are the results after I wrote a board_init function which enables LDO3 via I2C

Success: UART_DEV(1) RX: [$GPRMC,,V,,,,,,,,,,N*530x0d]\n
Success: UART_DEV(1) RX: [$GPVTG,,,,,,,,,N*300x0d]\n
Success: UART_DEV(1) RX: [$GPGGA,,,,,,0,00,99.99,,,,,,*480x0d]\n
Success: UART_DEV(1) RX: [$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*300x0d]\n
Success: UART_DEV(1) RX: [$GPGSV,1,1,00*790x0d]\n
Success: UART_DEV(1) RX: [$GPGLL,,,,,,V,N*640x0d]\n

I'm bad in interpreting the NEMA data. We should have a driver for it.

Since we had only board_init in boards/common/esp32, I had to touch all boards to be able to write a board specific boar initialization.

Therefore, I would suggest that we merge this PR as it is. I will than provide my changes as a separate PR. Would this be OK for you. Alternatively, I could provide my changes to your branch.

It could be further refined in that way that the GPS module is nonly switched on, if the driver module for the NEO-6M module is used. BTW, I guess that the driver module would be not NEO-6M specific. Rather the driver would be a UART-based driver that interprets NMEA messages.

The last problem we should discuss before we merge is why the board has problems with SHT3x sensor.

I'm for merging this PR as is. Let me know when I can squash it.

I'm for merging this PR as is. Let me know when I can squash it.

Have you tried any I2C device with your board?

Yes, I've attached the BME280 sensor. But it was long time ago and with Arduino IDE.

I'm now trying to run the tests/driver_bmx280 and it fails with "Unable to communicate with any BMX280 device". Need to measure the signals.

It might be a problem with the pull-ups. In contrast to other boards, the TTGO board has external pull-ups. The SHT3x sensor module I use has also 4.7 kOhm pull-ups. And the I2C peripheral driver uses of course OD outputs with enabled pull-ups of 4.7 kOhm. So we have 10 kOhm pull-ups on TTGO board in parallel to the 4.7 kOhm pull-ups of the ESP32 and the 4.7 kOhm pull-ups of my SHT3x. The overall pull-up is then about 2 kOhm.

BTW, there are other drivers that do not work in I2C fast mode, e.g., tests/driver_ccs811 or tests/driver_mma8x5x. But some of them work in I2C normal mode.

My BME280 board seems to be dead. I couldn't talk to it neither via TTGO nor via NUCLEO-F103RB. But I've connected TTGO board directly to the NUCLEO-F103RB and run the ROBOT tests. The results were the same as in the nightlies.

But I've connected TTGO board directly to the NUCLEO-F103RB and run the ROBOT tests. The results were the same as in the nightlies.

My guess is still that the I2C problem with various sensors is related to the pull-up configuration, which has nothing to do with the board definition in this PR. I wonder if we should make the pull-ups configurable in ESP32 to catch problems as with this board. Lets say we define a pseudomodule esp_i2c_no_pullups and the according board definition would just use this module to disable the internal pullups. What do you think?

Anyway, let's continue with the board definition as it is. Please squash.

Squashed.

Nice job everyone... Now I need to get that board 😄

@gschorcht @MrKevinWeiss thanks for your help!