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

fix: Wire::writeReadAsync always malloc'ing DMA buffer #2796

Merged
merged 1 commit into from
Feb 8, 2025

Conversation

veecle-stefan
Copy link
Contributor

The async implementation of I2C (Wire) seems to allocate the DMA buffer for every call because the check, whether the current buffer is large enough (if (_dmaSendBufferLen < bufLen) {) is always true because _dmaSendBufferLen is never actually set anywhere.

Simple fix: added a line after successful malloc that sets the _dmaSendBufferLen = bufLen.

PS: Shouldn't we use new uint16_t[bufLen] here, since we're in a C++ object? It probably maps to malloc but it would at least avoid one cast.

…allocating the DMA buffer anew on every call
@veecle-stefan veecle-stefan changed the title fixed: Wire::writeReadAsync not setting _dmaSendBufferLen, therefore … fix: Wire::writeReadAsync always malloc'ing DMA buffer Feb 8, 2025
@earlephilhower
Copy link
Owner

Great catch, thanks!

I'm fine leaving malloc/free in place of new[]/delete[] here. For primitives there's no consistency here and it depends on what I was feeling like the day I wrote the code. The one gotcha, though, is that new could throw which we can't catch (unless you explicitly enable exceptions in the IDE and blow up your code size). They map down to malloc and free in any case, like you said...

@earlephilhower earlephilhower merged commit 3c556e6 into earlephilhower:master Feb 8, 2025
26 checks passed
@veecle-stefan veecle-stefan deleted the fix-Wire-Async branch February 8, 2025 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants