2009-04-23 14:15:57     PPI Duty Cycle?

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

2009-04-23 14:15:57     PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73108   

 

I have a simple test program that i wrote, based heavily on ppitest (? confirm).  It just configures the PPI port.  Then it loads a buffer of 640x480,with an incrementing value,

Finally it continuously dumps that same buffer out the ppi multiple times.  The main loop is very simple:

 

    for (done = 0;done < cycles;done++)

    {

    retval = write( ppiFD, gImage, gImageSize );

    if ( retval != gImageSize ){

            perror("ppi write error");

            done = 1;

        }

    }

 

The problem that I am having is that data is only coming out the PPi port approximately 50%  of the time.  The rest of the time nothing is coming out.

 

I am doing this as a 2-D write, and I see on a scope that FS1 has a 50% duty cycle, and data is only being written while it is low.  I have confirmed that I have CMD_PPI_DELAY 0.  The length of time that data is being written is about 32 usec.  That does correspond to 640 writes at a 20MHz clock (on board the EZKit). 

 

I am using uclinux SVN with a 527 EZkit 527 board.

Is this a bug in my code?  A bug in the PPI port driver?  A limit in the PPI port DMA transfer that it takes nearly the full write time to set up the write?  Something else that I am missing?

Thanks,

QuoteReplyEditDelete

 

 

2009-04-23 14:54:31     Re: PPI Duty Cycle?

Robin Getz (UNITED STATES)

Message: 73109   

 

Adam:

 

I'm not sure what you are trying to do - if you need to create a frame buffer - the best (only) way to do this is via a kernel driver.

 

-Robin

QuoteReplyEditDelete

 

 

2009-04-23 15:10:57     Re: PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73110   

 

I am trying to just write a bunch of data from user space out the PPI.  So I am just using ppicycle as a model and using the ppi driver that it uses.  And that is where I ran into the odd timing issue.  Is there a problem with doing it this way?

 

I found an additional oddity.  I tried to switch over to just doing 1-D, instead of 2-D, and  kept the rest of my test code the same.

 

Now with each frame sync it sends data out for 2.3 msec.  While dumping a full frame should take 15 msec.  And often the code will just freeze after sending about 500 frames, but that number varies.  On a scope it is not sending any data.  It just stops and the application hangs at just 2% cpu.  It seems at though that write to the ppi never returns.  If I just do a few hundred writes, it usually returns.  If I set it to do 1000 writes then occasionally it completes, but usually it just hanges.

 

Seems odd.

 

 

QuoteReplyEditDelete

 

 

2009-04-23 18:03:45     Re: PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73113   

 

I realized that I have been getting some under-run errors.  When I do it at 2-D I see a few.  Perhaps 12 in a run of 1000 outputs.  But when I do it 1-D I see a whole bunch more.

 

I am using the 20MHz clock on the EZKit.  Should the 527 be able to keep up?  I actually was hoping to use a 24 MHz to stream 16 bit data out from SDRAM memory.

 

I see that some of the same issues were discussed here:

 

https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&_forum_action=ForumMessageBrowse&thread_id=33495

 

Is that possible?  Too fast?  Perhaps you are right that I really should be using a framebuffer.  Would it then be possible to get a stream at that kind of data rate?

 

Thanks,

 

--Adam

QuoteReplyEditDelete

 

 

2009-04-24 10:21:48     Re: PPI Duty Cycle?

Michael Hennerich (GERMANY)

Message: 73162    Adam,

 

I think your problems with 1D DMA also come from the fact that 1D DMA only support 2^16 words lengths.

 

> Should the 527 be able to keep up?

 

Do you use 8 or 16-bit PPI?

Right now the bfin_ppi driver doesn't support the PPI Packing mode.

 

>Is that possible? Too fast? Perhaps you are right that I really should be using a framebuffer.

>Would it then be possible to get a stream at that kind of data rate?

 

You should definitely modify framebuffer driver for your needs.

The bfin_ppi driver was never designed to be used like this.

Blackfin framebuffer driver use the AUTO DMA reload feature.

You enable the DMA and PPI only once and it keeps running.

The DMA restart automatically without Interrupts or other intervention.

 

>Is that possible? Too fast?

 

I think some people use PPI CLK in the range of 20MHz (16 bit PPI) successfully.

But in case you have slow Async Memory accesses and by accident a cache line fill, you might get an PPI under run error.

 

-Michael

 

 

QuoteReplyEditDelete

 

 

2009-04-24 14:38:19     Re: PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73179   

 

>I think your problems with 1D DMA also come from the fact that 1D DMA only support 2^16 words lengths.

 

Oops.  I was try to send out more then 2^16 words.  So that does explain why the 1-D wasn't working.

 

>Do you use 8 or 16-bit PPI?

 

>Right now the bfin_ppi driver doesn't support the PPI Packing mode.

 

I have 16 bits of data and I am using 16 bit PPI.  So I don't think that I need the packing mode. 

 

As I am trying to build up packets, not a video frame, I had not really thought about using the framebuffer.  But I will look into that.  I know that there are a whole bunch of different video drivers in drivers/video (over 100).  Any suggestions about where to start?  If I just want to build up a block of packet data in memory and then have it constantly sent out the PPI port which driver might be a good starting point?

 

Thanks,

 

--Adam

QuoteReplyEditDelete

 

 

2009-04-24 14:40:26     Re: PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73180   

 

Also, do you have any idea why when I do operate in 2-D mode I only get data at 50% duty cycle?  In 2-D it seems to be behave as though the delay time is equal to the row send time.

QuoteReplyEditDelete

 

 

2009-04-27 16:33:15     Re: PPI Duty Cycle?

Adam Dershowitz (UNITED STATES)

Message: 73319   

 

Micheal,

 

 

 

I have started looking trhough some framebuffer code.  Specifically I see that bfin-t350mcqb-fb.c is code that you wrote.

 

Does that seem like a good starting place?  I am a little unsure why you think that a Framebuffer approach is the way to go on this.  I have been reading up on this and my understanding is that the real benefit of a framebuffer is that it allows for a generic interface to different types of displays and such.  In my case, I am trying to use a very specific one, that does not need things like "copy_area" and such that can be generic.  I just want to build up set of packets in memory and have them go out the PPI port.  I do want them to repeat until changed, like a screen.

 

I also am worried about my prior question about the 50% duty cycle.  Because if I switch over to a framebuffer, but use a similar set of configs to what is in the ppi driver I would expect to still get that 50% per row.

 

As you can see, I don't really understand why the PPI driver is not going to work, and I am looking for some guidance on the framebuffer approach.

 

 

 

Thanks much,

 

--Adam

QuoteReplyEditDelete

 

 

2009-04-28 03:25:40     Re: PPI Duty Cycle?

Michael Hennerich (GERMANY)

Message: 73342    Adam,

 

A framebuffer driver gives you at least three things - and I think you want all of them.

 

1) bfin_ppi driver doesn't allow use of autobuffer DMA - our framebuffer driver all use autobuffer DMA or chained descriptor DMA.

2) A framebuffer driver provides you an uncached memory area.

3) Its a well standardized interface to user space.

 

You can do things like this:

 

#cat /dev/fb0 > screenshot.raw

#cat screenshot.raw > /dev/fb

 

From you user space application you simply open /dev/fb an MMAP the uncached memory area the kernel/fram,ebuffer driver provides.

 

The "duty cycle" as you refer to depends on the number of words (pixels) per line and the recurrence of the Line start condition (FS1 asserted). This is controlled by Blackfin HW timers in PWM_OUT mode.

 

-Michael

Attachments

    Outcomes