View Full Version : 18F series performance not so good?
CuriousOne
- 10th January 2023, 06:32
Hello to all survivors of too many redirects.... :D
I finally got PIC18F45K80 running, and settings are correct - run multiple PAUSE statements and measured times with scope. But I'm not impressed with performance at all.
The simple code
SOME:
HIGH PORTB.1
LOW PORTB.1
GOTO SOME:
On the 16F series, outputs frequency that of 1/4 of OSC speed- say osc is 8mhz, output will be 2mhz and so on (and contrary some recomendations, replacing HIGH/LOW with LATB=X or TRISB=X does not improve the speed).
Now I have 18F45K80 running at 64mhz.
#config
CONFIG RETEN = OFF
CONFIG INTOSCSEL = HIGH
CONFIG SOSCSEL = DIG
CONFIG XINST = ON ;Enabled
CONFIG FOSC = INTIO1
CONFIG PLLCFG = OFF
CONFIG FCMEN = OFF ;Disabled
CONFIG PWRTEN = OFF ;Disabled
CONFIG BOREN = OFF ;Disabled in hardware, SBOREN disabled
CONFIG WDTEN = OFF ;WDT disabled in hardware; SWDTEN bit disabled
CONFIG CANMX = PORTB
CONFIG MCLRE = OFF
#endconfig
OSCTUNE.6 = 1 ; Enable 4x PLL
OSCCON = %01110000
ANCON1=0 'DISABLE ADC D3-D2-D1-D0-
ancon0=0
TRISC=%00000000 'set PORTC as output all
TRISD=%00000000 'set PORTD as output all
TRISB=%00000000 'set PORTB as output all
TRISA=%00000000 'set PORTA 2 as input, others as output
TRISE=%0000000 'set PORTE as output all
define OSC 64
GKO:
HIGH PORTc.7
'PAUSEus 1
LOW PORTc.7
'PAUSEus 1
GOTO GKO
But output frequency is about 2.5mhz, but it should be at least 16mhz.
Ioannis
- 10th January 2023, 09:40
I do not have that chip and cannot test it.
But 16MHz cannot be output as the main clock is 64MHz and divided by 4 gives system clock of 16MHz. So each MCU tick is 62.5ns. I really do not know how many tick will take your program to execute, maybe 5 or 6? Worst case might be around 380ns or 2.6MHz.
Ioannis
richard
- 10th January 2023, 10:43
On the 16F series, outputs frequency that of 1/4 of OSC speed- say osc is 8mhz, output will be 2mhz and so on (and contrary some recomendations, replacing HIGH/LOW with LATB=X or TRISB=X does not improve the speed).
Not in my world a pic @8mhz [12,16 or 18] would get nowhere near that
GKO:
HIGH PORTc.7
LOW PORTc.7
GOTO GKO
TRANSLATES TO 5 LOOP instructions no matter whether its pic16 or pic18
GKO
BCF PORTC 7 1CYC
BCF PORTC+12H 7 1CYC
BSF PORTC 7 1CYC
BCF PORTC+12H 7 1CYC
BRA GKO 2CYC
AS IOANNIS states around 380ns or 2.66MHz @64MHZ
GKO:
LATC.7 = 0
LATC.7 = 1
GOTO GKO
TRANSLATES TO 3 LOOP instructions no matter whether its pic16 or pic18
GKO
BCF LATC 7 1CYC
BSF LATC 7 1CYC
BRA GKO 2CYC
around 250ns or 4MHz @64MHZ
DITTO FOR
LATC.7 = 0
GKO:
TRISC.7 = 0
TRISC.7 = 1
GOTO GKO
TRANSLATES TO 3 LOOP instructions no matter whether its pic16 or pic18
GKO
BCF TRISC 7 1CYC
BSF TRISC 7 1CYC
BRA GKO 2CYC
around 250ns or 4MHz @64MHZ
tumbleweed
- 10th January 2023, 11:55
I agree with richard. There's no way your numbers are correct, and directly using LAT vs HIGH/LOW should ALWAYS get you almost 2x the performance.
One thing in your setup... never set XINST=ON as it changes the way some instructions work.
CONFIG XINST = ON <<<<<<<<<<<
CuriousOne
- 10th January 2023, 20:27
Well I posted all that several years ago, with the scope screenshots. Later I'll try to find that topic and bring it up.
So issue is, why 18F is so slow, and is there a way to fix it?
tumbleweed
- 10th January 2023, 21:30
It's not so slow... you're seeing what it should be.
The 16F isn't any faster. Since the max clock is 32MHz, it'll be half the speed.
If you want the 18F to be faster use LAT as Richard showed.
CuriousOne
- 11th January 2023, 18:43
No I don't mean that. I mean different thing - a lot of code posted here is exclusively for 18F series. When asked, authors say that 16F has no speed to do it. But now it turns out that there is no performance difference per mhz at all?
mpgmike
- 11th January 2023, 19:06
The PIC18F advantage over the 16F is more instructions. The 18F's ASM "MOVFF" allows transfer of a byte of data directly from one register to another. For the PIC16F, it would take several instructions using the W Register.
CuriousOne
- 11th January 2023, 19:44
Thanks!
So besides more peripherals, like USB host, 2x osc speed and 2x memory, there are no other advantages, right?
tumbleweed
- 11th January 2023, 23:19
Those extra instructions definitely make a difference. It's not just clock speed. If it takes more instructions to do the same thing then that's a disadvantage.
That, plus even though the memory is still banked you don't have the horrible ram arrangement that the PIC16 suffers from, and no program memory page issues.
The 18F has a hardware multiplier, dual-priority interrupts, more FSR registers.
All in all, if you have a choice between 16F and 18F, 18F is the better choice. It'll produce faster code in a lot of instances.
The only reasons I can think of to use a 16F might be price or perhaps power consumption.
richard
- 12th January 2023, 01:11
not to mention the flash memory is 16 bits wide allowing for tabled data to be accessed way easier, eliminating any need to pack/unpack data.
bigger faster fonts with less effort, works for me
CuriousOne
- 12th January 2023, 05:48
All that good, but does PBP uses them? The main difference I found is the dimension of arrays and long variables.
Say, average, 500 line PBP code will run significantly faster on 18F or not?
I don't care for banks or whatever with 16F - compiler takes care of.
Price is also not an issue - 18F45K80 and 16F1939 (which I most often use) have same price in china - around $3 new, $1 - 2nd hand.
richard
- 12th January 2023, 11:25
if you put a bowling club granny in a ferari would she drive faster ?
in the right hands a pic18 is faster by a large margin
tumbleweed
- 12th January 2023, 11:36
Say, average, 500 line PBP code will run significantly faster on 18F or not?
I don't care for banks or whatever with 16F - compiler takes care of.
I get that YOU don't care for banks or whatever, but the compiler does.
The answer depends on what your "average 500 line PBP code" does.
As you see from your original example of toggling IO ports, the difference could be anywhere from 0 to much faster.
How much faster?
It depends.
Ioannis
- 12th January 2023, 14:25
All that good, but does PBP uses them?
Yes it does.
You can vedrify this by yourself. Though a simple two variable multiplication in your editor and after compilation check the LST file. You will see that mulwf command is used just fine!
Ioannis
'************************************************* ***************
'* Name : UNTITLED.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2023 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 12/1/2023 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************
b1 var byte
b2 var byte
w3 var word
b1=123
b2=456
w3=b1*b2
end
and part of the LST file:
00001 ;************************************************* *****************
00002 ;* pbp_pic18FxxK40.LIB *
00003 ;* *
00004 ;* By : Leonard Zerman, Jeff Schmoyer, Darrel Taylor, *
00005 ;* Charles Leo *
00006 ;* Notice : Copyright (c) 2017 ME Labs, Inc. *
00007 ;* All Rights Reserved *
00008 ;* Date : 04/05/2017 *
00009 ;* Version : 3.1.0 *
00010 ;* Notes : Created for 18FxxK40 and similar devices *
00011 ;************************************************* *****************
00081 LIST
00082 ; Oscillator is 4MHz
01288 LIST
000000 01289 ORG RESET_ORG ; Reset vector at 0
01298 LIST
000000 EF23 F000 01299 goto INIT ; Finish initialization
08250 LIST
000004 5004 08251 MUL movf R1, W
000006 0208 08252 mulwf R3 ; R1 * R3 = PRODHL
000008 CFF3 F006 08253 movff PRODL, R2
00000C CFF4 F007 08254 movff PRODH, R2 + 1
CuriousOne
- 12th January 2023, 19:44
My code does various things - reads pixel data from eeprom and sends it to display module via paralel interface, to show meaningful data to user. It interacts with TCXO, ADCs, serial wired leds, mp3 module, GPS module and a lot of other I/O. My code does no complex math, except increasing value of some variables and doing HEX<>DEC conversion for RTC.
Here's a small fragment from one of my 16F code. So moving to 18F, will deliver any speed increase for something like this?
ERASER: 'INITIAL DISPLAY SET TO ZERO
low LED
FOR Y=0 TO 15
LOC=Y
GOSUB LOCSET
X=11
GOSUB CODER
NEXT
pause 30
waiter: 'wait for keypress and display time
if lock=0 then goto beginner
pause 1000 'toggle led
toggle led
gosub gettime2
gosub timedisp
goto waiter
stop 'finish
coder: 'decode into cd4543 bcd
low strb
PORTD.0=x.2
PORTD.1=x.1
PORTD.2=x.3
PORTD.3=x.0
high strb
return
LOCSET:' SET THE DIGIT LOCATION
HIGH STRB
PORTD.4=loc.0
PORTD.5=loc.1
PORTD.6=loc.2
PORTD.7=loc.3
LOW STRB
'PAUSE 10
RETURN
gettime:
I2CRead SDA, SCL, $D0, $00, [RTCSec, RTCMin, RTCHour, RTCDay, RTCDate, RTCMonth, RTCYear, RTCCtrl]
t1=rtchour >> 4
t2=rtchour // 16
t3=rtcMin >> 4
T4=rtcMin // 16
'Z1=(RTCmin >> 4)*10+RTCmin // 16 'decode seconds
'Z2=(RTCHour >> 4)*10+RTCHour // 16 'decode hours
hours=T1*10+T2
minutes=T3*10+T4
if DRO<>rtcmin then 'check for time changes, so display only is refreshed when time is changed
cvlileba=1
else
cvlileba=0
endif
DRO=rtcmin
Return
Ioannis
- 13th January 2023, 07:32
I am sure it will.
How much? I will not analyse your program for you as it is too much work to do.
Ioannis
Powered by vBulletin® Version 4.1.7 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.