 |
 |
| View previous topic :: View next topic |
| Author |
Message |
dmilrtime
Joined: 17 Mar 2022
Posts: 6
|
| Moving from PIC16F1517 to PIC16F15275 - Oscillator Settings |
 Posted: Thu Mar 31, 2022 4:46 pm |
 |
|
Hello All,
I have some older code that has been in production and not touched since 2015ish. We have been using the PIC16F1517 for a years and now with supply chain issues that everyone is facing we need to port the project to a newer PIC.
The PIC16F15275 is a newer PIC that is pin compatible with the 1517 and for the most part register compatible. Where I am having an issue is with the #fuse directives.
The legacy 1517 project has the following:
#fuses INTRC_IO,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT, BORV25, PROTECT
The 15275 does not support PUT, BORV25 but I found the equivalents for them. My specific issue is around the INTRC_IO vs the various OSC Fuse flags for the 15275
Our original code uses the INTRC_IO flag and configured for the Internal RC OSC to be 16MHz. I am trying to figure out which of the fuse flags for the 15275 would configure the Internal OSC for 16MHz. I have tried
#fuses RSTOSC_HFINTRC_32MHZ,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT_64MS, BORV28, PROTECT
Then I have also tried:
setup_oscillator(OSC_HFINTRC_16MHZ | OSC_HFINTRC_ENABLED);
None of these or any combo of these have set the OSC to 16MHz. I know because some of the other code that is relying the 16MHz clock.
Anyone have any experience with setting the Internal OSC for the 15275? Any tips that might help me out?
Thanks |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Mar 31, 2022 5:53 pm |
|
|
Try this:
| Code: | #include <16F15275.h>
#use delay(internal=16M)
//====================================
void main()
{
while(TRUE);
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Fri Apr 01, 2022 1:37 am |
|
|
As another comment, get rid of the PROTECT fuse, until you have finished
the development and have the chip working.
PROTECT should only ever be set on the final 'running' version.
If you enable it during development, it significantly reduces the life of
the chip. With this disabled, the programmer can block erase only the
parts that need to change in the memory. With this set, the programmer
has to do a full bulk erase of the whole chip for every single change you try.
Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!....
| Code: |
#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)
|
Remember also you can 'see' what is actually done by simply looking at
the fuses in the .lst generated by an attempt, rather than having to actually
waste an erase cycle each time.
In fact the reason you have problems is the way this chip's oscillator
is done. There is no fuse option to actually directly select 16MHz. Instead
the HFINTOSC is setup to run at 1MHz, and then the chip is told to run
at 16MHz with the OSCFRQ bits.
Table 11-1 in the sheet. The above compiler setting correctly sets all
these.
At the start of the main:
| Code: |
0014: MOVLB 11
0015: CLRF OSCTUNE
0016: CLRF OSCEN
0017: MOVLW 04
0018: MOVWF OSCFRQ //100 to OSCFRQ
0019: MOVLB 3E
001A: CLRF 38
001B: CLRF 43
001C: CLRF 4E
001D: CLRF 59
001E: CLRF 64
|
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Fri Apr 01, 2022 5:42 am |
|
|
re: | Quote: | Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!.... |
#fuses INTRC_IO,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT, BORV25, PROTECT
My 'gut' thinks the last option would be the final one.
The compiler's 'parser' should decode the line from left to right
so. first it configures for 'noprotect' then later for 'protect'
well that's my guess...
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Apr 01, 2022 7:48 am |
|
|
| Just look at the end of the .LST file to see which one prevails. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Fri Apr 01, 2022 11:40 am |
|
|
Why bother?.
The point is that he should not be using protect while experimenting.
Better to just put the NOPROTECT as the last value, and just change this to
PROTECT on the final version....
I didn't bother to check, since 'better to sort it out'....  |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Fri Apr 01, 2022 12:21 pm |
|
|
Why use either one? Isn't NOPROTECT the default?
If developing something for the "MARKET" can I see it, but
certainly not during development. I would avoid them totally till final.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Fri Apr 01, 2022 12:35 pm |
|
|
I can't recall ever using PROTECT, though in the good old days, alarm panel mfrs would sand the numbers off the DIPs, GM had DELCO numbers and Heathkit had their part numbers.
You could read a PIC16C84 even if 'protected'...then Microchip got fancy...sigh...
I miss the old days ! |
|
|
dmilrtime
Joined: 17 Mar 2022
Posts: 6
|
|
| Posted: Fri Apr 01, 2022 4:11 pm |
|
|
Thanks for the info and the tip on the PROTECT fuse. I am used to blowing these fuses at Production programing time not when I compile and load the code. I didn't realize what that meant until now.
While I was working on the OSC issues my last piece that doesn't want to port very well is the Serial Port.
| Code: |
#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);
|
When I compile the setup_uart() function gives a "Missing a comma" error. The include file has 3 possible options for the setup_uart() function
| Code: |
///////////////////////////////////////////////////////////////// UART
// UART Prototypes:
_bif void setup_uart(int32 baud);
_bif void setup_uart(int32 baud, int8 stream);
_bif void setup_uart(int32 baud, int8 stream, int32 clock);
|
I tried all three options:
setup_uart (115200, PC); - Missing comma error
setup_uart (115200, PC, 16000000); - Function used but not defined error
Any tips on what I am missing to get the Serial Port to work as expected?
Thanks again for the help. This should be a simple port but for some reason it's not so straight forward.
| Ttelmah wrote: | As another comment, get rid of the PROTECT fuse, until you have finished
the development and have the chip working.
PROTECT should only ever be set on the final 'running' version.
If you enable it during development, it significantly reduces the life of
the chip. With this disabled, the programmer can block erase only the
parts that need to change in the memory. With this set, the programmer
has to do a full bulk erase of the whole chip for every single change you try.
Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!....
| Code: |
#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)
|
Remember also you can 'see' what is actually done by simply looking at
the fuses in the .lst generated by an attempt, rather than having to actually
waste an erase cycle each time.
In fact the reason you have problems is the way this chip's oscillator
is done. There is no fuse option to actually directly select 16MHz. Instead
the HFINTOSC is setup to run at 1MHz, and then the chip is told to run
at 16MHz with the OSCFRQ bits.
Table 11-1 in the sheet. The above compiler setting correctly sets all
these.
At the start of the main:
| Code: |
0014: MOVLB 11
0015: CLRF OSCTUNE
0016: CLRF OSCEN
0017: MOVLW 04
0018: MOVWF OSCFRQ //100 to OSCFRQ
0019: MOVLB 3E
001A: CLRF 38
001B: CLRF 43
001C: CLRF 4E
001D: CLRF 59
001E: CLRF 64
|
|
[/code][/quote] |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Apr 01, 2022 4:37 pm |
|
|
| Quote: | #use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);
|
Are you really writing code like this ? I mean, putting a function
outside of main() or some other routine ? I mean hanging a function
out in space. |
|
|
dmilrtime
Joined: 17 Mar 2022
Posts: 6
|
|
| Posted: Fri Apr 01, 2022 4:40 pm |
|
|
| PCM programmer wrote: | | Quote: | #use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);
|
Are you really writing code like this ? I mean, putting a function
outside of main() or some other routine ? I mean hanging a function
out in space. |
No, setup_uart() is inside of main. I just showed the two lines that are of issue. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sat Apr 02, 2022 1:13 am |
|
|
The problem is he is not setting up a UART. Hence the setup_uart command
won't work... 
Key is the new chip is a PPS chip. Setting up serial using pin names, sets up
a software serial, not a hardware UART.
He needs to setup the serial with:
| Code: |
#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)
#PIN_SELECT U1TX=PIN_C6
#PIN_SELECT U1RX=PIN_C7
//This tells the compiler what pins to use for UART1
#use rs232(baud=115200, UART1, stream=PC)
//Now sets up UART1 for your serial
void main(void)
{
setup_uart(115200,PC);
//this is then happy
while (TRUE)
{
output_toggle(PIN_A0);
delay_us(500);
}
}
|
The error message is confusing. Because there is no physical UART actually
being setup, the setup_uart command gets confused. The error really should
be something like 'no UART enabled to setup'.
On some chips there is a default pin for both RX and TX, and on these
if these pins are used, the latest compilers will automatically use a
UART. However on this one (and a lot of the newer chips), the 'default'
POR value for the TX pin is an undefined pin. Hence the compiler cannot
assume a hardware UART is what is wanted.
In general with PPS chips always use PIN_SELECT before trying to setup
the device. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
