Skip to content
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 library issues #1

Closed
fpistm opened this issue Aug 30, 2017 · 3 comments
Closed

SD library issues #1

fpistm opened this issue Aug 30, 2017 · 3 comments
Assignees
Labels
bug 🐛 Something isn't working

Comments

@fpistm
Copy link
Member

fpistm commented Aug 30, 2017

From @fpistm on May 18, 2017 15:46

Link to SD lib need some correction.

Copied from original issue: stm32duino/Arduino_Core_STM32#2

@fpistm fpistm self-assigned this Aug 30, 2017
@fpistm fpistm added the bug label Aug 30, 2017
@fpistm
Copy link
Member Author

fpistm commented Aug 30, 2017

Update/correct the modified SD library. In case of TFT bitmap logo example, File object is passed as an argument to R/W function but like File object is copied the current file pointer is reset so it is always read from the beginning.

fpistm added a commit to fpistm/STM32SD that referenced this issue Sep 19, 2018
Using the TFT library TFTBitmapLogo example, SD file opened is
passed to read function. If FIL is not a pointer (as it is copied thanks
the copy constructor), file read/write pointer (fptr) is never
incremented so always reading from beginning of the file.

Fix stm32duino#1

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32SD that referenced this issue Sep 20, 2018
Using the TFT library TFTBitmapLogo example, BMP file opened is
passed to read16/32 functions. If 'FIL _fil' is not a pointer
(as it is copied thanks the copy constructor), file read/write
pointer (fptr) is never incremented so always reading from
beginning of the file.

Fix stm32duino#1

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
@fpistm fpistm closed this as completed in #6 Sep 20, 2018
@ppescher
Copy link

ppescher commented Oct 1, 2018

Hi @fpistm

I was using this library together with STM32FreeRTOS and I was concerned by library code that makes use of malloc(), such as this or even String from Arduino core.

I solved it by providing some hook functions for newlib to handle mutual exclusion and reentrancy problems ( I can prepare a PR for that if you want), but I was wondering if dynamic memory allocation was actually necessary here.

What exactly was the issue with the previous version, with a member FIL structure? Can't we just provide a copy constructor? Or pass File objects by reference/pointer instead of by value?

@fpistm
Copy link
Member Author

fpistm commented Oct 1, 2018

The issue was in some case the SDFile is passed to function which do some read.
In this case, the FIL member was simply copied so when returning the fp was not at the good position.

Example here:
https://github.com/arduino-libraries/TFT/blob/d52cb5d334dbbc0f3931c924106b0d5c8aba6ba7/src/utility/Adafruit_GFX.h#L327

bmpfile is used several time and so always read from the beginning as the Fil was not dynamic.

About the PR I'm always interested by improvement. Thanks in advance.

@fpistm fpistm added bug 🐛 Something isn't working and removed bug labels Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants