Pulse width control of GPIO outputs?

Hi BB Fellows,

I am planning to control a RGB-LED using the expansion connector pins
MMC_DAT5 - MMC_DAT7 as output pins with resistor-transistor drivers. I
would like to have a pulse width resolution in the range of 1-to-1024
individually for each LED to create impressive color and intensity
spectrum. I would like to do this using SDMA in repeat mode to
minimize the processor load. This is my initial idea - does somebody
have experience in doing this with OMAP3530 or otherwise a more
elegant way to do it? Please, advise,

siñ

I am not usre why you have chosen these particular pins or what the other pins are being used for, but there are three PWM outputs on the expansion header that could possibly be used. Take a look at Table 20 of the System Reference Manual for further details.

Gerald

2010/2/12 Seppo Nikkilä <seppo.nikkila@innovativeideas.fi>

So you propose expansion connector pins 4, 6, and 10 as PWM in MUX:2
mode. Unfortunately I have to use McBSP3 for my I2S (would prefer
McBSP2).

What do you think about the "misuse" of SDMA to emulate PWM? I would
hate to use processor cycles for something as rudimentary as this.

Basically I would write my PWM pattern to a memory buffer and let SDMA
roll it to these GPIO lines. When I want to change the pulse ratio I
will write new patterns to the buffer without even interrupting the
SDMA. Quick and dirty - I confess,

siñ

And, yes, I haven't read the SDMA chapter carefully yet nor GPIO or
System Control... So do you think it can be done this way?

same

As I said, I wasn’t sure what the other pins were being used for. I think that the SDMA may work, but it depends on your overall flash rate. And I am not exactly sure how that would work. I will leave the answer to that aspect to some of the SW folks.

Gerald

2010/2/12 Seppo Nikkilä <seppo.nikkila@innovativeideas.fi>

Seppo Nikkil� wrote:

So you propose expansion connector pins 4, 6, and 10 as PWM in MUX:2
mode. Unfortunately I have to use McBSP3 for my I2S (would prefer
McBSP2).

What do you think about the "misuse" of SDMA to emulate PWM? I would
hate to use processor cycles for something as rudimentary as this.

read back in the list archives, there was somebody who found out that
the "speed" of the GPIOs was not fast enough for his use case, might
be the same for you.... (subject was something with "GPIO"...)

Thanks for the remark! In my case the speed is not an issue. For me
the 32 kHz rate is is optimal. This should be more than easy for the
GPIO.

siñ

Hi siñ,

Actually I think that the fact, that the GPIO speed is limited is actually the reason why your sketched setup might work. In case the GPIO would run blasting fast you would use all your internal L3-bus-bandwidth doing SDMA transfers killing the rest of your system or making the PWM width unreliable in case of a low SDMA-L3-priority.

The GPIOs run 4MHz and I still have to an open point to explain exactly how this affects general system performance. Reason I never answered the thread is, that it's not behaving exactly the way I expected it to do in my experiments => I can't still explain every detail of it and more experiments need to be done...

I'm however hit by massive loads of work (fortunately), but will get back to it as soon I get 1 day free :slight_smile:

Meanwhile please give it a try and let us know about your results :slight_smile:

Best regards
  Søren

Yes, I was probably the one who started this GPIO performance thread
last fall, and I confirm the 4 MHz clock somewhere
in the GPIO system. I am guessing that the GPIO system is actually a
multiplexed state machine, and it services
every pin every 250 ns. I was planning on writing all ones and then
all zeros to a contiguous byte of GPIO pins and seeing
if there was a detectable time skew between pins. If not, then
repeating with pins in two consecutive bytes.
I haven't gotten around to trying this test, yet.

Your comments above are interesting. Some tests I did seem to show
that the CPU is held back in some way when
updating GPIO pins. So, I can have a program that does a timing loop
and then updates the GPIO, and then try
various combinations of the above. For instance, have a couple
microsecond delay loop and then toggle a GPIO pin
ON and back off, then go back to the delay loop. I verified that the
CPU was being held back until the GPIO pin
was updated.

Jon

Søren & jmelson,

This is very interesting, indeed!
I planned to use SDMA with 32 kHz cycle rate to drive GPIO outputs. So
processor would not be involved.
Now how do I best program SDMA to such slow rate and
do you think that the processor would still be held back?

siñ

Hello,

Søren & jmelson,

This is very interesting, indeed!
I planned to use SDMA with 32 kHz cycle rate to drive GPIO outputs. So
processor would not be involved.
Now how do I best program SDMA to such slow rate and
do you think that the processor would still be held back?

Here's an odd idea that may or may not work, assuming the straight DMA
is too fast or too unreliable.

Could you use one of the unconnected McBSP's to control the frequency
of the data sampling using digital loop-back mode?

Set the sample rate/frame-sync frequency appropriately, and the
receive threshold so no buffering takes place. Then configure 2 dma
channels, one to send the data to the McBSP.DXR and the other to copy
the now frequency-controlled DRR to the GPIO register.

Michael

Hi Michael,

This is a good idea, unfortunately I have use for all serial
communication ports on the expansion connector. I only have the MMC2
signals vacant so if they don't work as GPIO, I will try to use them
as MMC2_DATx. I will let you know when I have my expansion board at
hand and have tried first with GPIO&SDMA. For me speed is not a
matter...

siñ