Something strange about the streamer doing WFWORD operations [FIXED- IGNORE]

rogloh

EDIT: Ignore this post. I just noticed the top four bits are meant to be different. My code had them the same! Not paying enough attention. Lost a day on this yesterday, funny how writing up a post makes you see things differently.

Today I learned (the hard way) that these two streamer commands:

1110 dddd wppp 1111 - 16-pin -> 4-DAC4 + WFWORD 16 in %ponmponm_lkjilkji_hgfehgfe_dcbadcba
1111 dddd wppp 0000 - 16-pin -> 2-DAC8 + WFWORD 16 in %00000000_00000000_ponmlkji_hgfedcba

behave very differently when it comes to reading the 16 pins and writing into the FIFO. I thought the two variants would only affect the DAC output format but this is not the case.

I setup a COG to send this sequence of 16 bits to output to pins and then have a second COG to read the pins (as upper 16 bits of port A) into memory using both streamer command versions.

Pattern continuously generated on port A pins (in a back to back infinite REP loop):

    long    $01000000
    long    $03020000
    long    $05040000
    long    $07060000
    long    $09080000
    long    $0b0a0000
    long    $0d0c0000
    long    $0f0e0000

The first streamer command variant format worked fine and I ended up with this sequence in memory after reading the upper 16 bits of port A 20 times.

Data read was : 
0A0B0C0D0E0F000102030405060708090A0B0C0D0E0F000102030405060708090A0B0C0D0E0F0001

The latter streamer command variant creates a very weird pattern in memory (not what I expected, and finally explained why my PSRAM memory reading code was not working properly). It also appears to runs out of data as well even though the pins are still being updated. Is this a P2 bug in the streamer or is this the intended format to write into the memory?

Data read was : 
CA0E4286CA0E4286CA0E000000000000000000000000000000000000000000000000000000000000

What is it doing here exactly and why does it run out of data?

msrobots

yes, writing it down often helps to solve the problem