 |
 |
| View previous topic :: View next topic |
| Author |
Message |
rudy
Joined: 27 Apr 2008
Posts: 168
|
| PIC18F2550 REPLACED FOR PIC18F26K22 |
 Posted: Tue Nov 30, 2021 4:46 pm |
 |
|
Hi all,
I have a personal circuit that uses an 240x320 SPI lcd, with ILI9341 driver, also there is an RDA5805 FM module. Between them and the processor, there is a shift level converter, based on TXS0108E converter chip and an PIC18F2550 at the end.
Everything works pretty well, but it seems to me that the SPI communication to the LCD could be a little bit faster than it is, so, I have some development to do, and enjoy this opportunity to change the PIC18F2550 running at 48MHz for an 18F26K22 running at 64MHz, once that they are pin by pin compatible, at least is what it seems.
None of I2C to RDA FM module and SPI to the LCD works, at my trying, and I would be very happy to reduce a little bit the 64MHz, just to have the LCD communication working again, but a little bit faster than I could achieve with the old PIC18F2550.
Below is my 18F2550 initialization code (crystal 20MHz)
| Code: |
#include <18F2550.h>
#fuses HSPLL, PLL5, CPUDIV1, NOWDT, NOFCMEN, NOIESO, NOCPD, NOPROTECT, NOLVP, NODEBUG, PUT, NOBROWNOUT, MCLR
#use delay(clock=48000000)
#use SPI(MASTER, SPI1, MODE=0, BITS=8)
#use I2C(MASTER, SDA=PIN_B7, SCL=PIN_B6)
|
And here is the 18F26K22 initialization code (20MHz crystal is there, but not used)
| Code: |
#include <18F26K22.h>
#fuses NOWDT, NOFCMEN, NOIESO, NOCPD, NOPROTECT, NOLVP, NODEBUG, PUT, BROWNOUT, MCLR
#use delay(internal=64MHz)
#use SPI(MASTER, SPI1, MODE=0, BITS=8)
#use I2C(MASTER, SDA=PIN_B7, SCL=PIN_B6)
|
Any chance to make it work?
Regards! |
|
 |
