Shop OBEX P1 Docs P2 Docs Learn Events
Difficult question about Streamer — Parallax Forums

Difficult question about Streamer

Hello all!

I think I'm going to pose a question that might be difficult to answer considering I'm a newbie. I would like to know if there is a conceptual explanation of what a Streamer is and what the use cases for using it could be.

My project reads 4096 longs from hub into a cog running a process on 8 of them at a time cyclically. I wonder if instead of plainly reading them using RDLONG, I should consider using the Streamer

  .t_loop
        SETQ #8-1
        RDLONG source,source_offset

       { some processing here }

        JMP #.t_loop  

I've been perusing the documents but I cannot grasp the concept well enough to determine if it might be a fit for my case. Any help would be appreciated.

Comments

  • What it sounds like you want is the FIFO.

            RDFAST #256,source_offset   ' 256 blocks of 64 bytes = 4096 longs
      .t_loop
            RFLONG source
    
           { some processing here }
    
            JMP #.t_loop  
    

    Is it a good idea? Depends on your code. If you want to process 1 long at a time, RFLONG will make that easier by writing the incoming data in the same register every time.

    If your code can naturally process the blocks of 8 longs, then maybe stick with the block read.

    Actually, using the FIFO might be slightly faster.
    8x RFLONG will take 16 clocks.
    RDLONG will take 9-16 clocks, plus 7 clocks for the extra longs.

    The minimum clock count for RDLONG is higher that I expected.

  • @jrullan I tend to think of the streamer as a DMA engine for the P2 which can be setup to operate in the background that can move data from HUB RAM to pins/DACs or from pins/ADCs to HUB RAM. In the outgoing direction towards pins it can optionally also perform a translation operation using the LUT RAM.

    As far as use cases it could be used for many things including, but not limited to applications such as :

    • generating video output (the LUT RAM stage can be useful for optional palette lookups - eg. 8 bit index to 24 bit RGB)
    • serial data transfers such as (Quad/Dual)SPI or other clocked serial interfaces such as I2S
    • data transfers to and from external memory devices such as PSRAM or HyperRAM
    • streaming data out to internal DACs, or to external DACs with parallel data output
    • sampling pin data (eg. performing a logic analyzer function or oscilloscope with ADC data from pins)

    The streamer operates at some programmed "XFRQ" rate according to what is configured with the SETXFRQ instruction and the commands issued to the streamer setup the pins, data widths, transferred quantities and the data format endianess and also select LUT address table addresses. The RDFAST and WRFAST instructions setup the HUB memory sources and sink addresses for the streamer (DMA) transfers. The FIFO is also used to smooth out the accesses and keep things flowing smoothly to avoid data drop outs. The streamer instructions can be modified on the fly during the actual transfers and this allows multiple interface protocols to be implemented. It's very versatile.

  • evanhevanh Posts: 16,032
    edited 2022-10-12 06:28

    Each Cog has both one dedicated FIFO and one dedicated Streamer attached.

    As James highlighted, the FIFO can be used by Cog instructions to efficiently read or write hubRAM bytes/shortwords/longwords.

    For the larger block copies between cogRAM and hubRAM your first posted solution, SETQ+RDLONG/WRLONG, is the fastest raw copy. FIFO is not used for this.

    Streamer performs block I/O transfers to/from hubRAM via the FIFO. It operates concurrently to the Cog. You set it up with the desired I/O pacing and it'll go do that while the Cog continues. Effectively a DMA channel, as Roger said.

    PS: Hubexec also uses the FIFO. That's three ways it can be used. The FIFO can only do one at a time though, so be careful about when it is used.

  • Thank you all for your comments.

    It still surprises me how this community, being so technical and specialized (in my mind you are all gurus) manages to be so newbie friendly! :blush:
    That's what motivates me to keep learning about the Propeller 2.

    It seems that from your comments for my particular application there's no reason to change my approach. Although I might later setup a testing program to check out these features of the Propeller 2.

  • @jrullan said:
    It seems that from your comments for my particular application there's no reason to change my approach.

    Agreed.

  • evanhevanh Posts: 16,032

    @jrullan said:
    It still surprises me how this community, being so technical and specialized (in my mind you are all gurus) manages to be so newbie friendly! :blush:

    Most of us here like it that way. It all starts with Chip's own devotion to making the hardware understandable. Nothing is intentionally hidden. Libraries are optional.

    You can only teach understanding once it is understood. Libraries make it happen without understanding.

  • pik33pik33 Posts: 2,388

    Libraries make it happen without understanding.

    Then you have to understand these libraries which is more difficult than understanding the real hardware.

  • evanhevanh Posts: 16,032
    edited 2022-10-16 11:01

    Ha, I just realised the term "library", in it's repurposed computing form, isn't an entirely appropriate label since a real library is all about education.

    That said, library source code can be very educational. Just they are often just a binary blob without the sources. All you're given is the API and related docs.

Sign In or Register to comment.