18F series performance not so good?

[CuriousOne]

Hello to all survivors of too many redirects....

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]

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]

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]

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]

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]

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]

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]

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]

Thanks!

So besides more peripherals, like USB host, 2x osc speed and 2x memory, there are no other advantages, right?

[tumbleweed]

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]

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]

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]

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]

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]

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]

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]

I am sure it will.

How much? I will not analyse your program for you as it is too much work to do.

Ioannis