-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Sd File::availableForWrite() #7650
Comments
@fabiuz7, interesting note. I'm not sure that the same technique can be used by our newer version of the SdFat library (the Arduino fork is ancient...), but if it is then it seems like it would be a reasonably simple PR. Would you be interested in submitting one? |
start by adding availableForWrite to Print |
I may try, but I'm not very familiar with sdfat library. However I was looking at esp8266 arduino repo, and I found that Serial and WiFi already as a similar method. Does a virtual "availableForWrite" in Print class introduce conflict with WiFi and Serial classes? |
Good pointer, @JAndrassy! Looks like that was added ~1yr ago to the Arduino upstream core. @fabiuz7 In the end if there's no compile-time ambiguity, it should be fine. I think that's what would be needed, anyway. You can add it in a PR and the continuous integration system will verify no compiles get broken. |
I linked to API repo which is not really used. it missed it too. to AVR and SAMD it was added in 2017 |
Adds an availableForWrite() method to the Print class, matching current ArduinoCore-API commit 398e70f188e2b861c10d9ffe5e2bfcb6a4a4f489 . Hook availableForWrite into the SDFS filesystem (other FSes don't have this capability built-in). Fixes esp8266#7650
Hi, I had tried this sketch. It compiles but it continues to store the data in the local buffer, the SD card is never written. |
Thanks for the feedback. I double checked (added the avail4Write call to LittleFS and got expected results) the code and it's actually working correctly. The latest SDFat library does not support I don't know why Arduino would have added new stuff to the ancient fork vs. pulling in the currently maintained version and doing a PR. Let me see if the hack they did can be added to our own ESP8266SdFat library. I'm not so sure, given their ancient codebase, but will let you know if something comes up. |
I've spent some time trying to hack in the Arduino patch to the modern SD library and have to say that it's beaten me, @fabiuz7 . :( There have been a lot of little changes to the SD library architecture which make some of the hacks Arduino did not directly translatable. So, I think you's out of luck for SD.availableForWrite() for the time being. The actual patch to consolidate it under a |
Thanks for the investigation. That's a pity that Arduino's version diverged so much from the original SdFat, limiting the inclusion of features in other cores :( |
* Add Print::availableForWrite method Adds an availableForWrite() method to the Print class, matching current ArduinoCore-API commit 398e70f188e2b861c10d9ffe5e2bfcb6a4a4f489 . Hook availableForWrite into the SDFS filesystem (other FSes don't have this capability built-in). Fixes #7650 * WiFiClient::availableForWrite proto matching Print * Fix Netdump signedness warning * Clean up Serial availableForWrite This is evidently a breaking change due to the type difference. Arduino's `availableForWrite` returns an `int`, while the (multiply-implemented, non-virtual) core `availableForWrite` returned `size_t`.
Hi again, |
See #7779 |
* Update to upstream SdFat 2.0.2 Increases the read/write performance for SD card accesses by a significant amount, up to 5x (3+MB/s) in testing. Fixes #7772 * Add SDFS::availableForWrite handler Peek into the sector cache to determine the maximum number of bytes that can be written w/o needing a (slow) SD operation. Fixes #7650
Hi, I have recently discovered
int availableForWrite()
to check the amount of available bytes without waiting for new "sector" (hence avoiding blocking writings). here) the example that demonstrate it.Is there any plan to add to esp8266 core?
The text was updated successfully, but these errors were encountered: