I'm interested in the RP2040, coming from a STM/Nordic background. The things I want to do are:
- Program it using my familiar workflow: ARM single wire debug (SWD).
- Use the embedded rust crates for creating a program entry and setting up the interrupt table (
- Be able to take advantage of all the hardware functionality (especially with respect to timing).
The Raspberry Pi Pico is 2 Cortex-M0 ARM cores on a chip, with a modest selection of peripherals that you might expect (including UART, SPI, I2C, ADC, maybe some others I've forgotton). It also includes some peripherals that are (to me) more unusual: FIFOs between the two cores, spinlocks for synchronizing the cores, dividor units (since armv6 thumb instruction set doesn't have integer division), and a fixed function pipeline which is "concidentally" useful for emulating old games consoles that rely on precise timing. (The datasheet is awesome and very detailed: https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf)
There are things that it might be useful to take advantage of, but where I can't see how the code that is generated would take advantage of them. For example, the divisor unit. We are relying on our Rust code being translated into some pretty specific memory reads/writes, and we could even do in-software pipelining by doing something useful for the 8 cycles that the divisor unit takes to run. This ain't going to happen, so I expect you need to write some assembly to create a division function. In all honestly I can't see how you could use these peripherals in parallel unless you're writing ARM assembly. But the possibility is there.
Although the chip is a cortex-m0, which is very basic, other aspects of the design are more advanced than what you would get with an equivalent device (like the Blue Pill, which has a Cortex-M3 which includes an instruction for integer division, I think).
What I'd like is the ability to translate Rust into sensible machine code. This would mean using the hardware division, rather than a software implementation which I'm sure would take more than 8 cycles! Other than that, I'm not sure what else needs to be done apart from the standard ARM codegen. I'd also like a board crate with the memory mapped IO registers given names. (On the Pico every peripheral register has 3 memory registers: one for set, one for clear, and one for flip (xor), which are there to avoid read-modify-write patterns with single instructions in the simple case.)
What are other people's thoughts on this hardware? I, for one, am excited about having a bit more diversity in ARM SoC design. I'd like to see bluetooth, and also a smaller circuit board version that you could put in e.g. a 3D printed smartwatch with a little battery. I also like the large amount of memory, which would fit a small-ish framebuffer, for example 16bit color (e.g. RGB565) on a ST7789 display (240x240 pixels) would fill 112.5kB, which is more than the PineTime's total RAM (64kB).