Maximum frequency output from a PIC

[NickMu]

I've added the two extra configs and I got output on RB2.
I did not have time to play more but I will do as soon as I will return from a two weeks vacation.

Regards,

Nick

[Art]

You could try putting the code you want to be called the fastest, closest to zero vector.
Labels called with a Goto command causes the program counter to start looking for your label from zero,
so the closest it is to zero, the faster it is found, and run.

So without looking at anything else about your code:

// the following is not run time code, so who cares…
@	device  pic16F819, wdt_off, hs_osc, pwrt_on, mclr_off, lvp_off, protect_on
DEFINE OSC 16         ' We're running at 16 Mhz
led     var         PORTB.1
i       var         byte

// jump to config vector
Goto Config

Main:
    high led
    CCP1CON = %00001100     ' Normal PWM mode
    T2CON.2 = 1             ' Timebase ON
    PAUSE 15

    low led
    T2CON.2 = 0             ' Timebase OFF
    CCP1CON = %00000000     ' Disable PWM to regain control of PortA.2
    PAUSE 5
Goto Main


Config:
ADCON1=%01001110            ' Digital only for all pins
CCP1CON = %00001100     ' Normal PWM 
PR2 = 3            
CCPR1L =0         
CCP1CON.5 = 1
CCP1CON.4 =1

For i = 0 to 9
    Toggle LED
    Pause 500
NEXT

// run main program
Goto Main

[NickMu]

This is a nice tip Art.
I will only have the chance to try it after my well overdue vacation, just for fun.

Just so I understand your tip correctly for the sample code presented it will make the GOTO jump in the main loop much faster in which case the main loop will be faster and the second half of the loop will be closer to the target 5 mS?

For my particular application this is not a big advantage but for time sensitive applications it might make a difference. All I need in this case is to create a 20 mS frame with a 15 / 5 mS ratio.
I can only guess that the Rx program might benefit from that but in my case the really fast action happens behind the scene and I think that the system is pushed to its maximum.

I was always under the impression that each PBP command has a fixed amount of execution time but your suggestion proves me wrong.

How is your project going?

One correction to my statements few posts ago: I mentioned that I will try to increase my available frequencies by employing a PIC16F819 with higher frequency external oscillators to cover 2 MHz – 5 MHz band but I just realized that my math was wrong. For some reason I was under the impression that you can get a maximum Fosc / 4 out of PWM module but the formula proves me wrong again, it is only Fosc / 8. I think that I was biased by the fact that the Fosc / 4 is available on clock out feature.
Anyway recycling few boards that will only collect dust in my garage is still good enough even though the expected results are a bit lower.

Regards,

Nick

[Art]

Yes, as I understand, the major delay per cycle is the "Goto Main".
It's not my suggestion that proves you wrong, it's you timing it

Then if you work out how long the Goto takes to execute, you can
subtract that from the 5 value in your PAUSE 5 command, and you're
fine until you put anything between the start of your program and the
end of main, or also if you use a beefy command like sound, or serin/out
etc., as they put code in the front of your program for the same reasons
(they want to execute fast also).

[HenrikOlsson]

Hi,
I'm definitely no expert on the low level stuff but I do think there's some misunderstaning / confusion going on here.

When you execute a GOTO Label it's NOT like the program starts from the top and then "searches" thru the code until it finds the Label to which you want to GOTO.

The physical adress of the piece of code starting "at" Label is known when the program is compiled so the GOTO Label is simply replaced with GOTO $xxxx where xxxx is the physical adress in program memory where the particular piece of code is located. A GOTO always takes TWO instruction cycles, no more no less.

But, some PICs have its program memory divided into pages and when a GOTO is executed it's important that it GOTO's the adress in the correct page. The compiler handles this for you when needed (that's the warning you see sometimes, Code crosses page boundries or something like that). Making sure you're in the correct page does take a couple of instructions as well so all in all the GOTO CAN take more than 2 instruction cycles but not much. So it CAN make a (small) difference rearanging the routines so it doesn't need to jump across page boundires when executing a GOTO but most of the time you simply wouldn't care.

In this particular case the GOTO Main will take 2 cycles. Only if the Main routine would end up starting in one page and ending in the next would it take more than 2 cycles.

Interrupt service routines are one thing where it can matter. Since the hardware interrupt vector is at adress $0004 (IIRC) it makes sense (if you're looking for the absolute best performance) to place your interrupt service routine at the top of the program (and jump over it of course). If you don't do this it MIGHT end up in another memory page and you'll loose a few cycles every time it needs to set the correct page bits before jumping to the ISR.

Again, I'm no expert so I might very well have some details wrong - I'm happy to be corrected.

/Henrik.

[rsocor01]

Henrik,

I don't have the definitive answer either, but I think that what Art is suggesting makes sense to me. I have tried moving to the beginning of the program subroutines that I use a lot in the program and the used programming code space is reduced by a good number of bytes. So, I assume that the program is also executing faster. I believe that this has something to do with the way the program memory is organized in pages in many PICs.

Robert

[HenrikOlsson]

Hi,
On the 12F683 and 16F819 there is only one page of program memory so it doesn't (or shouldn't if my reasoning is correct) matter where you put anything because there will never be a need to switch pages.

If I understand what Art wrote correctly he's basically claiming that the "further" the GOTO jump is, the longer it takes and the further "down the list" your subroutines are placed the longer it takes to GOSUB them because the program counter starts "searching for them" from the beginning of the program. I don't think that is correct - neither on PICs with a single memory page nor on those with multiple pages.

If using a PIC with the program memory spanning several pages and it has to jump (GOTO or GOSUB) from ona page to another then the compiler will insert code to make sure the correct page is selected before executing the GOTO but it either does that or it doesn't and that piece of code (to select the correct page) will be always take the same amount of time (a couple of cycles I imagine), it doesn't matter where or "how far" it is going to jump.

/Henrik.

EDIT: Robert, which PIC did you use in the project where you moved the subroutines?