Hi all

I am trying to build a custom USB HAL device for my rp-pico device. When I try using the pico_usb_twitchy_mouse example, I can see the USB device through lsusb, but using hidviz I am unable to see any HID devices.

For reference

• My host machine is an M1 based Mac
• I am using probe-run

output from lsusb is:

Bus 002 Device 005: ID 16c0:27da 16c0 Twitchy Mousey  Serial: TEST

Regards Matt

Rebased #209 onto current trunk. Updated to embedded-dma 0.2

Current plan is to drop everything except for SingleChannel, since I think that should end up being simpler and more flexible than the current approach. To get bidirectional functionality from SingleChannel, will need to update peripherals to provide TX/RX endpoints so that the user can have 2 channels targeting the same peripheral for reading/writing. For double-buffering I was thinking to pass the second DMA channel as an Option to the constructor, so the same interface is used regardless of single-shot/double buffering.

Will probably rename SingleChannel to Channel or Transfer or something to match the above changes.

EDIT: After splitting it up, it looks like it already resembles the above somewhat so this might only require minor changes

Other goals:

• support transfer widths other than 32bit for peripherals
• address concerns with current interface raised in #13 and #209

Provide definition for BOOT2 inside of each BSP hidden behind the boot2 feature flag, and make boot2 a default feature of the BSPs This moves

#[cfg(feature = "boot2")]
#[link_section = ".boot2"]
#[used]
pub static BOOT2: [u8; 256] = rp2040_boot2::BOOT_LOADER_W25Q080;

from the BSP examples into the BSP library. Users of the BSP then have one less thing to paste/change in their own code.

While I was already changing this code I also updated the HAL and all BSP crates to use the latest git commit for rp2040-boot2.

Closes #145

Might be worth merging https://github.com/rp-rs/rp2040-boot2-rs/pull/11 first, then doing a release of rp2040-boot2. After updating to use the crates.io version of rp2040-boot2 we could also deal with #92 in this PR.

Rationale

The current PIO API has a number of limitations:

• As the state machines are contained in PIO, they cannot be moved around individually. Sometimes, a single PIO block implements multiple functions that are used in completely different parts of the code base.
• StateMachine is not Send, although it could be.
• Multiple state machines should be able to share code to reduce instruction space usage, yet currently they are not because PIOBuilder always allocates space. Sometimes, multiple state machines implement the same functionality (e.g., multiple SPI or I2C buses).
• Some functions must only be called in specific configurations. For example, pin directions have to be set while the state machine is stopped, as PINCTRL is modified. The current API does not reflect such restrictions, which makes it harder to use than necessary.

Also, during my work, I found a bug where used instruction space was not marked properly.

This PR also fixes #141 by providing a function to set pin directions.

Design

This PR uses different types to represent state machines in different states - UninitStateMachine<P> is not associated with any program, whereas StateMachine<P, Stopped> and StateMachine<P, Running> are. Program installation in instruction memory is separated from state machine initialization via InstalledProgram and PIO::install(). Access from state machines to shared registers is performed via atomic operations to enable Send.

Old usage example:

let pio = rp2040_hal::pio::PIO::new(pac.PIO0, &mut pac.RESETS);
let sm = &pio.state_machines()[0];
let div = 0f32; // as slow as possible (0 is interpreted as 65536)
rp2040_hal::pio::PIOBuilder::default()
    .with_program(&program)
    .set_pins(led_pin_id, 1)
    .clock_divisor(div)
    .build(&pio, sm)
    .unwrap();

New usage example:

let (mut pio, sm0, _, _, _) = pac.PIO0.split(&mut pac.RESETS);
let installed = pio.install(&program).unwrap();
let div = 0f32; // as slow as possible (0 is interpreted as 65536)
let sm = rp2040_hal::pio::PIOBuilder::from_program(installed)
    .set_pins(led_pin_id, 1)
    .clock_divisor(div)
    .build(sm0);
sm.start();

Testing

I tested that the blink examples work, and I tested with my own code that, however, does not use much more PIO functionality yet (except for sideset pins). Those programs work fine.

When using RTIC, if one wants to be able to schedule a software task (eg taskname::spawn_after(duration)) it is necessary to bind the TIMER peripheral to the monotonic: let mono = Rp2040Monotonic::new(c.device.TIMER);. This makes the Timer peripheral and its four hardware Alarm interrupts unavailable.

It would be useful to have Timer/Alarm hardware interrupts and scheduled software tasks available simultaneously. For example, to set key timing cycles using low overhead HW interrupts, and schedule SW tasks relative to them.

Perhaps deriving the monotonic from SYSTICK rather then TIMER would work.

