-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
enable gzStreamUpdater progress update callback #37
Comments
@sharandac thanks for your constructive feedback I've commited some changes based on your suggestion, available on the 1.0.5-beta branch. While testing that code, I found out adding a |
Thanks for the great library and the quick response! works great! Another question that I find interesting right now. Is there a way to reduce the quite large RAM requirement? In a current project I have very little IRAM but a lot of PSRAM to do crazy things. Therefore it happens to me very often that the stream starts, but a new constructor then crashes the program. Unfortunately you can't teach the arduino-ESP32 framework to use PSRAM automatically with a new constructor. For this reason I usually use ps_*alloc or *alloc. I have also written a small "wrapper" for this. #ifndef _ALLOC_H
#define _ALLOC_H
#if defined( BOARD_HAS_PSRAM )
#include <stddef.h>
#include <stdbool.h>
#include <esp32-hal-psram.h>
#define MALLOC ps_malloc /** @brief malloac from PSRAM */
#define CALLOC ps_calloc /** @brief calloc from PSRAM */
#define REALLOC ps_realloc /** @brief realloc from PSRAM */
#else
#define MALLOC malloc /** @brief malloac from normal heap */
#define CALLOC calloc /** @brief calloc from normal heap */
#define REALLOC realloc /** @brief realloc from normal heap */
#endif // BOARD_HAS_PSRAM
#endif // _ALLOC_H |
Nice suggestion, makes me wonder if the user should decide to enable or disable psram (when applicable)? There are a few reasons for that:
I just finished testing |
Thanks again. I think your implementation is exactly the right way! The programmer should rather decide that, would have been my decision too. |
@sharandac does closing this issue mean the implementation works for you ? since your suggestions gave birth to the idea, you may be interested by the very experimental PSRamFS library and the recently added support for ramdisk |
@tobozo the first intention was that it would work for me ... now I am curious about the PSRamFS :) |
@tobozo Maybe I missed it, but is there a way to unpack from a char array? |
sure, just create some object inheriting Stream* and implement the read() readBytes() and available() methods, then pass it to gzStreamUpdater |
i would have done that next. i was also thinking if something like that already existed. would be a nice function, pointer to the data and its size. |
It'll eventually be added to esp32-psramfs as an extra Initialization will be implemented as follows: const unsigned char my_gz_bytes[] = {
// (... all the bytes of your gz file)
};
size_ t my_gz_bytes_count = 16787; // how many bytes in the array
void unpack() {
// init your TARGZUnpacker object
TarGzUnpacker *TARGZUnpacker = new TarGzUnpacker();
RomDiskStream myFakeGzStream( my_gz_bytes, my_gz_bytes_count );
Stream *streamptr = &myFakeGzStream;
TARGZUnpacker->tarGzStreamExpander( streamptr, PSRamFS );
} [edit] and there's a [edit2] here's another more generalistic implementation (with read and write) |
In the current version, the progress callback is disabled when the ESP32 is used. Could it be reactivated with the following code?
For that would be interesting to use the upstream from here instead of a standalone version. 248
The text was updated successfully, but these errors were encountered: