Maximum frequency output from a PIC

[NickMu]

Hi Henrik,

It is funny but I used both your suggestions in my younger days. I also used a frequency to voltage convertor (LM2917 if my memory serves me right). Each has its limitations and advantages.
Since I started using PICs I pledge to myself that I will replace any of the analog or logical components that can be replaced especially when it comes to timing circuits. In this case it is so easy to change one line in the code to generate a different frequency or duty cycle with much better accuracy than analog circuits. I also pledge to myself to learn as many special functions of the PICs as I possibly can. Like I said before I’m a slow learner but nobody bits me when it comes to forgetting things (LOL).
I am aware that some signal conditioning will be necessary but that is my last of the worries. I recently discovered those single gate chips in small packages and I’m sure that a couple resistor and capacitors combined with a trigger smith will do fine.
At least knowing now that it can be done using a regular PIC I will research this avenue and keep you posted.

Thank you again for the valuable input.

Regards,

Nick

[HenrikOlsson]

Hi Nick,
Ah, ok, it's the I've got a hammer now everything looks like a nail kind of thing ;-)

Well, as with most things there are more than one way to skin a cat. What I'd do is probably something like this (for 12F683 but not tested):

' CMCON, ANSEL, TRIS, whatever not shown here!

oldCount VAR BYTE
LED VAR GPIO.0

oldCount = 0    'Clear count
LED = 0    ' Turn off LED

' Set TMR0 up as a counter, signal fed into T0CKI pin
OPTION_REG.5 = 1

Main:
   If TMR0 <> oldCnt THEN    ' There has been pulses since last time we checked
       LED = 1
   ELSE
       LED = 0
   ENDIF

   oldCnt = TMR0      ' Store current count

' Now wait a bit to allow any new pulses to "tickle" the counter.
' Shortest PauseUs time @8Mhz is 12us.
' If faster response is needed replace with a copule of @NOP (each taking 500ns @8MHz) or try without any delay at all. 

   PauseUs 25  ' Or go do something else usefull instead....

Goto Main

Anyway, that's one idea....

/Henrik.

[NickMu]

Hi Henrik,

Thank you for the sample code.
I will do some “hammering” tonight and report the results.

Regards,

Nick

[NickMu]

Results after the “hammering” session today.

Testing setup as follows:

One PIC12F683 acting as Tx module. It output bursts of 15 mS 500Khz carrier on CCP1 pin (pin 5) followed by 5mS no carrier. Pin 2 of the PIC is high when carrier ON and low when carrier is OFF.
Second PIC12F683 acting as Rx is connected to the same 5V supply and has its TOCKI pin (pin 5) connected to CCP1 pin of the Tx PIC. Pin 2 of this PIC drives a LED.

After adding some configuration lines and fix some oldCount speling I ran few simple tests to make sure the connections and configs are OK I ran the sample code.
Unfortunately it did not work and the problem was on the Rx side. Monitoring the signals from Tx they were what they should be. Rx will output some very random signals or no signals at all.

So I started messing with the code and try few alterations of the Rx program. I realized that some different handling of TMR0 and oldCount needs to be implemented. I have to confess that some of the results did not make sense to me at the time but by pure luck (I left a code line behind in the first WHILE / WEND loop got some meaningful results).
I do not know enough about the insides of the WHILE / WEND loop but, after violating its condition. I also think I broke few other rules of programming and according to the well known rule if something works there must be at least two mistakes that compensate each other.
The Rx and Tx codes that follow are working and my old analog scope shows perfectly matched signals on the Tx and Rx PICs.
Tx code:

@ device  pic12F683, intrc_osc_noclkout, wdt_on, mclr_off, protect_off
DEFINE OSC 8           ' We're running at 8 Mhz

OSCCON=%01110111        ' 8MHz internal osc
ANSEL   = 0             ' Digital only for all PortA pins
TRISIO=%00100000        ' Make PORTA outputs
out     var         GPIO.5
CCP1CON = %00001100     ' Normal PWM 
PR2 = 3             ' 1MHz output @8MHz system clock
CCPR1L = 2            ' 50% Dutycycle
CCP1CON.5 = 0
CCP1CON.4 =0
    T2CON.2 = 1 
Main:
    high out
    T2CON.2=1         ' Osc ON
    PAUSE 15
    low out
    T2CON.2=0         ' Osc OFF
    PAUSE 5
Goto Main

Rx code:

@ device  pic12F683, intrc_osc_noclkout, wdt_on, mclr_off, protect_off
DEFINE OSC 8           ' We're running at 8 Mhz

OSCCON=%01110111        ' 8MHz internal osc
ANSEL   = 0             ' Digital only for all pins
TRISIO=%00100100        ' Make PORTA outputs

oldCount    VAR     byte
LED         VAR     GPIO.5

    oldCount = 0    'Clear count
    LED = 0    ' Turn off LED

' Set TMR0 up as a counter, signal fed into T0CKI pin

    OPTION_REG.5 = 1

