Skip to content

Fix RMT buffer allocation #3512

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

Merged
merged 2 commits into from
Jan 20, 2020
Merged

Fix RMT buffer allocation #3512

merged 2 commits into from
Jan 20, 2020

Conversation

collin80
Copy link
Contributor

As the code sits, you can't use the last RMT buffer, basically because of an off by one style error. The comparison I changed should be "greater than" only not "greater than or equal to." It's OK if i+j = MAX_CHANNELS. In the case of having four inputs, all using 2 buffers each, this leads to i being 0, 2, 4, 6 and each takes up two buffers so the allocation is 0-1, 2-3, 4-5, 6-7. The 6-7 is the problem because i+j will equal 8 but really that still means only 6-7 are being used as j is always one larger than the actual offset from the starting buffer.

With the >= used let's say you have four RMT inputs, each using 2 channels wide for their receive buffer. This is 4*2 = 8 buffers which is the number of hardware buffers (MAX_CHANNELS). But, for the fourth input the starting buffer will be 6 (this is correct, the buffers used for each input are 0-1, 2-3, 4-5, 6-7). But, 6+2 = 8 which  is MAX_CHANNELS. This is valid but the >= would match against it and abort. It is correct to only abort if the value i+j is only greater than MAX_CHANNELS. Thus, a simple one character fix. Delete the equals sign.
@me-no-dev me-no-dev merged commit 7b3c1df into espressif:master Jan 20, 2020
@me-no-dev
Copy link
Member

nice find :) just love those type of bugs

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.

2 participants