Skip to content

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

kc64
Copy link

@kc64 kc64 commented Mar 3, 2025

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.

Added support for FIFO trigger level.

Signed-off-by: kc64 <callan.kevin@gmail.com>
Copy link

github-actions bot commented Mar 3, 2025

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:  +112 +0.012% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@kc64
Copy link
Author

kc64 commented Mar 3, 2025

Following the pattern for shiftctrl, just after the edit. The single-line form is fine also but wanted to respect the style of the surrounding code.

@Gadgetoid
Copy link
Contributor

Gadgetoid commented Mar 5, 2025

I suspect the wrapped line below is because it hits some line length threshold, no need - afaik - to try and match that style since it's a functional choice and not a stylistic one (and also why I don't use strict code formatting).

Commit message should be something like:

rp2/rp2_pio: Add support for FIFO trigger level.

This is all a big magic-numbery for me but the datasheet - pages 329 and 377 at time of writing - seems to concur this is correct for RP2040.

It looks wrong for RP2350, though, the status_n field is four bits wide:

https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2350/hardware_structs/include/hardware/structs/pio.h#L44-L46

Instead of three:

https://github.com/raspberrypi/pico-sdk/blob/ee68c78d0afae2b69c03ae1a72bf5cc267a2d94c/src/rp2040/hardware_structs/include/hardware/structs/pio.h#L44-L46

Relevant snippet from the RP2350 datasheet:

image

Versus RP2040:

image

And the status_n field has also changed.

This code needs to handle the RP2350 case correctly. Not quite sure how to wrangle that.

In the interim anyone needing this feature can use machine.mem32[] with offsets 0x0cc, 0x0e4, 0x0fc, 0x114 (for SM0, SM1 ... etc) and base 0x50200000 or 0x50300000 for PIO0 and PIO1 respectively. Eg something like this (don't quote me 😆):

machine.mem32[0x50200000 | 0x0cc] &= ~0b1111                         # Mask out status_sel & status_n bits
machine.mem32[0x50200000 | 0x0cc] |= (status_sel << 4  | status_n)   # Set them to our desired values

RP2350 users can figure out the alternative.

@dpgeorge
Copy link
Member

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.

@kc64 kc64 changed the title Update rp2.py Update rp2.py to support FIFO trigger level Mar 13, 2025
Signed-off-by: kc64 <callan.kevin@gmail.com>
@kc64
Copy link
Author

kc64 commented Mar 13, 2025

I added support for both RP2040 and RP2350.

@kc64 kc64 changed the title Update rp2.py to support FIFO trigger level rp2/rp2_pio: Add support for FIFO trigger level. Mar 13, 2025
Signed-off-by: kc64 <callan.kevin@gmail.com>
@@ -40,7 +42,10 @@ def __init__(
from array import array

self.labels = {}
execctrl = side_pindir << 29
if 'RP2350' in sys.implementation._machine:
Copy link
Contributor

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.

Copy link
Contributor

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>
Copy link
Author

@kc64 kc64 left a 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

@kc64 kc64 requested a review from AJMansfield June 5, 2025 18:12
Copy link
Contributor

@AJMansfield AJMansfield left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy