-
-
Notifications
You must be signed in to change notification settings - Fork 511
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
Uploaded 4.3 version with TT-GO 1.14 display #1816
base: master
Are you sure you want to change the base?
Conversation
Trial to adapt the ESP32 miner to the Lilygo TT-GO 1.14 WIP Seems to crash after a while
|
||
float sharerate = share_count / (millisecs / 1000.0); | ||
|
||
display_mining_results(String(hashrate_float, 1), String(accepted_share_count), String(share_count), String(uptime), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From our discussion on Discord:
I think I know, since it refers to a mutex it must be happening in a point when two threads found the share at almost or exactly the same time and both want to take control of the display? but it's weird as only one thread should be updating it unless I made something wrong or don't remember it correctly, I'll check in a second
No, indeed this is possible, both cores update the display. Can you check if that's the case by removing one of two display_mining_results calls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same idea just 14 minutes ago, and removing the || defined(DISPLAY_114) from the second core seems to do the trick...
After seeing a few times the display half frozen before the console crashes...
it is now working since 15 minutes, but of course updates only on core 0 shares...
Maybe the solution would be to raise a flag while the display is still doing something, and check it in the mining loop (core 0 and core 1) to wait before sending the result ?
|
||
float sharerate = share_count / (millisecs / 1000.0); | ||
|
||
display_mining_results(String(hashrate_float, 1), String(accepted_share_count), String(share_count), String(uptime), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the second instance.
ESP_Code4.3/ESP_Code/Counter.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing to add - you don't have to make a separate folder with your changes, if you uploaded it to the ESP_Code folder it would nicely show the difference between master branch and your changes,but don't worry for now, just remember for future attempts :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uploaded the new version with handleSystemEvents for both cores
added also the User_setuo.h for tft_eSPI lib
added handleSystemEvents to core 1 and core 2 as suggested Also added the User_Setuo.h for the tft_eSPI library
Changed the mining display screen to new version changed font
New version of the mining screen |
Also both settings are available in the User_Setup.h the user has to comment out or uncomment the lines according to its display type note: For st7735 the pins can be assigned differently upon user need, so they are not carved in stone as it is an excternal display. I used the pins I had already soldered on my own display and ESP
Uploaded latest code with st7735 display |
Comment or uncomment acording to your display type
sorry, still learning github...
Trial to adapt the ESP32 miner to the Lilygo TT-GO 1.14 WIP
Seems to crash after a while
I am using Bodmer's tft_eSPI library
There is also a config file in the library folder to make the onboard display recognized, it is not uploaded here