• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 98 subscribers
  • Views 1095 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to create complicated pulse trains -- EHPWM versus PRUSS versus memory-bit-stream?

Walter Snafu
Genius 3450 points

I am trying to create complicated pulse train waveforms with the c6748 -- without needing a lot of cpu overhead.  My question is whether to use the Enhanced High-resolution Pulse Width Modulator (EHPWM) that comes in the c6748.  Or whether to use the Programmable Real-time Unit Sub-System (PRUSS) on the c6748.  Or perhaps something else?  Which approach would incur the least amount of cpu overhead?

Here are the specs:

My waveforms are digital, having only two values -- high or low -- and all the information is conveyed in the timing of the high/low pulses.   The waveforms go something like this.   High for 14 counts, then low for 14 counts -- Do that 9 times. Followed by high for 16 counts, then low for 16 counts -- Do that 8 times.  The "counts" are timed by an external clock that must be at a specific frequency.  (Or perhaps the "external clock" might be derived from the system clock -- if that is set at an appropriate frequency.)  There will also be slightly different versions of that waveform all in a long continuous un-interrupted stream.  I also need fairly tight control on when this pulse train starts. There should be no jitter or interrupts in this bit stream. 

I could also have this pulse train stored in memory (as a stream of one's and zero's) and then have some sub-system (which sub-system?) clock these out a GPIO port in-sequence.  That would be yet another way to accomplish my goal. 

I'm looking for ways to off-load some most this tedium away from the CPU.   What is your recommendation?

