Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arduino_default SPI and I2C enhancements #557

Merged
merged 4 commits into from
Apr 24, 2024

Conversation

jp-bennett
Copy link
Contributor

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
Copy link
Collaborator

tobozo commented Apr 23, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

tobozo commented Apr 23, 2024

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
Copy link
Contributor Author

@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
Copy link
Collaborator

tobozo commented Apr 23, 2024

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
Copy link
Contributor Author

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 tobozo merged commit 0e474e2 into lovyan03:develop Apr 24, 2024
87 checks passed
@tobozo
Copy link
Collaborator

tobozo commented Apr 24, 2024

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

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants