Diffrence between pic16f and pic18f

[pixman]

Hi to all

I have found a that using a delay timer is different between Pic16f and Pic18f.
I received my samples of the Pic18f44k22. Setup the config bits and tried to toggle and led,
but the led stayed on. I then took Nigel's Tut1.2 and ran it on a pic16f628a in mplab sim.
I used the stop watch and it read the delay routine was 250mSec.
I set the Pic18f44k22 up to run at 4Mhz under mplab sim.
The stop watch read the delay routine was 3,5mSec.
Each line was read at 1uSec for both.
Why is there such a difference.

David

 

[Pommie]

Software delays written for the 16 series don't work correctly on the 18 as the goto $+n syntax is wrong. However, you may also have the PLL enabled which will increase the speed 4 fold. Check your config and then google pic18 delay.

Mike.

 

[pixman]

I have changed the config to different speeds and pllx4 is off. for some reason I can't get that to work. that is why I want to use a timer to toggle an output, the I can check it with a scope to see what is going on. I can't read the high frequency with my scope, its a small hand held unit that was given to me.

 

[pixman]

I found a code generator, but it is for a 16f. under the comments it was said to change the goto $+2 to $+6.
I have tried this with Nigel's delay timer and work under mplab sim. I will try it with actual Pic and the scope to see if my config setup is correct.

 

[Mosaic]

Perhaps you could try it with Oshonsoft, using the same basic script for each processor.. Once it works have a look at the assembly code to determine the differences.

 

[pixman]

Got it sorted out, By changing the goto $+2 to goto $+6.
Now I can tackle the real problem. The Usart. It loads the W-reg value into the TXREG1 but no output on pin RC7. I am testing this with the pickit 2 usart tool and the logic tool. the pin is dead.

 

[Mike - K8LH]

Perhaps this "cycle accurate" fixed delay subsystem may come in handy in the future;

        cblock  0x000
delayHi
        endc

;==================================================================
;  K8LH DelayCy() subsystem macro generates four instructions     =
;==================================================================
        radix   dec
clock   equ     4               ; 4, 8, 12, 16, 20 (MHz), etc.
usecs   equ     clock/4         ; cycles/microsecond multiplier
msecs   equ     clock/4*1000    ; cycles/millisecond multiplier

DelayCy macro   delay           ; 11..327690 cycle range
        movlw   high((delay-11)/5)+1
        movwf   delayhi
        movlw   low ((delay-11)/5)
        call    uDelay-(((delay-11)%5)*2)
        endm

;******************************************************************
;  example code for simulation testing                            *
;******************************************************************
        org     0x000
SimTest
        DelayCy(200*usecs)      ; <- put simulator PC here
        goto    $               ; <- put simulator break point here

;******************************************************************
;  K8LH DelayCy() 16-bit uDelay (11..327690 cycle) subroutine     *
;******************************************************************
        nop                     ; entry for (delay-11)%5 == 4
        nop                     ; entry for (delay-11)%5 == 3
        nop                     ; entry for (delay-11)%5 == 2
        nop                     ; entry for (delay-11)%5 == 1
uDelay  addlw   -1              ; subtract 5 cycle loop time
        skpc                    ; borrow? no, skip, else
        decfsz  delayhi,F       ; done?  yes, skip, else
        goto    uDelay          ; do another loop
        return                  ;

;******************************************************************
        end

You just need to keep in mind that the range of delays is 11..327690 cycles. That's 11..327690 usecs with a 4-MHz clock, or 6..163845 usecs with an 8-MHz clock, etc. If you need longer durations you can use multiple DelayCy() macro calls or you could increase the subsystem 5 cycle loop time. Here's an example subsystem with an 8 cycle loop time (11..524298 cycle range);

        cblock  0x000
delayHi
        endc

;==================================================================
;  K8LH DelayCy() subsystem macro generates four instructions     =
;==================================================================
        radix   dec
clock   equ     4               ; 4, 8, 12, 16, 20 (MHz), etc.
usecs   equ     clock/4         ; cycles/microsecond multiplier
msecs   equ     clock/4*1000    ; cycles/millisecond multiplier

DelayCy macro   delay           ; 11..524298 cycle range
        movlw   high((delay-11)/8)+1
        movwf   delayhi
        movlw   low ((delay-11)/8)
        call    uDelay-(((delay-11)%8)*2)
        endm

;******************************************************************
;  example code for simulation testing                            *
;******************************************************************
        org     0x000
SimTest
        DelayCy(200*usecs)      ; <- put simulator PC here
        goto    $               ; <- put simulator break point here

;******************************************************************
;  K8LH DelayCy() 16-bit uDelay (11..524298 cycle) subroutine     *
;******************************************************************

        nop                     ; entry for (delay-11)%8 == 7
        nop                     ; entry for (delay-11)%8 == 6
        nop                     ; entry for (delay-11)%8 == 5
        nop                     ; entry for (delay-11)%8 == 4
        nop                     ; entry for (delay-11)%8 == 3
        nop                     ; entry for (delay-11)%8 == 2
        nop                     ; entry for (delay-11)%8 == 1
