PIC18F2550 REPLACED FOR PIC18F26K22

[gaugeguy]

You need to use LAT and not PORT when setting an output. PORT is for input and LAT is for output.

[rudy]

It worked at the end!

But I am not sure what is the SPI frequency I am working with. I finally got the SPI running, I presume I am running at 64MHz, but the refresh rate of the LCD is exactly the same as 18F2550 running at 48Mhz.

Quite confusing...

[temtronic]

LCD refresh is determined by the LCD module not the SPI speed.
SPI speed is the 'data transfer' rate.
Historically LCDs are slow devices, so you' need to read the datasheet for your to see how 'fast' it is.
To measure the SPI speed, simply put scope or frequency counter on the SPI clock pin, send a character forever, read the scope or counter.

[rudy]

With Oscilloscope, the maximum I could reach is 1,60mhz at clock pin. The IIL9341 can easily reach 10Mhz.

[Ttelmah]

Try explicitly setting the SPI clock rate:

#use SPI(MASTER, SPI1, MODE=0, BITS=8, BAUD=8MHz)

The slew rate limitation of the SPI port, together with the setup and hold
times of the devices, means that though it can potentially clock to 16MHz,
this is usually out of spec. However 4Mhz, and 8MHz, should
work. I've used the SPI at 8Mhz on the same chip you are using and
it merrily worked fine.
If it doesn't go to 8MHz, you need to do a basic 'flash an LED' test and
check your chip genuinely is running at 64MHz.

What compiler version are you actually using with this?.

[rudy]

Hi Ttelmah

When I insert this:

[rudy]

There is another issue. The clock waveform is weird. The SDO is sharp square wave, but the clock signal is strange. I don't know if there is nome other configuration I need to do on PIN_C3. Have to check.

[rudy]

All wrigth!

Chip is not running at 64Mhz.

I did this: (as mentioned by Ttelmah:

[Ttelmah]

No, it shouldn't be 16MHz. Each output instruction is 3 machine cycles, and
the loop is another two. This is why to test the speed you need to do it
with delays in the loop. Something like:

[rudy]

Rsrsrsrsrs.

Exactly 500Hz. A nice square wave.

[Ttelmah]

In which case you should be able to get the SPI to 4 or 8MHz. Same
question as before, what compiler version is this being tried on?. Also
what happens if you specify 8MHz?.

[rudy]

Well, Ttelmah;

The compiler version now is 5.049. I Expect that the 18F26k22 could be at least 30% faster them 18F2550 (64/48). I have here an old particular development, that uses an 320x240 ILI9341 LCD color display, and I am trying to do the SPI communication a little bit faster, to get better LCD screen image changing. But I also have the 18F2550 running in the old development, along with this new development, and I can see any difference within both processors SPI speed.

All I can do now, with my poor knowledge, is to check if the sending image routine is the problem perhaps, may be it is not as good as it could be.

Regarding with your question, if I understand it, The #use_spi statement you send me, didn't make any change to SPI speed, in fact, it got slower than the original statement.

This is your suggestion:

[Ttelmah]

Get rid of your code writing to the SSP registers.
The setting you are trying to use takes the SPI port outside it's limitations.
Generally in CCS, you should pretty much never write directly to registers.
Doing so is an easy way to make mistakes.

One key thing I have not seen you doing, is setting the slew rate, On this
later chip, you need to disable the slew rate limitation or it won't be able
to clock at the fast rates.

set_slow_slew_c(FALSE);

Slew rate limiting defaults to 'on', and limits the maximum clock rate
on the SCK pin to under 2MHz.

[rudy]

No change!

The only things that makes SPI goes at reasonably speed are:

[temtronic]

As Mr. T says, use the CCS functions not directly writing to registers.
I suspect the old compiler version 'might' be putting the wrong data into the registers. Dumping the listing would confirm/deny this. filename.lst is the listing, the actual code generated by your program.