Because this is broken in the current version of usb-device, we need to gate this until the upstream fix is published in a version.

Note:

I didn't get to test it yet. It'd be greatly appreciated if reviewer could build one of the example and confirm that it is broken without the gate (you'll need to make the usb host suspend the link, typically by putting a laptop host into sleep/suspend).

Implement critical section's custom-impl trait based (heavily) on examples and feedback from dirbaio and jannic.

Interrupts are disabled before acquiring the spinlock to ensure that an interrupt on the same core does not deadlock. The interrupt-enable on failure to acquire the lock ensures that interrupts still have a chance to fire on the same core if main() is blocked on the critical-section. Performance for this implementation is not expected to be great.

This assumes that spinlock31 is reserved exclusively for this purpose.

This should not be merged before https://github.com/rp-rs/rp2040-pac/pull/39 to avoid churn.

Definitely squash when you do perform the merge, we don't need the history from this branch.

Add support for PIO hardware. This PR is based on #9 and implements most of the missing features, including interrupts.

This PR depends on pio-rs#3.

Closes #5.

This is important to get the full power of the RP2040. However, there's a major issue, which is that symmetric multiprocessing is explicitly unsound in embedded Rust.

Does the bootrom table lookup code work? It's just that according to Datasheet section 2.8.3, the Bootrom stores the table addresses as 16-bit values - these need to be read as 16-bit values, then expanded to 32-bit, then converted to the appropriate pointer. I suspect the code as written will read 32-bits from the bootrom, and get thus get the pointer very wrong.

While looking at the code generated by https://github.com/rp-rs/rp-hal/pull/288, I wondered why there were references to 64bit division code (compiler_builtins::int::specialized_div_rem::u64_div_rem) for a basically empty firmware.

Turned out that init_clocks_and_plls() contained 64bit integer divisions.

As the code to do those divisions takes about 1kB even in fully optimized builds, I changed the clock calculation code to use 32bit divisions, instead.

To keep the code small, I accepted some minimal additional rounding error: In case the remainder of the division is bigger than 2^24, the lower 8 bits will be thrown away, causing a relative rounding error of at most 2^-16. (To be exact, instead of the expected rounding-down of normal integer division, the value might get rounded up, instead. The resulting difference from the true value might be even smaller than before.)

I am not sure that the functionality of configuring the peripheral as a slave exists yet, and I think this is an important feature. If so, please let me know if this can be done with my own pull request, or if this will be implemented later.

I'm trying to get started with running rust on my newly purchased rpi pico w ( with wifi support ). Initially when I set everything up and run the blinky example, it did not work. I then ran the micro python example and the led was working. For the w version the rpi community says that there is a slight change in the way onboard led is configured

Link to the thread https://forums.raspberrypi.com/viewtopic.php?t=336836

Is there any change that must be made in the rust blinky example to get it working?

We had to update our version of critical_section, since critical_section 0.2.0 will silently break when mixed with critical_section 1.0. If you see the above error message, you need to update your dependency to rp2040-hal v0.6.1 (or downgrade to an older version of the HAL) Sorry for any inconvenience!

Full error for anyone who needs more context:

 Compiling rp2040-hal v0.6.0 (/home/nine/vc/rust/rp2040/rphal-update/rp2040-hal)
error[E0428]: the name `_critical_section_1_0_acquire` is defined multiple times
 --> rp2040-hal/src/critical_section_impl.rs:5:1
  |
5 | critical_section_0_2::custom_impl!(RpSpinlockCs);
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `_critical_section_1_0_acquire` redefined here
6 | #[cfg(feature = "critical-section-impl")]
7 | critical_section::set_impl!(RpSpinlockCs);
  | ----------------------------------------- previous definition of the value `_critical_section_1_0_acquire` here
  |
  = note: `_critical_section_1_0_acquire` must be defined only once in the value namespace of this module
  = note: this error originates in the macro `critical_section_0_2::custom_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

Please comment or emote on this issue if you've hit this problem so we have an idea of how many people are affected. Also: feel free to ask if you don't know how to resolve this.

As the dual core paradigm is one of the key features of the Pico / 2040, Rust support would need to allow for async fn to be executed in parallel without introducing an operation system in the project but by simply distributing the tasks to the two cores with the "executer". Is there already anything planned with such a goal ? Thanks a lot for listening, -Michael

Just a simple PoC showing that the existing I2C struct is flexible enough to be extended with a variant that doesn't own SCL/SDA pins. That way, it would be easy to use I2C with DynPins.

For now I only tested that this still builds. And the function naming needs to be improved. (Also, lots of unnecessary code duplication in controller.rs)

@cr1901: Would that, in combination with #482, solve #481?