CoretechR / OMOTE

Open Source Remote Using ESP32 and LVGL
https://hackaday.io/project/191752
GNU General Public License v3.0
1.02k stars 114 forks source link

Refine and implement hardware interface #37

Closed MatthewColvin closed 9 months ago

MatthewColvin commented 9 months ago

Maintenance

Documentation

Refactor

Feature

Known Issues

obi11235 commented 9 months ago

It seems pretty unstable on the hardware. More than half the time it wakes up the screen is just white. It's not a hard crash because it goes to sleep. The wifi networks screen also crashes, there are 9 pages of access points in my area, so i'm sure it's a memory issue. My crashing issues may all be related to that. I think it keeps waking up and trying to go back to the wifi page and crashing again.

Regarding the structure Personally i'd like to see some separation between the system images, wifi logo, battery, etc. and the user interface that will be different for each user, like the apple logo. It looks like void OmoteUI::layout_UI() { has all the user specific screens, it would be nice if that was just calling out to some class the user can include. For example i have some super crude code (that i'm using on mine) that can drive the tabs other than the settings page via a pair of arrays, one for the tab names and one for the components on each page https://github.com/obi11235/OMOTE/blob/inline-changes/Platformio/src/main.cpp#L162 that also relies on moving the components to functions, like the number keypad I've made so it can show up on any number of tabs (I'm not making it pretty yet because i'm waiting on some of the work you all have done on refactoring the code)

MatthewColvin commented 9 months ago

Hey @obi11235 thanks for the heads up on the crashes/odd behavior.

I am not experiencing those on my setup but I don't have a PCB but rather just a TFT wired to a dev board. But I am getting a PCB soon.

As for the architecture of the UI. I have not even started looking at that and I don't even know a lot about lvgl lol. My main objective has been to get a HAL of sorts to allow support of the SIM and HW with the same UI layer.

That goal is mostly accomplished at this point so if you would like to make a PR to the abstraction branch with an architecture/refactor for the UI I think we can work together land that :)

All that being said I need to find out how to reproduce this behavior so I can debug this thing. It may be good to reset your flash just to make sure nothing funky is going on there. https://randomnerdtutorials.com/esp32-erase-flash-memory/

obi11235 commented 9 months ago

Resetting the flash caused a different issue. The brightness values for the back light are reversed so the default value of 255 has the screen set to back light, had to patch the code to set the default to 128 and another wipe to fix that. It didn't change much.

It also doesn't remember the tab it was on after going to sleep, keeps defaulting to the status page (not sure if it really matters based on the goal of your PR)

I'm still having the white screen issue. The touch screen still works when the screen is white. Even pulling the power from the remote to fully reset everything won't make it boot up right the next time so I don't think it is related to not resting the screen. After a bunch of resets after putting the firmware on it I can get the screen to work. It may work for a few sleep / wake cycles but it ends up going back to the white screen eventually.

I put the firmware i was using back on it, the branch i shared in my first comment, and it wen't back to working as i expect it. Once in a while the firmware i was using the screen would not init right on startup, It would not default to white, the screen would have some of the interface on it (not really useful to this thread) but it would work fine on the next startup. I can force it to happen if i use the reset button on the back of the remote.

obi11235 commented 9 months ago

All that said, the white screen tends to be triggered by the crash after loading the wifi scan. I'll see if I can figure anything out there, I'm guessing that may be the root of the screen issue. Though it would be nice if after a reboot the firmware could correctly recover from that state with out a bunch of resets and some luck.

MatthewColvin commented 9 months ago

I am getting crashes on wifi scan now too. Maybe I can get a crash dump and find out why.

obi11235 commented 9 months ago

I figured out why in my case. https://github.com/MatthewColvin/OMOTE/pull/2 fixes it (i was going to move it to a null pointer check but then ran into another pile of issues and couldn't reproduce this issue)

obi11235 commented 9 months ago

Also figured out the display inverted issue, working on a PR for it. I still have (i think) the white screen issue.

obi11235 commented 9 months ago

another issue i'm seeing is it's not connecting to wifi unless i tell it to scan after a previous successful connection.

obi11235 commented 9 months ago

This fixes the back light issue with it being inverted (may or may not have been a real issue). It stops the bright flash during screen init. But it also makes the screen more stable for me, it cuts down on duplicated code that i think was causing issues, it's branched off my wifi fix. https://github.com/MatthewColvin/OMOTE/pull/3

Dark1886 commented 9 months ago

Thank you guys for working on this project a bunch and debugging. I'll hopefully be able to join and get some actual dev time on the project after wedding at the end of the month.

CoretechR commented 9 months ago

@MatthewColvin Unfortunately I am seeing the same white screen that obi11235 mentioned. Only every few times the device manages to boot up properly.

MatthewColvin commented 9 months ago

Hey @CoretechR I merged in some code by @obi11235.

@obi11235 correct me if I am wrong but with that delay readded now you are not seeing the white screen bug right?

obi11235 commented 9 months ago

@CoretechR it looks like my fixes were merged after you let your comment. I don't know if the delay was the thing that helped, but the screen got initialized more than once which I think was causing the crashes. I got the screen initialization to match the original code flow, I think it's the same now.

CoretechR commented 9 months ago

@obi11235 You are right, somehow the code I was using was not up to date. The screen works as expected now. There are still some issues like the preferences not working (remembering the current tabview page). But if it's alright with you, I'm going to merge it into the abstraction branch.

MatthewColvin commented 9 months ago

Yeah I'm am good with a merge I think @obi11235 is wanting to use this as a base for some UI development.

We can file a bug for that if we want to make sure that continues to work.

obi11235 commented 9 months ago

I can look at the issue with it not starting on the correct tab after it's merged. I also have code to make the timeout section work to control the time out function i'll add.