search

BitMaker-hub / NerdMiner_v2

Improved version of first ESP32 NerdMiner
Other
1.5k stars 268 forks source link

New board, SD card, restructuring (update). #178

Closed elmo128 closed 11 months ago

elmo128 commented 11 months ago

Added ESP32cam board (no display implemented, ESP32-D0WD-V3 based), setup via config file on sd card, moved certain parts of code, eg. some of the nvMem access to a dedicated class. As this is a rebased version of an earlier pull request, this class does not yet handle logging and other new features, except enable/disable.

BitMaker-hub commented 11 months ago

After this merge we will need to recheck all boards. But current SPIFF config is not compatible with NVME structure you proposed. I had to reconfig board.

Can you check if is possible to setup the NVME partition on same place were current json config file is?

BitMaker-hub commented 11 months ago

Sorry, that was not part of your job. This was merged before, but some of your changes is chrashing ESP32-2432S028R board

elmo128 commented 11 months ago

After this merge we will need to recheck all boards. But current SPIFF config is not compatible with NVME structure you proposed. I had to reconfig board.

The config files on flash and SD card share the same set of keys. I changed them to be more self-explanatory, as it is intended for users to modify their value on the card.

Can you check if is possible to setup the NVME partition on same place were current json config file is?

It should still be in the same location, only the keys vary.

elmo128 commented 11 months ago

Sorry, that was not part of your job. This was merged before, but some of your changes is chrashing ESP32-2432S028R board

I don't have access to this board. If you need assistance, feel free to share the logs. PS: Does it crash, if you try to access the config page?

nitroxgas commented 11 months ago

Hi Elmo128! The board crashes because there's no more heap space available to deal with the screens, and sometimes even https connections can't be established. Some boards are dealing with extremely low resources, so my suggestion is that changes like implementing new features that are not shared among all boards should be protected by compilation directives (#ifdef). Or even contained inside the driver area of that specific board. For example, I´ve implemented the touch function inside the board code to restrict him.

elmo128 commented 11 months ago

Some boards are dealing with extremely low resources, so my suggestion is that changes like implementing new features that are not shared among all boards should be protected by compilation directives (#ifdef).

Or even contained inside the driver area of that specific board. For example, I´ve implemented the touch function inside the board code to restrict him.

Hi. Really? Then the tft handling might need some changes, especially since there is no need to buffer a whole screen in ram when using pannels with controller and framebuffer. It might require some additional cpu time, but as significant portions of the screen should not change too often,... By the way, afaik dynamic memory allocation on embedded devices should stay an exception and the exception handling in monitor.cpp might have a negative performance impact as well.

nitroxgas commented 11 months ago

I know! Exactly what I did with Sprites handling in the first commit. Creating and destroying them to release memory to the httpclient. Before that, httpclient not only couldn't connect, but it started to keep a part of the memory blocked, and the board became unresponsive and restarted. So, catching these exceptions was needed to prevent the complete crash over a few minutes. Now I'm slicing each screen into 4 to be able to deal with the small amount of memory available in the esp-wroom-32.