@ESP-Sprite: Thx for that info. That explains a strange 32 bits readings of GPIO_OUT_REG after execution of
*((volatile uint8_t *) (GPIO_OUT_REG +1)) = 0x01;
uint32_t read_val = _DPORT_REG_READ(GPIO_OUT_REG);
read_val contains 0x01010101 (all 4 bytes populated by written byte) on old ESP32 chip version. So there are no byte strobes implemented on virtually mapped registers, or the C compiler doesn't generate proper instruction for BYTE writing, or there is cache related issue.
@ok-home: Thx for the link. I didn't know those older ESP32 have direct LCD/CAM support. At least it is not mentioned in TRM related to those ESP32 with LX6 core.
you create a problem for yourself and then try to solve it
Its not as simple as that. I am trying to redesign a lot of different, already working devices in production, by replacing old microcontrollers by ESP32 and implementing some new features like WIFI/BT support, color LCD (replacing an old character display), touch etc.
However, any version of ESP32xx doesn't have enough pads to cover already supported features (by old design) and those new which are required for upgrading. So we are considering of using two ESP32 chips. One ESP32S3 (we have that developing board with USB, LCD and touch, rs485, SD card, audio). After all of those, there are not enough available free pads for other purposes that S3 can cover (for data-bus, address decoder, CAN bus and power management) especially if you add to that, that some pins are only inputs (by design) and some are overlapped with strapping functionalities. So we need an additional ESP32 to cover only those features not covered by the first chip and to communicate with the first ESP32S3. Due to the lack of hardware implementation of those features in old ESP32 versions, it looks that (second chip) has to be also ESP32S3. That's, why I am performing all those tests.
Sure, 10 years ago or so, when the first ESP32 is released, its mainly purpose was advancing an older ESP8266 wifi/bt targeting IoT. Today, its main purpose is still IoT. However, implemented functions in S3 model are amazing (with respect to its cost). That makes it suitable for much wider designs and not only related to IoT. But in those, the main issue is the small amount of available bidirectional pins.
