How to DMA to synchronous output pin?

[Anonymous]

I have a need to drive a PSoC 5 LP output pin in a synchronous manner.  I'm thinking of putting bit-coded [bytes] into a memory area, and then using DMA to transfer that memory, one 8-bit byte or 16-bit word at a time, into a [hardware/UDB} component.  The idea is that the DMA and component will work together so that I never have a transmit underflow, and so my synchronous output pin never has a "fault".  This is in contrast to high-intensity use of the processor to keep the thing fed.

   

So, I don't immediately find a good example source code.  This isn't RS232 or SPI or audio.  My thought is to use a "Shift Register" component.  Then I would need to tie the DMA component to the shift register.  I don't know, however, if all the necessary control features are there.  The idea is that the DMA would fill a holding register in the Shift Register *before* the shifting register is empty, so that it gets side loaded in time, without underflow.  So it seems to me that the DMA component nrq output needs to drive the Shift Register Load input.  But then, the DMA component needs to know when it's time to do the next, so maybe the Shift Register interrupt ouput drives the DMA drq input. I'm simply not sure if these things behave properly.

   

Perhaps my question is this.  Am I going about this the correct way, trying to use the Shift Register?  Or is there a better way.

   

Again, to repeat, I need this pin to output a time-controlled, aka synchronous, output.  I want to control it using bits in a memory array.  (Note this pin is self-timed.  There is no separate clock.)

   

Thanks,

   

Helmut

[Bob_Marlowe]

Helmut, there are shift registers which you can connect to a port and fill them using at first test "poor man's DMA" (CPU). At a later stage you could use real DMA.

       

Bob

   

PS: I am located near Bremen

[Anonymous]

I found http://www.cypress.com/forum/psoc-5-device-programming/dma-shift-register which is close, but I have dramatically simplified and improved it in my opinion.  That reference can NOT output bytes back-to-back.  My modification CAN, and is more simple.

   

   

I have reduced the PWM to a single fixed function PWM, using the inverse of the shift register LOAD signal in order to trigger DMA into the shift register FIFO.  One distinct side effect is that the DMA timing.  The original design DMA-wrote the FIFO perhaps a single master clock before it got loaded into the shift register.  My design DMA-writes the NEXT FIFO value one shift clock AFTER the LOAD.  This delays my data output by one byte.  But, it allows the PWM to only count to 8, rather than a minimum of 9 or even 22 as originally designed.  In this way, the bytes are shifted out back-to-back in a true synchronous fashion.

   

Below is a scope capture (hey, I can't afford a new scope) showing LOAD and DATA pins.

   

   

I have attached the complete project.

   

Note that my own need must transmit a single burst, rather than looping indefinitely.  I have that almost working and hope to post the result soon. It involves adding some feedback logic from DMA_NRQ to the reset input of the PWM and ShiftReg_1.

   

-Helmut

   

P.S. Bremen?  Oh well.  Too far from Stuttgart or a US/Europe/India international airport.  Maybe next time...

   

   

[Anonymous]

I believe I have the single burst of multiple back-to-back synchronous bytes working.  I've added 5 S-R Flip Flops built from "discrete" logic, in a feedback loop from DMA_NRQ to the reset input of the PWM_1 and ShiftReg_1.  Trigger_Reg sets all of them, causing nOUTPUT_ACTIVE (aka reset) to go low.  This starts everything.  Later, when DMA_NRQ pulses high for only 2 master clocks, it resets the frist FF.  However, due to the delayed data, there is still another byte that hasn't been sent yet.  The next FF gets reset when LOAD rises for that last byte.  The next FF gets reset when LOAD goes low again.  The next FF gets reset when LOAD goes high yet one more time.  This is now close to when that last byte is finished transmitting and the next non-existent byte is to get loaded.  Note there's one more delay, for the next FF getting reset when LOAD once again goes low.  (The data is coming out one bit time after LOAD.  I believe that's because it doesn't shift until the clock after seeing LOAD.  That's whey the very last extra FF is required.)

   

Note that the software sets then clears Trigger_Reg in the beginning to start things off.  Thus, Trigger_Reg is general 0 during the burst.

   

Note I'm assuming all these NOR and AND gates don't eat up too much resource.  If they do, then...

   

A more simple alternative to this would be to feed the DMA_NRQ into an interrupt.  Trigger_Reg goes DIRECTLY to the reset inputs, so the software sets it low to start things off and leaves it low.  The interrupt routine sets Trigger_Reg to stop further transmission.  (The component name logic is now inverted.  Perhaps add an inverter to make the name make better sense.)  A side effect of this is that the last byte in the DMA burst won't get transmitted, so you need to provide a dummy trailing byte.  Furthermore, the next-to-last byte will only be partially transmitted, so it needs to be a dummy as well, and the situation of transmitting only part of it needs to be acceptable.  Making both dummy bytes 0x00 should help.

   

Below are the top design, a scope photo, and attached project.  The scope shows nOUTPUT_ACTIVE going low during the burst, and then the DATA.  I made the last byte 0xA5 so that I could see the first and last bits to make sure they all came out OK, which they do.

   

My specific application will use nOUTPUT_ACTIVE to key a radio (PTT = Push-To-Talk) and then send the DATA out as FSK.

   

-Helmut

   

   

           

   

[Bob_Marlowe · Accepted solution]

"I'm assuming all these NOR and AND gates don't eat up too much resource.  If they do, then..." On the very right hand side of the Creator window is a resource meter tab. This might help you estimating free resources.

       

Bob