Proton BASIC Community

Hi

I'm have issues with a new board. The code seems right in a VSM but cannot even get a blincky led on the dev board

So asking if anyone has an example of the 18f13k22 running on its internal xtal at 64mhzor even 48mhz

Thanks

Tim

Try this piece of code Tim. I don't have a PIC18F13K22 device at hand, but it looks as though it should work, based upon the datasheet.

Never, never, trust simulators too much, especially Isis because it gets the finer points of the microcontroller's operation incorrect. I've had this situation a lot in the past with it when operating different devices at different speeds with their internal oscillator.

Hopefully, the code below will work, but if not, it may give you some pointers:

    Device = 18F13K22
    Declare Xtal = 64
'
' Setup USART1
'   
    Declare Hserial_Baud = 9600
    Declare HRSOut_Pin = PORTC.6
   
'--------------------------------------------------------------------------------------
' A test of a loop transmitting text at a specified Baud rate
' If the text is received on the serial terminal correctly, the oscillator is running at the correct speed
'
Main:
    Osc_64MHz()                     ' Set the device to run at 64MHz with its internal oscillator
   
    Do                              ' Create a loop
        HRSOutLn "Hello World"      ' Transmit the text at a specific Baud rate
        DelayMS 255                 ' A small delay between transmissions
    Loop      
   
'--------------------------------------------------------------------------------------
' Setup the internal oscillator to run at 64MHz
' Input     : None
' Output    : None
' Notes     : None
'
Proc Osc_64MHz()
    OSCCON  = %01110000
    OSCCON2 = %00000100
    OSCTUNE = %01000000
EndProc

'--------------------------------------------------------------------------------------
' Setup the config fuses for internal oscillator
'
Config_Start
    FOSC = IRC          ' Internal RC oscillator
    PLLEN = Off         ' PLL is under software control
    PCLKEN = On         ' Primary clock enabled
    FCMEN = Off         ' Fail-Safe Clock Monitor disabled
    IESO = Off          ' Oscillator Switchover mode disabled
    PWRTEN = Off        ' PWRT disabled
    BOREN = SBORDIS     ' Brown-out Reset enabled in hardware only (SBOREN is disabled)
    BORV = 19           ' VBOR set to 1.9 V nominal
    WDTEN = Off         ' WDT is controlled by SWDTEN bit of the WDTCON register
    WDTPS = 32768       ' Watchdog Timer Postscale. 1:32768
    HFOFST = Off        ' The system clock is held Off until the HFINTOSC is stable.
    MCLRE = On          ' MCLR pin enabled, RA3 input pin disabled
    STVREN = On         ' Stack full/underflow will cause Reset
    LVP = Off           ' Single-Supply ICSP disabled
    BBSIZ = Off         ' 512W boot block size
    XINST = Off         ' Instruction set extension and Indexed Addressing mode disabled
    Debug = Off         ' Background debugger disabled, RA0 and RA1 configured as general purpose I/O pins
    Cp0 = Off           ' Block 0 not code-protected
    CP1 = Off           ' Block 1 not code-protected
    CPB = Off           ' Boot block not code-protected
    CPD = Off           ' EEPROM not code-protected
    WRT0 = Off          ' Block 0 not write-protected
    WRT1 = Off          ' Block 1 not write-protected
    WRTC = Off          ' Configuration registers not write-protected
    WRTB = Off          ' Boot block not write-protected
    WRTD = Off          ' EEPROM not write-protected
    EBTR0 = Off         ' Block 0 not protected from table reads executed in other blocks
    EBTR1 = Off         ' Block 1 not protected from table reads executed in other blocks
    EBTRB = Off         ' Boot block not protected from table reads executed in other blocks
Config_End


i have an ask in my mind(you know  i am new for old and new pic18 series)
could you explain/teach it ? please.

HFIOFS bit of OSCCON register is indicating/giving an info that HFINTOSC stable or not stable;,

if HFINTOSC frequency is stable and what we will/can do?
if HFINTOSC frequency is not stable and what will/can do ?
i think we have to do something so what is this?
for what purpose(task) should(must) we use(use)?

If you're using a peripheral where the stability of the clock speed matters (like a UART), then you should wait for it to be stable.

Other than that it probably doesn't matter.

A good question.

I sometimes wait in a While-Wend loop for the internal oscillator to become stable, or the PLL to become stable, by testing bits of the OSCCON SFR. However, the HFOFST config bit is set for the device to wait for the oscillator to become stable before it runs, so it shouldn't need them.

Sometimes, all it takes is a small delay of a few 10s of milliseconds after setting up the oscillator SFRs so it gives time for the stability. i.e. DelayMs 100 etc...

it is mean HFIOFS bit is just readable bit ..
we can check/watch it often time (it depent condition off in our codes a or lot point) HFIOFS  bit value is 1 or 0
thank you.

Thanks Les

I can confirm, its working. I was confused about the fuse settings for the PLL not being set. Then looked at the data sheet and saw you set it in the OSCTUNE reg

Thanks, I can proceed now.

Tim

Quote from: okmn on Apr 22, 2021, 05:48 PMi have an ask in my mind(you know  i am new for old and new pic18 series)
could you explain/teach it ? please.

HFIOFS bit of OSCCON register is indicating/giving an info that HFINTOSC stable or not stable;,

if HFINTOSC frequency is stable and what we will/can do?
if HFINTOSC frequency is not stable and what will/can do ?
i think we have to do something so what is this?
for what purpose(task) should(must) we use(use)?

Personally, I don't generally monitor this bit where it is available but it depends on the circumstances, for example...
If you are using an external crystal then there is no need to monitor it.
If you are using the internal oscillator then as others have said if you are performing functions (i.e. data transmit/receive) that are timing critical then it is better for the oscillator frequency to have stabilised first. If there is a lot of code to execute before the timing critical code then you may not need to monitor it as that code may take long enough to execute that the oscillator will have stabilized by the time the timing critical code is reached, alternatively, as previously stated you could use a long delay instead of monitoring the frequency stability bit.

However, while using a long delay may be practical at initial power on it may not be so practical during operation. I may be wrong but as I recall where it is most useful and the primary reason it is provided is to do with power saving, i.e. when you enter sleep the main oscillator is often turned off and a special low power oscillator used to keep the PIC running. Consequently, every time the device wakes the main oscillator is turned on again and will take time to stabilise, therefore if your main oscillator is set to the HF internal oscillator and you have timing critical code to execute it may be wise to monitor the clock stabilisation bit and if necessary wait until it indicates stability before performing certain operations.