Thanks for making me check that part again!!Are your interrupt handlers definitely running on the right CPU? Where do you initialise them - inside screen_worker() or screen_initialise()? If you initialise the interrupt handler and enable the interrupt in screen_initialise() which is running on core0, then those interrupts will happen on core0 even though the rest of the screen handling has moved to core1.
I've moved the "screen_initialize()" function so it'll run in core1
Code:
screen_worker() { screen_initialize (); while (1) {handle_screen();} } this was the issue, but for unrelated reasons. when I originally started testing this, it wasn't working.. I kept moving things around until it "worked", but the fix wasn't in the code: I had to physically reset the Pico for it to work. Every time I flash it (I'm using another pico as a debug probe and flashing it like this), I need to manually reset it. I have a cable soldered to the RUN pin, to ground it every time i flash it.
If I don't do this, the state machines work but the CPUs are in a weird state.
I forgot to move the initialization back to the core1 and this is why it broke.
The rest of this post is optional:
I'm not sure I understand. It works like this: I have two separate "line buffers". One is the "work buffer" that I update in software, and another is the "line buffer" which is the one that's sent to PIO. After the DMA transfer is started, a flag is set. This enables the worker to swap pointers. For clarification:However, if I have understood it correctly, I think your video timing generation like this is really much too fragile - you have the HSYNC accurately placed by the PIO, but then position the video relative to it by an IRQ handler starting a DMA. You really want the two PIO programs linked together such that the DMA started before the HSYNC, filled the PIO FIFO with pixels, and then the pixel PIO program starts a defined interval after the HSYNC.
One approach would be:
- make the pixel PIO program count the pixels in a line
- at the end of the line, use WAIT instruction(s) to wait for the HSYNC being generated by the other SM
- Either add some dummy blank pixels to the start of each line to cover the back porch time, or else have the PIO program insert a fixed
delay between the end of HSYNC and starting to move the pixels.
Code:
uint32_t linebuffer0[1440];uint32_t linebuffer1[1440];//in the interrupt handler: uint32_t *work_buffer = line % 2 == 1 ? linebuffer0 : linebuffer1; //in the worker: uint32_t *work_buffer = line % 2 == 1 ? linebuffer1 : linebuffer0;This way the pixel PIO is always reading the other buffer. Data is fully ready in this buffer when DMA starts. The IRQ only starts the DMA transfer, and it does so at the very beginning. Having a few padding pixels left or right would allow me to shift the video horizontally which may be useful, but it won't really change how things are done.
Is there a better way to start the DMA transfer?
Actually I'm generating characters. My line buffer is pixels, but I also have a character buffer. This is how all is tied together:You might draw some inspiration from this project, even though it's doing rather different things to what you are:
https://github.com/arg08/pico-mode7
It's doing 50Hz TV video rather than VGA video, but that's just a difference in the timing constants. It was also originally written to overlay the video on top of syncs coming in from another piece of hardware, but for testing there's an HSYNC generator in a separate PIO SM so that it ends up doing rather similar to what you need - syncs generated in one SM, and pixels in another SM watching the timing of that to accurately position the video relative to the syncs.
It's also doing character-cell video for a text display rather than the graphics you are doing, so my PIO programs aren't directly relevant to your setup, but maybe a source of inspiration.
Probably if I was doing an output-only setup I would do the syncs and the video all in one SM, bit maybe there's some merit in separating them.
Code:
//this is the part that handles the screen bufferchar display_char_buffer[80*25];char work_char_buffer[80x25];int cursor_position;keyboard_worker() { char c = readKeyboard(); //very simplified, it also handles deletes and other control stuff. work_char_buffer[cursor_position++] = c; if( line > vblank) { memcpy(work buffer to display buffer); } // this is the part that converts to pixels, synced by the HSYNC and VSYNC PIOsline_worker() {int current_char_line = screen_line %14; //14 pixel tall charactersint current_char_row = screen_line/14; // lines 0 to 13: text row 0, line 14 character 1 ... and so onfor (int column;column<80;column++ ) {int char_row = font[current_char_row + column][current_char_line]; // the font is a 2D array of 256 chars x 14 rowsadd_to_pixels(work_buffer, char_row); // this copies the pixels on a very big line. // it's a complex function since the chars are 9 pixels wide and they are // aligned to 32bit words. irrelevant to this discussion.}}Statistics: Posted by hjf — Thu Oct 24, 2024 2:33 pm