Shop Learn
STREAMER - I beg you example ! - Page 2 — Parallax Forums

STREAMER - I beg you example !

2

Comments

  • RamonRamon Posts: 476

    Evanh, the 'a' bit is working fine. I have problem with $FFFF (that is supposed to run perpetually).

    @cgracey , Please can you check if the streamer documentation is correct/accurate/complete? Could it be improved to include a step by step guide for idiots like me?

    By setting the D[15:0] count to its maximal value of $FFFF, a streamer command will run perpetually.

    I am testing with the following code, and the streamer stops after the initial command.

    CON
      _clkfreq = 4_000_000
      DOWNLOAD_BAUD = 115_200
      rx_pin   = 63
      tx_pin   = 62
      baud     = 115_200
    
      OUTPIN   = 36
    
    OBJ
      ser: "spin/SmartSerial"
    
    PUB main() | md, i
    
      ser.start(rx_pin, tx_pin, 0, baud)
      md := %0100_0000_1<<23 + OUTPIN<<17  + $FFFF  'streamer mode: imm 32x1, 32 bits, run perpetually
      ser.printf("md: %x The streamer is supposed to run perpetually\n", md)
      org
            setxfrq ##3216                       'streamer freq: 3 Hz
            drvl    #OUTPIN                      'pin = output, low
            xinit   md, ##%1010_1010_1010_1010_1010_1010_1010_1010  ' It starts sending '0', ... and send '1' last
      end
      waitms(9000)
      ser.printf("But it is not runnning perpetually!\n", md)
      '
      md := %0100_0000_1<<23 + OUTPIN<<17  + 1<<16 + $FFFF  'streamer mode: imm 32x1, 32 bits, set bit 'a' (bit-16) to reverse MSB, run perpetually
      ser.printf("md: %x The streamer is supposed to run perpetually in reverse order\n", md)
      org
            setxfrq ##3216                       'streamer freq: 3 Hz
            drvl    #OUTPIN                      'pin = output, low
            xinit   md, ##%1010_1010_1010_1010_1010_1010_1010_1010  ' It should start sending '1', ... and send '0' last
      end
      repeat
        org
           nop
        end
    
  • How do you know it has stopped. Could it be that it has run out of data and is just sending 0's? Does it stop after 32 bits?

    Mike

  • RamonRamon Posts: 476

    It's very easy to know if it has stopped or not. The frequency is set to 3 Hz, so I am staring my eyes to an LED on pin 36 :smile:

    If you have the opportunity to run the example code you can see how the first xinit sends the bits from right to left, and stops on a 'HIGH' (rightmost '1' bit near ##%1010 .....). So the led keeps turned ON, only during the 9 seconds delay I have hardcoded
    before it starts the second XINIT. (waitms(9000))

    The second XINIT has the 'a' bit set (bit 16) and then it starts sending a one (HIGH) reading the bits in the same order as an english reader will read the code (##%1010_ ... and _1010 last). So in the last bit will turn the led OFF.

    I don't need to feed more data as the whole purpose of $FFFF in D(15:0) bits is to just to run perpetually. Or did I misread the docs?

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-03-29 16:21

    @Ramon said:
    I don't need to feed more data as the whole purpose of $FFFF in D(15:0) bits is to just to run perpetually. Or did I misread the docs?

    If you don't keep feeding the streamer with data in immediate mode the last value will be output perpetually (after the previous ones).

    Immediate -> Pins/DACs

    S/# supplies 32 bits of data which form a set of 1/2/4/8/16-bit values that are shifted by 1/2/4/8/16/32 bits on each subsequent NCO rollover, with the last value repeating. Each value is output in sequence.

  • RamonRamon Posts: 476

    So confusing. We are talking about the streamer. (what is that? something that sends a stream of bits??).

    My mother tongue is not English, but I would have not chosen 'Run perpetually' and just I would said instead that "It will latch the pin(s) to the last value(s) sent."

    That said, now please test the following code and tell me what you see.

    CON
      _clkfreq = 4_000_000
      DOWNLOAD_BAUD = 115_200
    
      OUTPIN   = 36
    
    PUB main() | md, i
    
      md := %0100_0000_1<<23 + OUTPIN<<17 + %1<<16 + $FFFF  'streamer mode: imm 32x1, 32 bits, a-bit set, run perpetually
      org
            setxfrq ##3216                       'streamer freq: 3 Hz
            drvl    #OUTPIN                      'pin = output, low
            xinit   md, ##%1010_1010_1010_1010_1010_1010_1010_1011  ' It starts sending '1010', ... and send '1011' last ... and 'Run perpetually'
      end
      repeat
        org
           nop
        end
    
    
  • TonyB_TonyB_ Posts: 1,720
    edited 2021-03-31 15:24

    In your examples the streamer will output the last bit perpetually after the earlier 31 bits. It is running perpetually but you give it only enough data for 32 bits. To repeat the 32-bit pattern perpetually you can do one of two things:

    1. Give the streamer an immediate data long before the end of every 32-bit time period, e.g. using XCONT.
    2. Use RDFAST -> Pins/DACs mode. Write 16 identical longs to hub RAM, say to address ptra, then do RDFAST #1,ptra before XINIT to output the block of 16 longs / 64 bytes / 512 bits perpetually. However you will not be able to use the FIFO for anything else while the streamer is running a RDFAST mode.

  • Cluso99Cluso99 Posts: 17,739

    perpetually = continuously = repeats without limit

  • RamonRamon Posts: 476

    @TonyB_ said:
    In your examples the streamer will output the last bit perpetually after the earlier 31 bits. It is running perpetually

    Have you run the code?

    Please, can you test it? You can try it without a-bit set, and with a-bit set (as above code).

    md := %0100_0000_1<<23 + OUTPIN<<17 + %1<<16 + $FFFF
    md := %0100_0000_1<<23 + OUTPIN<<17          + $FFFF
    

    What do you see?

  • RamonRamon Posts: 476

    Complete test code :

    CON
      _clkfreq = 4_000_000
      DOWNLOAD_BAUD = 115_200
    
      OUTPIN   = 36
    
    PUB main() | md, i
    
      ' SEND stream without a-bit SET and run perpetually (until the 9 second wait)
      md := %0100_0000_1<<23 + OUTPIN<<17 + $FFFF  'streamer mode: imm 32x1, 32 bits, run perpetually
      org
            setxfrq ##3216                       'streamer freq: 3 Hz
            drvl    #OUTPIN                      'pin = output, low
            xinit   md, ##%1010_1010_1010_1010_1010_1010_1010_1011  ' It starts sending '1101', ... and send '0101' last ... and 'Run perpetually'
      end
      waitms(9000)
    
      ' SEND stream now with the a-bit SET and run perpetually (or not?)
      md := %0100_0000_1<<23 + OUTPIN<<17 + %1<<16 + $FFFF  'streamer mode: imm 32x1, 32 bits, a-bit set, run perpetually
      org
            setxfrq ##3216                       'streamer freq: 3 Hz
            drvl    #OUTPIN                      'pin = output, low
            xinit   md, ##%1010_1010_1010_1010_1010_1010_1010_1011  ' It starts sending '1010', ... and send '1011' last ... and 'Run perpetually'?
      end
      repeat
        org
           nop
        end
    
  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-02 09:36

    @Ramon said:

    @TonyB_ said:
    In your examples the streamer will output the last bit perpetually after the earlier 31 bits. It is running perpetually

    Have you run the code?

    Please, can you test it? You can try it without a-bit set, and with a-bit set (as above code).

    md := %0100_0000_1<<23 + OUTPIN<<17 + %1<<16 + $FFFF
    md := %0100_0000_1<<23 + OUTPIN<<17          + $FFFF
    

    What do you see?

    I changed OUTPIN from 36 to 56 for Eval board and changed bit frequency from 6 Hz to 2 Hz with setxfrq ##1074 which makes it much easier to count the LED flashes. I also increased the wait to 18000 milliseconds.

    In "perpetual immediate mode" there is no very little XCONT buffering and a new immediate value takes effect immediately after first NCO rollover probably. Therefore a wait longer than 32 bits is necessary to see all the flashes due to the first XINIT and I have edited my previous post because point 1. was wrong.

  • pik33pik33 Posts: 1,019
    edited 2021-03-31 18:36

    I use imm->LUT in my video driver (nostalgic, usable beta, and displaylisted, in constuction - displaylist works and it is fun :) to have text line upside down , zoomed, or interleaved by blank or color lines)

    While doing this I learned, that If the streamer don't get its data on time, it outputs the last bit. In HDMI mode it means instant picture loss.

    You have to feed it continuously either as I did, by a timed loop, or via interrupts.

    It is important that the streamer gets its LUT data when it needs it, and not when xcont is executed, so you may execute xcont, and after this update the LUT with new values while the previous xcont is still working, I thought it reads LUT at the time it is executed and I didn't understand why my colors are shifted.

    Better not use the same LUT entries for every xcont if you want to change their value in the real time,.or miracles happen (colors not at the places where they are supposed to be). I use 2 LUT banks separated by 32 longs (the least possible amount) and update them while they are not used for displaying pixels..

  • evanhevanh Posts: 10,954

    @pik33 said:
    It is important that the streamer gets its LUT data when it needs it, and not when xcont is executed, so you may execute xcont, and after this update the LUT with new values while the previous xcont is still working, I thought it reads LUT at the time it is executed and I didn't understand why my colors are shifted.

    Yes, the timing is deceptive. Both in the streamer command buffer delaying the start of a particular command until the prior one is completed, and also in the pacing of the active command.

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-02 09:41

    @evanh said:

    @pik33 said:
    It is important that the streamer gets its LUT data when it needs it, and not when xcont is executed, so you may execute xcont, and after this update the LUT with new values while the previous xcont is still working, I thought it reads LUT at the time it is executed and I didn't understand why my colors are shifted.

    Yes, the timing is deceptive. Both in the streamer command buffer delaying the start of a particular command until the prior one is completed, and also in the pacing of the active command.

    The current discussion is mainly about "perpetual immediate mode" which has little or no command buffering.

    Try this prog which flashes an LED. 4th stream is repeated after 1st, 2nd & 3rd.

  • RamonRamon Posts: 476
    Without a-bit:
    31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
    
    With a-bit:
    7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
    

    I am re-reading the docs again "Modes which shift data use bits bottom-first, by default. Some of these modes have the %a bit in D[16] to reorder the data sequence within the individual bytes to top-first when %a = 1."

    Several things doesn't make any sense (what was the purpose? I have no idea):

    • Repeat means : that the last bit is latched instead of repeating the stream (and good luck finding which one is the last bit when you set the a-bit)
    • %a bit reversal means that you reverse each one of the four bytes, instead of reversing the whole 32 bit stream.
  • cgraceycgracey Posts: 13,588

    @Ramon said:

    Without a-bit:
    31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
    
    With a-bit:
    7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
    

    I am re-reading the docs again "Modes which shift data use bits bottom-first, by default. Some of these modes have the %a bit in D[16] to reorder the data sequence within the individual bytes to top-first when %a = 1."

    Several things doesn't make any sense (what was the purpose? I have no idea):

    - Repeat means : that the last bit is latched instead of repeating the stream (and good luck finding which one is the last bit when you set the a-bit)
    - %a bit reversal means that you reverse each one of the four bytes, instead of reversing the whole 32 bit stream.

    It's not the always the last bit that is repeated, but whatever the last datum is, which could be 1, 2, 4, 8, 16, or 32 bits.

    The %a reorders data within each byte. It doesn't reorder the bytes. It's just for sub-byte data. For nibbles, it swaps the nibbles. For two-bit data, it reorders them from top to bottom of the byte. For one-bit data, it reverses all the bits.

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-02 09:41

    deleted

  • evanhevanh Posts: 10,954

    @cgracey said:
    The %a reorders data within each byte. It doesn't reorder the bytes. It's just for sub-byte data. For nibbles, it swaps the nibbles. For two-bit data, it reorders them from top to bottom of the byte. For one-bit data, it reverses all the bits.

    My attempt to get immediate streamer mode to do that didn't have any affect. The bit order didn't change at all. I tried as 32 x 1-bit, and as 16 x 2-bit.

    Of note is these "immediate" modes aren't "byte" based. Is that a factor?

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-01 19:57

    deleted

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-01 19:57

    deleted

  • evanhevanh Posts: 10,954
    edited 2021-04-01 18:47

    @TonyB_ said:
    The current discussion is mainly about "perpetual immediate mode" which has no command buffering.

    The command buffer is always there. But obviously, when those commands run out then any fresh command will be actioned much quicker. Presumably on the next NCO trigger for XCONT.

  • TonyB_TonyB_ Posts: 1,720

    @evanh said:

    @cgracey said:
    The %a reorders data within each byte. It doesn't reorder the bytes. It's just for sub-byte data. For nibbles, it swaps the nibbles. For two-bit data, it reorders them from top to bottom of the byte. For one-bit data, it reverses all the bits.

    My attempt to get immediate streamer mode to do that didn't have any affect. The bit order didn't change at all. I tried as 32 x 1-bit, and as 16 x 2-bit.

    Of note is these "immediate" modes aren't "byte" based. Is that a factor?

    Evan, setting %a does work in immediate mode, try my stream1.spin2 program.

  • evanhevanh Posts: 10,954

    @TonyB_ said:
    Try this prog and count the flashes (frequency should be 1 Hz). 4th stream of 15 flashes is repeated after 1st, 2nd & 3rd. What do you see?

    I haven't yet. As a quick read, I'm guessing the very first $FFFF length is holding the first command in action indefinitely. All the others never run.

  • TonyB_TonyB_ Posts: 1,720

    @evanh said:

    @TonyB_ said:
    Try this prog and count the flashes (frequency should be 1 Hz). 4th stream of 15 flashes is repeated after 1st, 2nd & 3rd. What do you see?

    I haven't yet. As a quick read, I'm guessing the very first $FFFF length is holding the first command in action indefinitely. All the others never run.

    Evan, you'll need to edit at least two posts once you have tried the prog.

  • evanhevanh Posts: 10,954
    edited 2021-04-01 19:37

    Lol, I'll leave the posts there. Amusingly, I've got the "a" bit working now in my old program. Dunno what I'd done wrong last time. Maybe was too tired and not remembering the polarity correctly.

    EDIT: Ah-ha! Got it! I'd got side tracked on trying to identify whether "a" meant word-order or bit-order and then forgot I'd not answered the question before then assuming it was bit-order, when it isn't, and then proceeding to not find the reordering I expected. So, yes, I was still too tired.

  • evanhevanh Posts: 10,954
    edited 2021-04-01 20:07

    Another ah-ha, also found out why we're not agreeing on the immediate mode command buffer too. The length of $ffff is special not just in perpetuity, it also seems to be like an XINIT in that the command it's attached to takes immediate effect.

    This may affect all modes! I haven't tested.

    EDIT: Tony, presumably this one will be the root of any lingering questions you've got with your test code as well.

  • TonyB_TonyB_ Posts: 1,720
    edited 2021-04-02 09:43

    @evanh said:
    Another ah-ha, also found out why we're not agreeing on the immediate mode command buffer too. The length of $ffff is special not just in perpetuity, it also seems to be like an XINIT in that the command it's attached to takes immediate effect.

    This may affect all modes! I haven't tested.

    From my testing of perpetual modes, XINIT takes effect immediately and XCONT takes effect after next NCO rollover.

  • evanhevanh Posts: 10,954
    edited 2021-04-01 20:13

    Well, without any control on the data sequence other than the waitx's, it's going to be overlapping in weird ways. First thing I'd do is replace all the $FFFF's with something sensible.

  • evanhevanh Posts: 10,954
    edited 2021-04-01 21:18

    @TonyB_ said:
    From my testing of perpetual modes, XINIT takes effect immediately and XCONT takes effect after next NCO rollover.

    XCONT, and XZERO, is supposed to take effect at the end of the sequence count of prior command.

    EDIT: Oh, of course, having said it out loud ... It isn't the newly issued $ffff that induces the immediate effect, it's the prior $ffff.

    EDIT2: It is even documented in the hardware doc, albeit a little buried:

    ... if the prior command used $FFFF for its initial count, ..., a new XZERO/XCONT command will only wait for the next NCO rollover, ...

  • evanhevanh Posts: 10,954
    edited 2021-04-02 00:40

    Here's the existing documentation regarding the "a" mode bit:

    Modes which shift data use bits bottom-first, by default. Some of these modes have the %a bit in D[16] to reorder the data sequence within the individual bytes to top-first when %a = 1.

    Here's a suggested addition to flesh it out with an example sequence:

    eg:  Shifting out %1000_1100_1110_1111_0111_0011_0001_0000 in 4-bit elements:
    
      Step | D3  D2  D1  D0       ( "a" mode bit set, big-endian )
    -------+-----------------     ( Streamer mode:  %0110 dddd eppp p101 )
        1  |  1   0   0   0
        2  |  1   1   0   0
        3  |  1   1   1   0
        4  |  1   1   1   1
        5  |  0   1   1   1
        6  |  0   0   1   1
        7  |  0   0   0   1
        8  |  0   0   0   0
    
      Step | D3  D2  D1  D0       ( "a" mode bit clear, little-endian )
    -------+-----------------     ( Streamer mode:  %0110 dddd eppp p100 )
        1  |  0   0   0   0
        2  |  0   0   0   1
        3  |  0   0   1   1
        4  |  0   1   1   1
        5  |  1   1   1   1
        6  |  1   1   1   0
        7  |  1   1   0   0
        8  |  1   0   0   0
    
  • evanhevanh Posts: 10,954
    edited 2021-04-02 00:43

    Lol, the colour coding in the code box is weird. Almost random seemingly.

Sign In or Register to comment.