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

Adafruit 3.5" 480*320 TFT FeatherWing V2 (TSC2007) not supported? #753

Open
TheRealSimon42 opened this issue Jun 16, 2024 Discussed in #748 · 5 comments
Open

Adafruit 3.5" 480*320 TFT FeatherWing V2 (TSC2007) not supported? #753

TheRealSimon42 opened this issue Jun 16, 2024 Discussed in #748 · 5 comments
Labels
hardware New hardware or driver help wanted Extra attention is needed

Comments

@TheRealSimon42
Copy link

Discussed in #748

Originally posted by TheRealSimon42 June 2, 2024
Hello everyone,
I am just trying to get started with this wonderful Project here, but run into the issue that my Touchscreen is not working. The screen itself is lighting up and showing everything correct, but the touch is not working (I am just able to navigate via the website, when enabling the cursor it stays where it is).

Hardware:

I suspect the reason for that (just my best guess) is the TSC2007 Touch controller because on the installer page (6.4 or so) it says STMPE610 under Touch Controller. I already found out that there is a nightly installer, but also the TSC2007 or v2 doesn't show up here. When using a FW-File from the Actions-Tab on Github, i.e. huzzah32-featherwing-35-v2_ota_v0.7.0-rc12_944f92e.bin, the screen won't show anything anymore.

But what confuses me, is that it shows up as supported inside the Documentation: https://www.openhasp.com/0.7.0/hardware/adafruit/featherwing/#supported-devices:~:text=(HX8357D%20with%20TSC2007%20resistive%20touch)

Is this maybe an Issue with the Web-Installer?

@fvanroie
Copy link
Collaborator

Hi, I don't own this hardware combination myself. This configuration is user-contributed, so if these binaries don't work it will require some tweaking and compilation of the firmware locally...

@TheRealSimon42
Copy link
Author

Okay, I understand. Maybe some Hint on the HW-Page would be great for new users 😉

By the way, if you want to get your hands on the HW and implement it into the installer, I would be happy to send it over to you as a loan 👌

@fvanroie fvanroie added help wanted Extra attention is needed hardware New hardware or driver labels Jun 27, 2024
@LarsMichelsen
Copy link
Contributor

LarsMichelsen commented Oct 11, 2024

But what confuses me, is that it shows up as supported inside the Documentation

I was also mislead by the documentation and thought it was a well supported hardware (huzzah32-v2 board with featherwing-35-v2 in my case). The website could be clearer on https://www.openhasp.com/0.7.0/hardware/#supported-devices to prevent that. Later on I found https://www.openhasp.com/0.7.0/firmware/#recommended-boards which is giving a clearer recommendation. A link to that might help.

Anyways, I have good news. I spent the past 3 evenings fiddling around with this and finally got it working, first the display and just now the touch functionality.

See here: #812

@fvanroie
Copy link
Collaborator

But what confuses me, is that it shows up as supported inside the Documentation

I was also mislead by the documentation and thought it was a well supported hardware

I'm sorry you find the documentation misleading. The pages can be found in this repository and you are free to add/correct/remove any information that is deemed incorrect. There is a history and git blame if you want to check the contributors... The project is open-source and all the information and code is best-effort and provided "as-is".

I only have the original FeatherWings, and I now count at least 5 different display+touch models and 5 or more different ESP32 boards that can be paired with it. So, there are at least 25 possible configurations that could (should?) be created... You quickly see, this is not that easy, and that's just for AdaFruit FeatherWings! Maybe we need to add a supported HW combination matrix to the docs?

This all leads to these questions: What's a supported board? Who tests and maintains it? Should we cut down on the number of HW? Is it reasonable to assume every page is 100% correct and up-to-date? Maybe post a disclaimer on every page? Or assign specific contributors to each page responsible to maintain it? I 'm not sure that will be feasible. Resources are spread quite thin already.

Please note this is a community effort and it is impossible for me to buy, configure, test and maintain all possible hardware configurations. We recently did a poll and there weren't any respondents using these boards. As an issue arises, thank you for contributing your solution. The next user will be thankful for it.

@LarsMichelsen
Copy link
Contributor

Please don't take my previous post the wrong way. I came across the project a few weeks ago, find openHASP a really interesting solution and am impressed by the project. Of course there is always room for improvement, but to be honest, it might be a bit boring if everything runs smoothly in such projects. In this respect, I have already had many interesting hours learning about the system and the components used. Thank you very much for the project!

Or assign specific contributors to each page responsible to maintain it?

I think something like this would work well:

  1. Write which boards are best supported. Whether it's 1 or 5 or something in between does not matter too much imho. Whatever you and or other core contributors are willing to maintain. These are then the goto choices for everyone who just wants something to get running and asks himself what to buy.
  2. Keep support for other boards as community extensions. This is for all users who have or want some special hardware. It's up to the community to support them. Mark them to be contributions and EOL their support in case issues are reported repeatedly and no fixes are provided. This can be a multi stage process, e.g. when errors are reported repeatedly for an environment, then this is marked somewhere quickly and if no one cares to fix this for longer (months?), then the environment is dropped. In Home assistant I recognized that they are dropping support for not working and unmaintained extensions. While it may feel a bit strict in the first place, if you think further about it, I think it's great to have some "lifecycle management" in place for such things. It helps the project health and in the end also user experience. Not sure if something like this is viable for a project of this size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware New hardware or driver help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants