arduino_default SPI and I2C enhancements

[jp-bennett]

There's a trio of changes here. Up first is adding I2C support to arduino_default, ifdef'd behind whether the Wire library is available.

Then there's an added quirk to Touch_FT5x06.cpp, as on native Linux, it seems any repeated I2C reads trigger a re-read of already read registers.

And finally, the arduino_default bus_spi gets a configurable SPI device, again for native systems that have multiple SPI devices.

[tobozo]

hi and thanks for that long waited contribution 👍

can you please provide a simple hello world project (doesn't need to be added to this PR) triggering the portduino configuration so this can be tested from a CI?

[jp-bennett]

can you please provide a simple hello world project (doesn't need to be added to this PR) triggering the portduino configuration so this can be tested from a CI?

Yeah, that's a reasonable ask. Is it acceptable to make it a PlatformIO project? (runs from the CLI with the python pio command)

[jp-bennett]

Also, it may be more useful to use PORTDUINO_LINUX_HARDWARE, which is defined in portduino itself, instead of ARCH_PORTDUINO, which is strictly in meshtastic.

[tobozo]

Is it acceptable to make it a PlatformIO project?

sounds good

Also, it may be more useful to use PORTDUINO_LINUX_HARDWARE, which is defined in portduino itself, instead of ARCH_PORTDUINO

why not use both e.g. #if defined PORTDUINO_LINUX_HARDWARE || defined ARCH_PORTDUINO

[jp-bennett]

@tobozo I have a very minimal portduino project at https://github.com/jp-bennett/portduino-hellorld that links in LovyanGFX. It's enough to compile test the code in question. Is that what you wanted, or should I be also firing up the display and touchscreen on real hardware?

[tobozo]

ok got it to compile (CI will need to apt install libgpiod-dev) so there's a reproductible platformio env, but the main.cpp should print("hello world") to a display object instead of the console; the project needs a custom lgfx configuration, if possible it should use the FT5x06 Touch driver too

that custom configuration doesn't need to have a working pinout and won't run with real hardware anyway, it only has to trigger both #ifdef blocks added in this PR and make use of the i2c bus:

void setup() {
  tft.init(); // or tft.begin()
  tft.print("hello world");
  lgfx::touch_point_t tp;
  auto blah = tft.getTouchRaw(&tp);
}

[jp-bennett]

but the main.cpp should print("hello world") to a display object instead of the console; the project needs a custom lgfx configuration, if possible it should use the FT5x06 Touch driver too

Added the display and touchscreen code, over at https://github.com/jp-bennett/portduino-hellorld https://photos.app.goo.gl/eMZyPSnufHiicRmo6 That's running with the Adafruit PiTFT Model B+ on a Raspberry Pi 5.

[tobozo]

successfully integrating the native build in the github workflow wasn't obvious as platformio is both friendly and hostile to github matrix :thong_sandal:

now I'd like if possible to change that line in the platformio.ini file to a tag or branch instead of a commit hash

platform          = https://github.com/meshtastic/platform-native.git#659e49346aa33008b150dfb206b1817ddabc7132

this platform value appears to compile just fine:

platform          = https://github.com/meshtastic/platform-native.git#develop

however it's pointing to a possibly unstable branch and may break at any time; a tag would be more appropriate but the repository doesn't seem to make use of tags since 2020

creating a new tag (e.g. v1.2.0) pointing to the 659e49346aa33008b150dfb206b1817ddabc7132 commit would allow the ini part to become more humanly readable and easier to map from a semver-aware matrix workflow:

[env:native-default]
extends           = native, portduino
platform          = https://github.com/meshtastic/platform-native.git#develop

[env:native-v1.2.0]
extends           = native, portduino
platform          = https://github.com/meshtastic/platform-native.git#v1.2.0

this is only worth using if the repository creates new tags regularly though (e.g. when a milestone is reached or a new feature introduced)

if you're not planning to manage tags on this repo I'll just leave the commit hash as it is

[jp-bennett]

a tag would be more appropriate but the repository doesn't seem to make use of tags since 2020

Portduino languished a bit until I discovered it and started pushing code. And since then things have been moving a bit too fast and furious to call anything a stable release. Hopefully before long we'll have a release and this a tag to use. We don't re-write history, so the commit hash should be usable for the foreseeable future.