feature request: single core version.

[mfp20]

Hi,

I see you made a little maintenance routine (core1_code) to run on core1. In comments you wrote "Most of the time this loop is stalled with wfes (wait for events)". It might be useful to leave 1 core for user to run his own application along the logic analyzer. Is it possible to move that code back to core0? What's the trade? A soft switch at runtime would be the best, but a compiler define at compile time (#define ENABLE_SINGLECORE) would be ok too.

My rp2040 is already soldered in place, inside a very tight place (inside a Quansheng UV-K5 handeld ham radio), hooked to another mcu and the other pre-existing hardware; and I need to look at the SPI bus in both directions, so I need to implement a small client on one core ...

Thanks for this awesome project. I used to keep a 2-picos breadboard for analizing signals and jtag/swd programming; now I can get rid of that tool and simplify my life.

[pico-coder]

What are you doing with the UV-K5? (On of my other distractions is ham radio).

As for the post: The simple answer is that the software based polling of PIO/DMA state, serial state etc should really be done by enabling interrupts and writing interrupt service routes.
The main motivation of all of this (and I definitely haven't reached the perfect optimized state) was to ensure that sw polling of the DMA engines was given CPU priority to ensure we sent back data as fast as possible. But, in cases where the host needs to abort an operation we have to be responsive to serial events, but we can get away with polling much less often than once per main loop.
All the wfes were added to ensure that PIO memory and CPU0 memory accesses had priority by keeping CPU1 in a sleep state most of the time.

If your use case is not on the bleeding edge of trying to get ever last bit of USB serial bandwidth, then there is no reason you can't just move the serial functions out of the core1 code and into the main checking loop for core0. Likely you can just edit the core1_code function to remove the wfes, and then call core1_code from the start of the while(1) loop in core0 (and edit the build configs to not map core1_code to core1).

[mfp20]

What are you doing with the UV-K5? (On of my other distractions is ham radio).

I'm modding the UV-5R Plus (it's the UV-K5 with blue backlight, and without USB connector). I placed an rp2040-zero in the empty usb-c spot. I don't want to cut pcb paths or disable parts of it. I'd like to be able to add on top only, keeping the mod as minimal as possible; so that public firmwares keep working despite having a better mcu on top of the default one. It's like the https://github.com/skuep/AIOC but kept inside the radio, dual core mcu, 2mb of flash, and all the rp2040 goodies...

And I'm rehauling the whole firmware to cope with that.

When your message arrived I had just resoldered the dp32g030 in place after removing the first I2C and SPI patches because they couldn't work as is. This thing is as cool as buggged in hardware. It's a miracle it can do so much. They made huge mistakes in designing the PCB, so now it is not possible to exploit the I2C (to eeprom and bk1080 commercial FM transceiver) and SPI (to the hamradio FM transceiver). In custom firmwares they are all bitbanged instead, burning cpu cycles. It's a pity, because the dp32g030 have all sort of goodies (flexible pins pad, dma, ...) and they are wasted.

If your use case is not on the bleeding edge of trying to get ever last bit of USB serial bandwidth, then there is no reason you can't just move the serial functions out of the core1 code and into the main checking loop for core0. Likely you can just edit the core1_code function to remove the wfes, and then call core1_code from the start of the while(1) loop in core0 (and edit the build configs to not map core1_code to core1).

mmm... I've already cleaned up your code and squeezed in 1 file only, but didn't give it a try yet; as I had fallen asleep fighting with tinyusb when I was working on that part...

I don't know what I need to monitor yet; currently I've just UART1 working (if you use the K1-USB dongle, you can rx/tx to both MCUs at the same time; ie: I wrote code to frame the serial data and add an address header to the frames, so I can talk to each one of the mcus sharing UART1 and the standard K1-USB dongle), and rp2040's UART0 connected to UART1 with reversed tx/rx pins so the MCUs can talk to each other (if I remove the K1-USB dongle, and use the rp2040 usb).

At the end of the day I'll have to look at I2C/SPI and maybe a couple of analog audio signals (mic and speaker). When I go back to your code I'll follow your guidelines. Thanks!

[pico-coder]

A rather late update, but just adding notes there that this is kept open not because of the core1 code per-se but because of the awful monstrosity of check_half. That relies on a cpu core polling on DMA controller fields that would better be handled with interrupts. If we had interrupts on the DMA engines that would lighten the load on cpu0 even more, and generally make things more responsive. And with that fixed up the overhead of what is in core1 code could move into core0.

[pico-coder]

I just pushed a major code release which completely rewrote how the DMA engines are managed and eliminated the core1 code.
Note that I did a new "pin test mode" which allows the GPIOs to be driven as outputs so that I can generate test patterns for debugging changes. Pin test mode does use CPU1, but if the feature is disabled then that core1 code is disabled as well.
Please have a look. I'll close this eventually based on feedback, or maybe just the passing of time...

[mfp20]

Just a quick note to thank you for the kind updates.

That project of mine stalled (ie: all bits and bolts scattered on the messy desk and me thinking "I should have placed those in a box" every single time I see one piece of the radio), but not cancelled. But I might be able to resurrect this development before next spring: I've 3 more quanshengs to hack into pieces, ahhahahahah
I'm currently working on a project that might have your code embedded as well; but it's unlikely to happen before Christmas. I'll let you know asap.

Thanks again