-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Statemachine improvements #6360
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
Conversation
This can be used to make sure a PIO has actually finished all data it was schedule to receive via a 'once' background_write
Always use DMA if swap flag is enabled. Improve docs a bit
Works in conjunction with adafruit/circuitpython#6360 * get rid of the need for 'filler' in morse demo * make neopixels work super fast without explicit byteswapping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed a doc formatting issue (extra """
). I added (reverse)
in the documentation for the swap
arguments, to clarify that the byte order is reversed, since swap is not so obvious for the 4-byte case. If you disagree with that, we can change it back. I will not merge pending your thoughts on that.
@@ -674,13 +674,26 @@ static bool _transfer(rp2pio_statemachine_obj_t *self, | |||
size_t len = MAX(out_len, in_len); | |||
bool tx = data_out != NULL; | |||
bool rx = data_in != NULL; | |||
if (len >= dma_min_size_threshold) { | |||
bool use_dma = len >= dma_min_size_threshold || swap_out || swap_in; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any risk that having DMAs for sizes less then the threshold that require swaps will cause either a speed issue for the small DMAs or potential exhaustion of DMAs? It may not be any concern just wanted to bring it up.
Rest looks great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really know. :) There are 12 DMAs; audio might claim 2 in the background, and this code now claims up to 2. so it looks like there should be plenty left over.
At first I wanted to say this was no change for existing code, but it IS a change. Before, if you had a LARGE buffer but couldn't allocate DMA, the code would fall back to copying in a CPU loop. Now, it will return an error.
@dhalbert thanks, the doc changes look fine to this human but I see the doc build is (still) failing. |
Now if only I knew how to write the core code to allow 'await state_machine.async_write(buf)` |
For this, I think the easiest thing to do is to pass an |
This makes it possible to
Closes: #6359, closes #6357