fastest PIC

georpo · Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.

Hello,

I am currently using a PIC24HJ256GP206 overclocked at 100MHz giving 50MIPS
but I need something much faster in order to display video on a TFT display.

So, which is the fastest PIC supported by CCS?

Thanks!
_________________
George.

bkamen · Posted: Sun Nov 06, 2011 9:22 am

georpo · Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.

The PIC24FJ256DA210 is much slower than the one I use.

It is not a matter of graphics etc. The video is stored as bitmaps in a SD card. I just need faster data transfer when writing on the 16bit bus.
Right now my TCY is 50MHz giving 20nS instruction cycle.
I need something 5 times faster than this.

So, again to the starting question.

Which is the fastest PIC supported by CCS?

Thanks.
_________________
George.

bkamen · Posted: Fri Nov 11, 2011 12:19 pm

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You can use this Microchip tool to find fast PICs:
http://www.microchip.com/maps/microcontroller.aspx

Choose the basic type of PIC in the box on the upper left. Also, click on
the little + in the corner, so you can see tickboxes for "Current, Future, etc.

Then go down to the row for "Max CPU Speed", and select the MIPS that
you want. For example, to get a mininum of 60 MIPS select that for the
first column but leave the 2nd column as -All-.

The page will automatically update in a couple seconds, after you make
any change. The list of suitable PICs will appear in the Search Results box.

georpo · Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.

The TFT panel has built in SSD1963 controller.
It is not driven directly from the PIC.

Imagine that I had a really fast card that can give me the desired speed
or that I had all the bitmaps in RAM. Not possible. I know. Just imagine.

So, what I would need is to feed the 16bit bus so fast:

480x272 pixels = 13560 pixels x 3 bytes/pixel (for 24 bit color)
=391680 bytes per frame.

391680 bytes /2 (because it is a 16bit bus) = 195840 words x 25 frames/sec
=4896000 words/second.

This is not so fast but think that before each word write, the PIC
has to calculate and shift the RGB bytes in the word to be written.

With the current PIC running at 50MHz, this is what I get:

ftp://user:12131547@georpo.dyndns.org/2GBSD/graph.jpg

This is taken from the /WR pin. It takes 664nS for 3 words transfer.

I am thinking of going NXP ARM.
_________________
George.

n-squared · Joined: 03 Oct 2006 Posts: 99

Hi
Microchip has released a new family of PI24 chips that run at 60MIPS.

The PIC24EP256GU810-I/PF is a 100TQFP device with 24K bytes of RAM.

BR
NN
_________________
Every solution has a problem.

drolleman · Joined: 03 Feb 2011 Posts: 116

Looking at the scope output there appears to be a lot of load / capacitance that is causing the signal to look like it does. You need to make the traces as short as possible, but thick enough to carry the current.

The other thing to do is pre-create your image in ram. Also this may look good in code 'Write_Data((color)>>16)' but expensive in clock cycles at runtime. Have this broken up before you write to the screen.

georpo · Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.

This is what I use to fill all 480*272 pixels with a color.
Color is a 32 bit value, I use the 24 lower bits to represent 8 bits for RED, 8 bits for GREEN and 8 bits for BLUE.
Data is packed in 16 bit format and requires 3 writes in order to fill 2 pixels:

RG 1st word contains RED and GREEN of 1st pixel
BR 2nd word contains BLUE of 1st pixel and RED of 2nd pixel
GB 3rd word contains GREEN and BLUE of 2nd pixel

drolleman · Joined: 03 Feb 2011 Posts: 116

When i indicated in ram, you use intelligent writing, where writing is required only. If a object needs updating then update that object. You don't create a raw image in ram but its color / format / location / what it is. This uses very little ram. For fill areas use the fast fill method.

eg. button
put outline of button
fill inside
write char's

It's the fill that usually takes the most time to write, since cpu cycles / pixel comes into play. The more complex, the more cpu cycles required to get the job done. I like to use a scope to tell me how long it takes to do something. or use the stopwatch in the realice to help trim how long it takes to do something.

If I'm writing a 7 seg item than I pre-format in ram. Usually it is fgcolor / bkcolor this only uses 1 bit per pixel even if you use 64k color! very little ram used. So when sending it to the controller it's very fast.

This method doesn't work on images, then you would need enough ram to support full image in ram. Or the video controller would need paging capabilities.