vtrx
Joined: 11 Oct 2017
Posts: 142
|
|
| Posted: Tue Nov 30, 2021 5:20 pm |
|
|
Try.
| Code: | PLLEN,NOXINST,INTRC_IO,
#use delay(int, clock=64MHz) |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Wed Dec 01, 2021 2:20 am |
|
|
Also, what compiler version?.
The efficiency of the spi_xfer, was improved very significantly a few compilers
ago. As much as perhaps 25% gain on some of my code. Might be worth
upgrading the compiler if you have an older version.  |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Wed Dec 01, 2021 6:42 am |
|
|
You may want to set the 26k22 clock to 48MHz, for initial testing.
Years ago, I found out that some I2C devices wouldn't run at the 64MHz clock of a 46K22 ! Ended up READING that devices datasheet...hmmm...some times it pays to read...
I think the compiler will run devices at the highest speed(default).This was never a problem with 20MHz PICs or peripherals .
I don't know what speed your device can run, but since that worked fine at 48MHz, I'd start there. |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Wed Dec 01, 2021 8:30 am |
|
|
Hi all;
@Ttelmah
Not spi_xfer, I think this is regarding with software SPI, and I don't use it. The compiler version is 5.007
@temtronic This is my fist approach, try to reduce the clock for 48MHz, and see what happens.
Thanks! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Wed Dec 01, 2021 9:10 am |
|
|
Ouch 5.007!. That is before I considered V5 to be running compilers. About
5.012, was the first V5 compiler I found where 95% of the functions worked.
An upgrade really is needed.
No, spi_xfer is not for software SPI. It is the SPI function that should always
be used with #use spi.
If you read the manual, you will find that #use spi, only refers to spi_xfer
for the actual operation. spi_read and spi_write, only refer to setup_spi.
These are two _distinct_ ways of setting up and using the SPI, and should
not be mixed. |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Wed Dec 01, 2021 9:53 am |
|
|
hum......
I just try to use the V5.049, and the original program that fits tight on F2550, now the MPLAB says "*** Error 71 "CLOCK.c" Line 693(1,2): Out of ROM, A segment or the program is too large MAIN"
I think will go back for 5.007 version!
Regards!  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Wed Dec 01, 2021 11:27 am |
|
|
The code did get larger, when it started to work properly!...
They have reduced the size a little since with better optimisations, but the
small size probably actually reflects the compiler not actually doing some
things correctly.... 
However this is a segment too large problem, not a 'actually too big' problem.
Have a search here. How to change the code to allow it to be split up better
to fit has been covered many times. They shifted the way the code is
optimised to make almost all things 'inline', which increases speed, but
does mean _you_ have to decide how things are split up, |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Wed Dec 01, 2021 11:49 am |
|
|
May be!
Because it works really fine, for more than 2 years. I just want to put SPI a little bit faster, due to the LCD refresh rate, just that!
I will take a look after, to see if I can optimize a little bit of the code!
Regards. |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Tue Dec 07, 2021 12:14 pm |
|
|
Trying to deal with this PIC18F26K22, but decided to start from scratch, because it is very much complex....
Start the old and good LED blinking, and found something very strange! Why do I have to insert a 1ms delay between every port change? doesn’t matter witch port I use, don’t work without this 1ms delay! If I don't put it, just LED2 blinks, and LED1 stays OFF all time. If it is "strange"like this I will give up very soon....
| Code: |
while(TRUE) //PG NORMAL DE TRABALHO
{
LED1=1;
delay_ms(1);
LED2=0;
delay_ms(500);
LED1=0;
delay_ms(1);
LED2=1;
delay_ms(500);
}
|
|
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Tue Dec 07, 2021 12:35 pm |
|
|
You'd have to tell me what pins are connected to your LED0 and LED1 for me to be sure, but if they're connected to the same port, it could be the 'classic' RMW (read-modify-write) issue.
Your code tells the processor to change a pin's state, for example set it high. The code does this. Next instruction is to set a different pin on the same port to a different state. Code reads the state of the port, applies the change to the new pin, then writes the entire port at once. If the first pin didn't have sufficient time for the RC time constant of whatever is connected to it to fully charge or discharge, then the initial change essentially is undone. |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Tue Dec 07, 2021 12:38 pm |
|
|
Hi!
Doesn't matter. I tried in different ports, A, B and C. The weirdest is that it works when I put one LED on port C and another on port SA, for example, but never work in the same port without the 1ms delay. In this case, I use C4 and C5, just to blink both!
Regards. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Tue Dec 07, 2021 12:52 pm |
|
|
We would need to see the entire program...
I've never had to do what you say
...
while(true) {
output_toggle(pinname);
delay_ms(500);
}
... |
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Tue Dec 07, 2021 1:02 pm |
|
|
It works;
I changed the code to this, and now works fine!
| Code: |
while(TRUE) //PG NORMAL DE TRABALHO
{
output_high(pin_c4);
output_low(pin_c5);
delay_ms(100);
output_high(pin_c5);
output_low(pin_c4);
delay_ms(100);
} |
|
|
|
rudy
Joined: 27 Apr 2008
Posts: 168
|
|
| Posted: Wed Dec 08, 2021 4:58 am |
|
|
It is definitely weird. I always did that, and always worked.
| Code: | #include <18F26K22.h>
#fuses NOWDT, NOFCMEN, NOIESO, NOCPD, NOPROTECT, NOLVP, NODEBUG, PUT, BROWNOUT, NOMCLR
#use delay(internal=64MHz)
#byte PORTA=0xF80
#byte PORTB=0xF81
#byte PORTC=0xF82
#byte PORTE=0xF84
//#byte SSPCON1=0xFC6
//#byte SSPCON2=0xFC5
//VARIÁVEIS DE SISTEMA
int PAGE=0;
#bit LED1=portc.4
#bit LED2=portc.5
void main()
{
//SSPCON1=0X20;
SETUP_ADC_PORTS(NO_ANALOGS);
SETUP_COMPARATOR(NC_NC_NC_NC);
SETUP_COUNTERS(RTCC_INTERNAL,RTCC_DIV_1);
SETUP_TIMER_1(T1_INTERNAL|T1_DIV_BY_8);
SETUP_TIMER_2(T2_DISABLED,0XFF,16);
SETUP_TIMER_3(T3_DISABLED);
SETUP_CCP1(CCP_CAPTURE_FE);
SET_TRIS_A(0b11111111);
SET_TRIS_B(0b11111111);
SET_TRIS_C(0b11001111);
SET_TRIS_E(0b11111111);
loop:
while(TRUE) //PG NORMAL DE TRABALHO
{
LED1=0;
LED2=1;
DELAY_MS(100);
LED1=1;
LED2=0;
DELAY_MS(100);
}
goto loop;
} |
I changed the compiler version back to 5.007, the same I use for years and the problem still the same. Just one led blinks, |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
