Maximum frequency output from a PIC

[Art]

Hi Nick,
Great post, and objective I've never tried to get out of using an Xtal before,
so hadn't previously considered some of the difficulties coming up with your own timing.

I know what you mean, playing with a phone that almost does everything doesn't motivate
me to build my own computers,
I do have to come back very soon for a project... kind of have to because I want the thing I'm making

If it is just a perfectly linear program that can boss the chip out of running any other program,
such as for a power supply or something... I think as things warm up you lose timing of the internal clock,
same as if there was voltage fluctuation.
but for the exercise... with the new rules as I understand them,
I would try a program that can interrupt itself with an output pin
connected to the portB interrupt pin. Then you could introduce a linear delay at the interrupt
vector, and control the delay before turning the interrupt back on.
I don't know if the jump to the interrupt vector is essentially a GOTO or not.
It jumps to vector 4, which would not be as fast as resetting the program counter to zero vector.
and potentially some inaccuracy caused if there's any variation in the response time to the interrupt.
Cheers, B.

[NickMu]

Hi Art,

I agree with you on your points. One must be careful when simplifying things, like we’ve been doing in this thread, depending on the application.
For my application 10% accuracy on frequency and duty cycle will be fine. The beauty of what we did here is that instead of doing it the old fashion way, trying to match RC values for target frequency and duty cycle, we used the built in oscillator (which in my opinion is more precise and reliable than RC setup even when using 1% components) and use the code to make any changes. In the process the component count, board space and I’m sure cost went down. I didn’t dream when I started this that (excluding PSU section) with only two PICs, a couple of resistors and capacitors and one Mosfet I can wirelessly transfer power with good efficiency and have the grounds ready for data transfer.
As for your suggestion at the end of your post you used the magic word (again I’m talking for myself only) INTERRUPTS.
Yes, they are next on my list and I will start researching how to use them. As soon as I have a clearer image of interrupts I will try to see if they will do any better on my Rx module. I have the feeling that they will eliminate some if not all the jitter but not the delay.

Regards,

Nick

[Art]

If you are still going on it, you probably know not to bother looking at BASIC interrupt in this case.
Usually there is time taken saving and restoring context, but that could likely be avoided
if the program is under 2K, and doesn't care where it was up to when the interrupt was called.

I will be writing for a 16F877 soon, and would see how fast I could just cycle a pin,
but don't have anything to measure it with.

[NickMu]

As the wise man once said “necessity is the mother of invention”.
I’m sure that it will take you no time to build a “tool” to solve your problem. What about employing one more PIC to do the job for you? Set it up to count incoming pulses from your DUT for a set period of time and send the results to a LCD or to your preferred PC communication terminal for a visual. You just built yourself a home made, dirty cheap frequency counter ready to solve your problem now and help you in the future.
Just a thought.
Some experimenting and results in that matter were done in the beginning of this thread but unless you are starting with a really high clock flexibility is not that great. I’m not sure if the Assembly approach will bring any more advantage but, again it is out of my league.


Regards,

Nick

[Art]

Looks like I'll have to.
I always thought if I have a 5 Volt square wave,
that my multimeter would measure it as 2.5 Volts.
I never considered the sampling frequency of the multimeter has
no connection with the frequency of the signal being measured.

[NickMu]

Hi again,

I’m trying to move what I learned last week to a larger PIC (PIC16F819) which I have a lot of leftovers and I’m trying to make use of. I’m also trying to increase my output frequency by using a 16MHz oscillator.

Based on what the data sheet shows I should have about the same setup as I had with PIC12F683 except that I could select between RB2 and RB3 as my output.

With the above code I get good output on RB1 (led out which proves that the system is running) but I do not get any output on RB2 or RB3. I was hoping that it will go by default on one of them.

@	device  pic16F819, wdt_off, hs_osc, pwrt_on, mclr_off, lvp_off, protect_on
DEFINE OSC 16         ' We're running at 16 Mhz

ADCON1=%01001110            ' Digital only for all pins

led     var         PORTB.1
i       var         byte

CCP1CON = %00001100     ' Normal PWM 
PR2 = 3            
CCPR1L =0         
CCP1CON.5 = 1
CCP1CON.4 =1

For i = 0 to 9
    Toggle LED
    Pause 500
NEXT

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

The data sheet states:

The CCP module’s input/output pin (CCP1) can be
configured as RB2 or RB3. This selection is set in bit 12
(CCPMX) of the Configuration Word register.

I have no idea how to change this setting and if this is the reason why I get no output.
Is there anything that I should do differently?

Thank you in advance for any input.

Nick

[HenrikOlsson]

Hi Nick,

1) Add _CCP1_RB2 or _CCP1_RB3 to your line of config directives in order to select which pin to be used as the CCP1-pin. But yes it WILL default to one of them.

2) When the PIC starts all pins are set to be input. You need to set RB2 or RB3 to be an output by clearing the coresponding bit in the TRISB register. The reason the LED works is because commands like TOGGLE, HIGH and LOW handles clears the TRIS-bit for you - each and every time the command is executed.....

3) Not that it matters but anyway, as far as I can see the 16F819 can not do 16MHz on its internal oscillator, up goes the partcount you said you want to keep low. If running at 16MHz is the main reason for switching to the 16F819 you could just as well stuck that 16MHz oscillator on the 12F683.

/Henrik.