Thank you for your help.

 

  • 0
    TI__Expert 8785 points

    Walter Snafu said:
    High for 14 counts, then low for 14 counts -- Do that 9 times. Followed by high for 16 counts, then low for 16 counts -- Do that 8 times.  

    PRU would be a good option for this.  EHRPWM is not, because there will be a lot of CPU overhead to keep track of the number of iterations before doing another type of waveform (e.g. you'll need to trigger an interrupt in each period to keep track of the iteration you're performing)

    Walter Snafu said:
    here will also be slightly different versions of that waveform all in a long continuous un-interrupted stream.  I also need fairly tight control on when this pulse train starts. There should be no jitter or interrupts in this bit stream. 

    EHRPWM would be a good option with minimal CPU overhead.  You'll only need to set up the configurations once, and it'll run forever without having to service it.  Also, there is a bit in the SYSCFG0 module that can start/stop all the EHRPWM.

    Walter Snafu said:
    I could also have this pulse train stored in memory (as a stream of one's and zero's) and then have some sub-system (which sub-system?) clock these out a GPIO port in-sequence.  That would be yet another way to accomplish my goal. 

    I know EHRPWM will not be able to do this.  PRU possibly can, since it can perform memory reads. 

    --Christina

     

  • 0 in reply to clam
    TI__Guru* 84110 points

    Walter Snafu,

    Why not just use a standard serial data interface instead of making up one of your own?

  • 0 in reply to RandyP
    Genius 3450 points

    RandyP said:
      Why not just use a standard serial data interface instead of making up one of your own?

    Do you mean "standard serial data interface" as in RS-232, with the start bits, stop bits, parity bit, baud rate, etc. ???  That would totally garble the pulse stream I need to create.

    So I presume you mean something else, but I don't know about that something else.  Can you steer me toward something?

    Thanks for your help.

  • 0 in reply to Walter Snafu
    TI__Guru* 84110 points

    RandyP said:
    Why not just use a standard serial data interface instead of making up one of your own?

    I am questioning the reason for this unusual pulse stream. It seems to be a way to send binary data encoded as slightly different width & repetition pulse streams. It seems like a valid question to ask why you want to do this rather than just use one of any number of standard communication methods that already work. An RS-232 UART is one valid method for communication, but to implement a communication channel and not to implement exactly what you are asking for.

  • 0 in reply to RandyP
    TI__Guru 62975 points

    Walter,

    McBSP and McASP should have transmit modes that allow you to pack in a continuous stream of data bits.  I'm not 100% sure about SPI.

    -Tommy

  • 0 in reply to RandyP
    Genius 3450 points

    RandyP said:
    I am questioning the reason for this unusual pulse stream. It seems to be a way to send binary data encoded as slightly different width & repetition pulse streams. It seems like a valid question to ask why you want to do this rather than just use one of any number of standard communication methods that already work. An RS-232 UART is one valid method for communication, but to implement a communication channel and not to implement exactly what you are asking for.

    My communication protocol comes from a pre-established, internationally accepted, ISO Spec -- which I cannot change.  It is a long stream of pulses of precisely prescribed widths and rates.  (Indeed, Texas Instruments already sells millions of product based on this ISO Spec!)  RS-232 UART will not work. 

  • 0 in reply to tlee
    Genius 3450 points

    tlee said:
    McBSP and McASP should have transmit modes that allow you to pack in a continuous stream of data bits.  I'm not 100% sure about SPI.

    Ordinarily, McBSP and McASP transmit their data on the bus, which is otherwise chattering away with lots of other traffic.  Is there a way for the McBSP/McASP to "transmit" a bit-stream out from a GPIO pin (thereby eliminating the chatter)?

     

  • 0 in reply to Walter Snafu
    TI__Guru 62975 points

    Walter,

    For transmit, the only signals used by McBSP and McASP are data, clock, and framesync.  For transmit you could NC the framesync.

    -Tommy

  • 0 in reply to tlee
    Genius 3450 points

    I need to double-check the answer, to make sure it will work. 

    I'll explain my c6748 design goal again, more simply this time. My goal is to send out a serial bit-stream of ~40,000 bits, clocking each bit out at a regular, deterministic, unbroken rate of ~14MegaHz.  Again, no gaps or breaks in this long bit-stream, and no preamble or post-amble of other junk.  Just a clean bit-stream at a regular clock rate.  

    It has been suggested that I use the McBSP or McASP.  My question:  Can these peripherals create a long 40kbit bit-stream without gaps, breaks, pre-amble or post-amble, at this clock rate? 

    Two potential problems:

    • Will frame-syncs (or other mischief) cause gaps to appear in the long bit stream?  Does the peripheral need to pause the bit-stream occasionally?
    • If the output buffer of this peripheral needs to be occasionally replenished by the cpu (using an interrupt, say), then can this occur without causing a gap in the output bit-stream? 

    Thanks for your help.

     

  • 0 in reply to Walter Snafu
    TI__Guru 64440 points

    Walter Snafu said:

    I'll explain my c6748 design goal again, more simply this time. My goal is to send out a serial bit-stream of ~40,000 bits, clocking each bit out at a regular, deterministic, unbroken rate of ~14MegaHz.  Again, no gaps or breaks in this long bit-stream, and no preamble or post-amble of other junk.  Just a clean bit-stream at a regular clock rate.  

    It has been suggested that I use the McBSP or McASP.  My question:  Can these peripherals create a long 40kbit bit-stream without gaps, breaks, pre-amble or post-amble, at this clock rate? 

    Certainly the McBSP can accomodate this.  I would also suggest that you use the EDMA to feed the bit stream into the McBSP transmit registers.  This would reduce the CPU overhead of feeding additional data into the McBSP transmit.  But that is an optimization to make.

     

    Walter Snafu said:

    Will frame-syncs (or other mischief) cause gaps to appear in the long bit stream?  Does the peripheral need to pause the bit-stream occasionally?

    You can configure the McBSP to not insert a delay between the active framesync pulse and when data is presented on the transmit pin.  Please refer to Section 2.5.5.5 of the Multichannel Buffered Serial Port User's Guide (SPRUGJ6) which discusses this configuration of the data delay relative to the framesync pulse.  You can configure the first data bit to be transmitted to be sent in the same clock cycle as the framesync pulse.  This is a 0-delay configuration.

     

    Walter Snafu said:

    If the output buffer of this peripheral needs to be occasionally replenished by the cpu (using an interrupt, say), then can this occur without causing a gap in the output bit-stream? 

    Yes.  The Transmit Read (XRDY) interrupt flag is set when data is transferred from the DXR (Data transmit holding register) to the XSR (Transmit shift register).  Therefore, while data is shifted out via the XSR register, the CPU (or EDMA) can fill the next value into the DXR by using the XRDY event.

     

  • 0 in reply to BrandonAzbell
    Genius 3450 points

    Thanks BrandonAzbell!  That is a really encouraging answer.  I can now proceed confidently with my design. 

     

     

  • 0 in reply to Walter Snafu
    TI__Guru 64440 points

    Walter, I assume you meant to say "I can now proceed confidently with my design." rather than "I can not proceed..."