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.
PS: I am located near Bremen
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.
P.S. Bremen? Oh well. Too far from Stuttgart or a US/Europe/India international airport. Maybe next time...
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.
"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.