-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
rp2/rp2_pio: Add support for FIFO trigger level. #16851
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
base: master
Are you sure you want to change the base?
Conversation
Added support for FIFO trigger level. Signed-off-by: kc64 <callan.kevin@gmail.com>
Code size report:
|
Following the pattern for |
Please try to make this work for RP2350. You could detect that chip using: is_rp2350 = "RP2350" in sys.implementation._machine Also, please update the documentation to add the new parameters. |
Signed-off-by: kc64 <callan.kevin@gmail.com>
I added support for both RP2040 and RP2350. |
Signed-off-by: kc64 <callan.kevin@gmail.com>
ports/rp2/modules/rp2.py
Outdated
@@ -40,7 +42,10 @@ def __init__( | |||
from array import array | |||
|
|||
self.labels = {} | |||
execctrl = side_pindir << 29 | |||
if 'RP2350' in sys.implementation._machine: |
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.
It'd be better to hoist this condition out into a module variable, so you're not recalculating this every time.
I tested the build myself to make sure, but indeed mpy isn't smart enough to optimize it away, so it ends up assembling to:
16 LOAD_CONST_STRING 'RP2350'
18 LOAD_GLOBAL sys
20 LOAD_ATTR implementation
22 LOAD_ATTR _machine
24 BINARY_OP 6
25 POP_JUMP_IF_FALSE 43
Better to just do that test the once and assign the result to a module-level is_rp2350
value.
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.
Here's how I'd do it: kc64#1
Which ends up assembling to just:
16 LOAD_GLOBAL is_rp2350
18 POP_JUMP_IF_FALSE 36
Signed-off-by: kc64 <callan.kevin@gmail.com>
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.
"hoisted" the RP2350 check out into a module variable
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.
Apologies for the delay reviewing this!
The current automated test suite doesn't cover PIO operation, but I've at least run it against 6763b1d on hardware, and all of the tests pass on my PicoW and Pico2 boards. (The lack of automated tests for PIO would be worth addressing, but that's a formidable-enough task to be out of scope for a PR like this one.)
In place of automated tests, I've checked the rp2/pio_*
examples that I have hardware to validate:
examples/rp2/pio_1hz.py
examples/rp2/pio_exec.py
examples/rp2/pio_pwm.py
examples/rp2/pio_uart_rx.py
All function as expected across both my PicoW and Pico2:
I don't know how to set up a scenario where I'd be able to observe the effects of having STATUS_SEL
and/or STATUS_N
set --- but since the change is just a straightforward implementation of the datasheet spec, and I've been able to test it to conclude it doesn't break existing PIO functionality, I think this is adequate.
@dpgeorge This PR is ready to rebase and merge.
Added support for FIFO trigger level.
Summary
This provides access to the bit fields that control the FIFO level used when executing
mov(x, status)
. An application may require an action to be taken when, say, three values have been written to the FIFO.Testing
None
Trade-offs and Alternatives
The current master branch does not provide access to these bit fields AFAIK.