[Solved] Stuck while trying to pass a buffer from spin to pasm and set rdfast to read from it.
pik33
Posts: 2,416
(First post deleted)
What I want is:
I have a buffer in Spin
byte line_buf[960]
I want to set rdfast to make a streamer to read from (first 64 bytes of) this buffer in a separate cog's PASM code
What I achieved so far is: the streamer reads something (and displays it) , but this is not my buffer.
To be continued tomorrow.
Comments
If you are wanting something like displaying a screen buffer as in VGA for example, then look at Chip's VGA example because the pasm code in cog does this without any "fluff".
This code doesn't care what the buffer is, but of course it has to manipulate it using a font. But you can use this concept for anything else. Just strip the extra blanks lines and sync code out - it's only a few lines.
Read to what? if you read to cog registers or LUT ram, you don't need the streamer. You can just use: (pass the address of the buffer as 3. parameter in coginit)
setq #64-1 rdlong cogreg, ptra setq2 #64-1 rdlong lut0, ptraOr you setup the fast read with RDFAST and then read the longs with RFLONG, but this also does not use the streamer, only the FIFO.
The streamer is only needed if you want to stream the buffer to pins or DACs with a certain frequency.
Andy
I used Chip's code for HDMI spiral as a starting point but this is pure PASM thing. I wanted to declare and fill the (small, at the beginning) buffer in Spin, and then pass its address to Pasm code, starting from 64 bytes as it is the smallest chunk available for rdfast, and then display id (as a repeating pattern) on the screen
Now it displays 64 bit pattern as expected: vertical lines on the screen. I made it 1024 pixels wide and the streamer is set to 1-bit LUT so the pattern is 2-colors and repeats twice every line (64byte=512 pixels). This works. The problem is: it is not my buffer.
Now the plan is: to make the code as simple as possible and find an error, else post all the code here if error not found.
It works now. The conclusion: dont program a Propeller late at night. I still don't know what was wrong yesterday.
This is a working piece of code:
CON hdmi_base = 48 'must be a multiple of 8 _clkfreq = 283_751_600 'system clock frequency must be 250 MHz for HDMI var long line_buf_ptr byte line_buf[64] pub test1()| iii repeat iii from 0 to 63 line_buf[iii]:=$AA line_buf_ptr:=@line_buf coginit(7,@hdmi, @line_buf_ptr) repeat iii:=iii DAT org hdmi setcmod #$100 'enable HDMI mode drvl #7<<6 + hdmi_base 'enable HDMI pins wrpin ##%001001<<8,#7<<6 + hdmi_base 'set 1k-ohm drive on HDMI pins setxfrq ##$0CCCCCCC+1 'set streamer freq to 1/10th clk (25 MHz) wrlut rgbp,#0 'set 2 colors in LUT wrlut rgbc,#1 rdlong linebuf,ptra rdfast #1,linebuf ' ' Field loop field mov hsync0,sync_000 'vsync off mov hsync1,sync_001 callpa #2,#blank 'top blanks mov ii,#480 'set visible lines line call #hsync 'do horizontal sync ' xcont m_luttest,rgbp 'do visible line djnz ii,#line 'another line? callpa #2 ,#blank 'bottom blanks mov hsync0,sync_222 'vsync on mov hsync1,sync_223 callpa #1,#blank 'vertical sync blanks jmp #field 'loop ' Subroutines blank call #hsync 'blank lines xcont m_vi,hsync0 _ret_ djnz pa,#blank hsync xcont m_bs,hsync0 'horizontal sync xzero m_sn,hsync1 _ret_ xcont m_bv,hsync0 sync_000 long %1101010100_1101010100_1101010100_10 ' sync_001 long %1101010100_1101010100_0010101011_10 ' hsync sync_222 long %0101010100_0101010100_0101010100_10 'vsync sync_223 long %0101010100_0101010100_1010101011_10 'vsync + hsync rgbp long %00000000_10000000_10000000_00000000 'background rgbc long %11111111_00000000_00000000_00000000 m_bs long $70810000 + hdmi_base<<17 + 16 'before sync m_sn long $70810000 + hdmi_base<<17 + 52 'sync m_bv long $70810000 + hdmi_base<<17 + 16 'before visible m_vi long $70810000 + hdmi_base<<17 + 1024 'visible m_luttest long $70820000 + hdmi_base<<17 + 1024 'rflong+lut ii res 1 linebuf res 1 hsync0 res 1 hsync1 res 1