I thought I was doing OK with the Hazard3 (risc-v) side, and indeed I got the on-board LED to flash as required.
However, as soon as I tried to get interrupts working, things went from bad to worse; I can now only get the clock to run at the crystal frequency (12 MHz) no matter how much I try to mimic the code in the SDK. And, if I do manage to get the program running, I’m as like as not to get an interrupt 14 (USBCTRL) which I haven’t started. I suspect it’s to do with the on-board debug feature; setting up the USB clock crashes the RPi jtag adaptor.
1 Like
Hiii, any news in this front? I got myself a rpi 2350 and with ANN: Configurable bareboard runtimes v15.2.0 we already have the runtime. What would be missing in the HAL 
Best regards,
Fer
A lot of the rp2040_hal drivers (UART, SPI, I2C, PIO, ADC) should work on RP2350 with peripherals instantiated at the right memory addresses.
In this this PR I suggested that I want rp2040_hal to move towards a compatibility breaking 3.x version that drops all of the startup and clock code in lieu of a dependency on @damaki’s embedded runtimes.
I’ve been using the TI MSPM0 chips for my recent projects, so I haven’t started on that work yet, but all of the pieces are in place. Mostly what’s needed is deleting a lot of code and changing all of the interrupt and timer driven things to use Ada’s aspects and delay statements.
As for the WiFi support, I saw @Max made some progress on that over here though I’m not sure how complete it is.
I don’t think anyone is working on the RISC-V cores at the moment. I had a go at building a library compatible with both ARM and Hazard3 cores, but it’s a lot of extra work for what I see as minimal benefit.
Ok, I spent a couple hours gutting rp2040_hal. I’ve got all of the tests running on the embedded_rp2040 runtime. The only failing test is PWM interrupts, which are not firing on WRAP for some reason.
I’ve started porting to RP2350, but it’s going to require significant refactoring of RP.Clock, RP.GPIO, RP.Timer, and RP.Flash as the underlying hardware is different.
My progress so far is on the rp2040_hal 3.x branch.
4 Likes
Took a quick look at your branch and I think the issue is that your Interrupts protected object is missing a priority in the Interrupt_Priority range. The default priority is just System.Priority'Last, which is not in the Interrupt_Priority range.
Try changing your Interrupts declaration in your test to this:
protected Interrupts
with Interrupt_Priority => System.Interrupt_Priority'First
is
...
1 Like