Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 4777

SDK • Re: How to disable all interrupts and freezes on core1?

$
0
0
Can you share the code for the core 1 loop?
I thought a lot about PIO machines but I didn't think it would be quite fast enough, and tricky with the bit shifting required. Here is the code with everything but the essentials stripped out for testing.

Code:

unsigned char rom[4096] = { 0 };const unsigned char rom64[4096] = { CHAR_ROM };void core1_entry() {__asm volatile ("cpsid i"); // Disable all interupts on core1bus_ctrl_hw->priority = BUSCTRL_BUS_PRIORITY_PROC1_BITS;rom_create_64(); // Copy character set into modifiable RAM.    while (true) {        while (gpio_get(CS_IN) == 0) // Wait for the enable signal.             ;        if (gpio_get(CS_IN) == 1)  // A second check to eliminate triggering on transitory 5ns noise spikes.            gpio_put_all( rom[(~gpio_get_all()) & 0b111111111111] << D0 );  // Put the data on the bus and enable the buffer outputs        while (gpio_get(CS_IN) == 1) // Wait for the VIC to let go of the ROM                ;        gpio_put(OE_OUT, 1); // Put the output data buffers back into tri-state            }}
If I understand how things on the 2040 work, when core1 starts up it accesses the flash to copy the const array from flash into RAM but shouldn't need to access it after. Is there any way to tell? Or do my directives force everything into ram, period?

Now I do communicate between processes by writing to shared variables. It's a quick and dirty method but I assumed it would be less likely to hang than using a FIFO. The big shared variable is the rom array which core0 writes to and modified as core1 is reading from it. If both cores try to access the same memory even if one is just reading, will this cause a stall? Do DMA transfers?

I'm running at 250MHz which seems to be the fastest you can go before you lose access to flash.
I don't know if there's a cleaner way to force code into SCRATCH_X with the SDK; I use:
I'll try that, thanks. Give me a moment.

Ok! The SCRATCH_X definition seems to have done the trick. I've been testing for a while now, connecting and disconnecting the USB and sending lots of data back and forth over the USB. Not a single crash, and all it takes is the Pico to hold the bus too long ONE time to corrupt an instruction the CPU is loading. I'm surprised how stable this is.

Thanks again for the help. The 2040 is really such a nice bit of hardware. I've never had this much luck in getting stuff to actually work before. :)

Statistics: Posted by iansmith6 — Sun Apr 21, 2024 12:21 am



Viewing all articles
Browse latest Browse all 4777

Trending Articles