Help understanding the fundamentals with spinning up a new COG in spin2.
ke4pjw
Posts: 1,155
So looking through Jon's jm_rgbx_pixel.spin2 and I got lost for a moment trying to understand how the hubRAM VAR structure is handed off to the new COG. So in SPIN1, I recall handing off the PTR, same way it is done with ptra. We would have to populate the local COG registers using rdbyte/word/long and mov to get the VAR values to a locally named COG register. This process is expedited in jm_rgbx_pixel.spin2 by using SETQ in combination with rdlong, where it copies 10 longs, starting at the @newconnection address to the newcon register.
Should I assume that SETQ increases both the S and D address of RDLONG?
The description of SETQ in the PASM2 is very terse and is only states:
"Set Q to D. Use before RDLONG/WRLONG/WMLONG to set block transfer. Also used before MUXQ/COGINIT/QDIV/QFRAC/QROTATE/WAITxxx."
I guess that is the only way a block transfer would work, is by increasing both.
Can I also assume that the structure of the named reserved cog registers must be exactly the same order as the VARs for the copied block?
If all of these assumptions are correct, this is SO nice!
Please pardon me if this is all too obvious. I have to talk it out to "get it" sometimes.
Thanks,
Terry
var long cog ' do not modify order; this structure passed to PASM cog ' long newconnection ' new conection when != 0 long p_pixels ' pointer to active pixel buffer long npixels ' number of pixels in buffer long txpin ' active transmit pin long pixbits ' bits/pixel (24 or 32) long resetticks ' ticks in reset period long rgfix ' swap r&g? long t0h ' bit0 high time (ticks) long t1h ' bit1 high time (ticks) long cycleticks ' ticks in 1.25us
Dat Section
dat { auto-run driver }
org 0
pix_driver setq #10-1 ' get 10 longs from hub
rdlong newcon, ptra
mov t1, #0
wrlong t1, ptra ' tell hub we're connected
rgbx_main rdlong newcon, ptra wz ' check for new connection
if_nz jmp #pix_driver
mov addr, p_hub ' point to rgbbuf[0]
mov npix, pixcount ' set # active pixels
Named long reservations in the DAT section
' -------------------------------------------------------------------------------------------------- newcon res 1 ' new connection flag p_hub res 1 ' pointer to pixel buffer in use pixcount res 1 ' # pixels in buffer tx res 1 ' output pin pixelbits res 1 ' bits per pixel resettix res 1 ' frame reset timing swapflag res 1 ' if !0, swap R & G bit0hi res 1 ' bit0 high timing bit1hi res 1 ' bit1 high timing cycletix res 1 ' 1.25us cycle ticks addr res 1 ' address of current rgbw pixel npix res 1 ' # of pixels to process colorbits res 1 ' rgbw for current pixel
Comments
Yes, SETQ #N + RDLONG will read N+1 consecutive longs from hubRAM into N+1 consecutive cogRAM locations. Same for WRLONG/WMLONG. Note that it is N+1, so SETQ #0 will still read just a single long, #1 will read two longs, etc.
Also note that this only works for long-sized operations.