I have done one PIO program where I keep two 16-bit constants in the same register - which would normally use up a lot of instructions to split them apart; I actually ended up with some very hairy code with registers having half constant and half data (so doing JMP X!=Y where X contains two constants and Y contains a duplicate copy of X in the top half and the data we are actually testing in the bottom half). It worked well, but it was hard work.Here I am using ISR and X for storing delay cycles. But this is just an experiment, I still need to store the VSYNC back porch cycle, does this mean I have exhausted the available registers.
However, for video out work like you are doing here (with 8 bits of useful data in each value written to the FIFO) I've usually had the CPU write 32-bit values - which can either be just 8-bit values for output (with the high bits zero), or else various special values with flags and sync state in the high bits and (for example) porch length values in the low bits. PIO is quite good at splitting apart values like this - OUT X,1 to get a 1-bit flag into X where you can test it. It costs nothing to have the ARM write 32 bits rather than 8, and you don't have to use all 8: if you want (say) 8 bits of data plus two flags you can set the autopull counter to 10.
Only snag with this compare to your approach is that I have to keep the FIFO continually supplied with data or else the output stalls. Combining the FIFOs for 8-deep output helps. It's also maybe better to have the clock generated by side-set on the main program rather than a separate SM - requires lots of careful cycle counting on all the different branches of the program, but just tedious rather than difficult, and means it should recover after a stall rather than being game-over with the two SM approach.
Statistics: Posted by arg001 — Mon Apr 08, 2024 9:18 am