Main:
    While TMR0 <> oldCount  ' There has been pulses since last time we checked
    high led
    oldCount = TMR0      ' Store current count
    Wend
    low led
    oldCount =0 
    TMR0=0     
    While oldCount=TMR0
    low led
    wend
    GOTO main

Can somebody explain me why this code is working?

Regards,

Nick

[HenrikOlsson]

Hi Nick,
Sorry about the typo, told you I didn't test it though.

Currently I have no idea why my original code (less the typo) did not work while your new one does. I just tried it here, again with two 12F1840's so that MIGHT have something to do with it but I don't think so. I also figured out that once you've enabled PWM mode on the CCP pin you can't control that output manually. So in order to force the PWM output low during the OFF period of the carrier you have to disable the CCP module and THEN force it low, I've implemented that in the TX-code below:

' ***************************************************************
' Device Fuses
' ***************************************************************

#CONFIG
   __config _CONFIG1, _FOSC_INTOSC & _WDTE_ON & _PWRTE_ON & _MCLRE_OFF & _CP_OFF & _CPD_OFF
   __config _CONFIG2, _PLLEN_OFF & _STVREN_ON & _BORV_LO & _LVP_OFF
#ENDCONFIG

' ***************************************************************
' Compiler directives
' ***************************************************************
DEFINE OSC 8               ; We're running at 8Mhz

' ***************************************************************
' Variables and aliases
' ***************************************************************
i VAR BYTE
LED VAR PortA.4

' ***************************************************************
' Initialization
' ***************************************************************

OSCCON   = %01110000        ' 8MHz internal osc
ANSELA   = 0                ' Digital only for all PortA pins
TRISA    = %00000000        ' Make PORTA outputs

CCP1CON = %00001100     ' Normal PWM 
PR2 = 3                 ' 500kHz output @8MHz system clock
CCPR1L = 2              ' 50% Dutycycle
CCP1CON.5 = 0
CCP1CON.4 = 0

' ***************************************************************
' Actual program
' ***************************************************************

' Show that we're up and running.
For i = 0 to 9
    Toggle LED
    Pause 200
NEXT

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

    T2CON.2 = 0             ' Timebase OFF
    CCP1CON = %00000000     ' Disable PWM to regain control of PortA.2
    PortA.2 = 0             ' Force output low to prevent saturation of coil
    PAUSE 5

Goto Main

For the RX-side I did this, which is pretty much exactly like I wrote it earlier. I found that I could ditch the delay to speed up the response time since the exection time for the loop is longer than the PWM-period. If you change the frequency you may need to add some delay.

' ***************************************************************
' Device Fuses
' ***************************************************************

#CONFIG
   __config _CONFIG1, _FOSC_INTOSC & _WDTE_ON & _PWRTE_ON & _MCLRE_OFF & _CP_OFF & _CPD_OFF
   __config _CONFIG2, _PLLEN_OFF & _STVREN_ON & _BORV_LO & _LVP_OFF
#ENDCONFIG

' ***************************************************************
' Compiler directives
' ***************************************************************
DEFINE OSC 8               ; We're running at 8Mhz

' ***************************************************************
' Variables and aliases
' ***************************************************************
oldCnt VAR BYTE
i VAR BYTE
LED VAR PortA.4

' ***************************************************************
' Initialization
' ***************************************************************

OSCCON   = %01110000        ' 8MHz internal osc
ANSELA   = 0                ' Digital only for all PortA pins
TRISA    = %00000100        ' T0CKI is input, rest outputs

' ***************************************************************
' Actual program
' ***************************************************************

OPTION_REG.5 = 1            ' TMR0 as counter
oldCnt = 0
TMR0 = 0

' Show the world that we're alive
For i = 0 to 9
    Toggle LED
    PAUSE 200
NEXT

Main:
    IF TMR0 <> oldCnt THEN
        LED = 1
    ELSE
        LED = 0
    ENDIF
    
    oldCnt = TMR0
   
Goto Main

I'm going to try to add two screen-grabs from the scope. Last time I did the uploader didn't work but hopefully that's fixed by now. Nope the bloody thing still doesn't work, sorry but you'll have to trust me that it does work here.

/Henrik.

[NickMu]

Hi Henrik,

Thanks again for your patience with me.
Your code makes much more sense to me so I will try it again tonight. I can only guess that as long as the execution time of the main loop is longer than the carrier period we should be fine. If that is not true there should be short glitches during the carrier ON period. Increasing the carrier frequency should be fine while going lower might require some delay.
I can only hope that first time it might have been a stupid mistake on my side.
Now that the setup is fine-tuned there should be no reason why it should not work.
I will report the findings as soon as I have results.

Regards,

Nick

[HenrikOlsson]

Hi Nick,
Yes, as long as the loop takes longer to exectute than the period time of the PWM signal (2us in this case) it'll work without additional delay in there. When running at 8MHz each ASM instruction takes 500ns so there's really only time 4 instructions in this case. The Goto Main takes 2 and the jump caused by the IF-THEN takes 2 so that's 4, then we have the rest so it's pretty safe to run it without any delay.

Here are the screenshots I mentioned:




/Henrik.