uDelay  addlw   -1              ; subtract 8 cycle loop time
        skpc                    ; borrow? no, skip, else
        decfsz  delayhi,F       ; done?  yes, skip, else
        goto    uDelay-6        ; do another 8 cycle loop
        return                  ;

;******************************************************************
        end

Using these subsystems with 16F mid-range devices involves changing one line in the macro and one line in the uDelay 8-bit loop subroutine (you'll find an example for a 16F1827 in the PIC Simple 8-Channel LED Sequencer Demo article);

I hope you find this information useful.

Cheerful regards, Mike

 

[Jon Wilder]

BTW...unlike PIC16F assembly, in PIC18F assembly you have an instruction known as movff. This instruction moves a value from one register direct to another register (direct-to-register write). With this instruction, you no longer have to pass everything through the accumulator (i.e. the "W" register).

movff 0x20, TXREG

The above instruction will move the contents of register location 0x20 into register TXREG.

 

[Mike - K8LH]

The 18F 'movff' instruction also doesn't affect the STATUS register.

Many differences between families... For example, automatic context save/restore on 12F/16F "enhanced mid-range" devices includes WREG, STATUS, BSR (bank select register), FSR0/INDF0, FSR1/INDF1, and PCLATH registers.

The only "down side" I've found so far with this level of context save/restore is when I've dedicated one of the FSRs to the ISR. Fortunately, unlike the 18F family, you can access (and alter, if necessary) the context "shadow" registers.

Mike

 

[pixman]

I found something funny last night. I'm using a pic18f47j53. I set up all the config bits and ran a simple led blink, When I ran it on sim in Mplab,
The led would not change state. I was using porta,0 and porta,1. in the watch window porta would not change state. I checked the config bits,adcon bits
and even cmcon. all were correct.
I decided I will simulate it on the pic itself. and it works.Leds blink and delay timer works perfect. But Mplab still says porta is off.

 

[Mike - K8LH]

Not sure what version of MPLAB you're using but my v8.92 shows only partial SIM support for the 18F47J53 device.

 

[pixman]

That is more than likely the problem, I thought it had something to do with the MCLR pin. It is only MCLR and has to be used. there is no software bit to turn it off.

 

[atferrari]

Have you tried to simulate just the code that materializes that delay?

When I moved to the 18F family I just rewrote few canned routines to never have to look back.

Prior that, when I moved from my first PIC, the 16C57, I learnt that trying to enter a new family still looking at the one you are leaving behind is not good. I am not saying, forget (I did) but consider the new one, simulate and go.

Even when you change between micros, check if any differences does exist, simulate and move on.

That made my life easier, albeit, with 16F I became very proficient (but not happy) selecting banks et al.

BTW, in both oportunities I read the documents showing what to take into account in the transition. That really HELPS.

A nice percentage of questions in forums could be spared if the OP to be would simulate his code first. Been there...

 

[Mike - K8LH]

I agree, in part. That is, I agree that simulation is an important step in the development process and I suspect that's why I'm disappointed that Microchip has fallen so far behind in simulator support for newer, more recent devices. I also agree that you have to take a close look at differences between devices in the same family.

As for "moving on" to other families... I think it's important to learn about and become proficient on the different device families but I can't imagine giving up one family for another. I suppose I might feel differently if Microchip were to match feature-for-feature between families, but they don't. That is, the 18F family doesn't have 8-pin or 14-pin devices, and, there are plenty of features found in some of the newer 12F/16F family devices that aren't available in 18F family devices (AFAIK). Myself, I use both 18F family (16-bit core) devices and 12F/16F family (14-bit core) devices, when the advantages/features of those devices match my design requirements, and I've even used 12-bit core devices (10F200, etc.) a couple times (though I consider the 12-bit core architecture kind of crippled).

Mike

 

[atferrari]

As for "moving on" to other families... I think it's important to learn about and become proficient on the different device families but I can't imagine giving up one family for another. I suppose I might feel differently if Microchip were to match feature-for-feature between families, but they don't. That is, the 18F family doesn't have 8-pin or 14-pin devices, and, there are plenty of features found in some of the newer 12F/16F family devices that aren't available in 18F family devices (AFAIK). Myself, I use both 18F family (16-bit core) devices and 12F/16F family (14-bit core) devices, when the advantages/features of those devices match my design requirements, and I've even used 12-bit core devices (10F200, etc.) a couple times (though I consider the 12-bit core architecture kind of crippled).

Mike

Yes, you are right Mike.

The point I tried to stress, thinking of the transition, is: face the new, whatever it is, as new, write minimal code, simulate and go. That principle of "divide and conquer" is esential here.

 

[pixman]

I have found the Data Sheet is the only way to find the answers. The board I have, has a USB connected to usart1 and I am using usart2. To setup
usart2 is different than any of the other 18f I have worked with, mainly because you have to map the pins you want to use. Using the data sheet I found all I needed and got it working. Yes it does take a little bit longer but next time you know what to look for.

 

[atferrari]

I have found the Data Sheet is the only way to find the answers.

A nice epiphany moment! Now you know!