| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| Oddity in latest 18F452 header file |
 Posted: Wed Jan 12, 2005 1:26 pm |
 |
|
With the release of 3.215 or 3.216 (I think; not sure which), I found this in the 18F452.h device header:
| Code: | long CCP_1;
#byte CCP_1 = 0x15
#byte CCP_1_LOW= 0x15
#byte CCP_1_HIGH= 0x16
#byte CCP_1 = 0xfbe
#byte CCP_1_LOW= 0xfbe
#byte CCP_1_HIGH= 0xfbf |
Does this look odd to anyone else? Doesn't this essentially make the 0x15 and 0x16 specifications moot?
--
Jeff S. |
|
 |
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Wed Jan 12, 2005 4:21 pm |
|
|
This is from 3.190:
| Code: | long CCP_1;
#byte CCP_1 = 0xfbe
#byte CCP_1_LOW= 0xfbe
#byte CCP_1_HIGH= 0xfbf
long CCP_2;
#byte CCP_2 = 0xfbb
#byte CCP_2_LOW= 0xfbb
#byte CCP_2_HIGH= 0xfbc |
Looks like they screwed up the header files again. Why they keep touching them, I don't know. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Jan 12, 2005 4:46 pm |
|
|
| Did someone report this bug to CCS? |
|
|
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Wed Jan 12, 2005 6:02 pm |
|
|
The duplication of CCP_1 is in the 18F6525 header also.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
|
| Posted: Wed Jan 12, 2005 8:19 pm |
|
|
| Haplo wrote: | | Why they keep touching them, I don't know. |
It's a bit more complicated than that. |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Wed Jan 12, 2005 10:35 pm |
|
|
| Darren Rook wrote: | | Haplo wrote: | | Why they keep touching them, I don't know. |
It's a bit more complicated than that. |
Please enlighten us! I'm very curious and anxious to know. |
|
|
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
|
| Posted: Thu Jan 13, 2005 7:33 am |
|
|
| Haplo wrote: | | Please enlighten us! I'm very curious and anxious to know. |
The header files are re-generated with each release to incorporate any changes made to the devices.dat. An employee of CCS doesn't actually write, or edit, each header file. |
|
|
Guest
|
| Re: Oddity in latest 18F452 header file |
| Posted: Thu Jan 13, 2005 8:48 am |
|
|
| Anonymous wrote: | With the release of 3.215 or 3.216 (I think; not sure which), I found this in the 18F452.h device header:
| Code: | long CCP_1;
#byte CCP_1 = 0x15
#byte CCP_1_LOW= 0x15
#byte CCP_1_HIGH= 0x16
#byte CCP_1 = 0xfbe
#byte CCP_1_LOW= 0xfbe
#byte CCP_1_HIGH= 0xfbf |
Does this look odd to anyone else? Doesn't this essentially make the 0x15 and 0x16 specifications moot?
--
Jeff S. |
It was OK in V3.214 as you see here:
long CCP_1;
#byte CCP_1 = 0xfbe
#byte CCP_1_LOW= 0xfbe
#byte CCP_1_HIGH= 0xfbf
I dumped V3.16 yesterday because delay_ms(1000) does not not work.
Fix one thing break two things... Progress like that should end up taking us back to version 1.0. |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Thu Jan 13, 2005 12:44 pm |
|
|
V3.215 is correct. Luckily too. I'm designing a new project using the F452 and haven't installed 3.216 yet.
Thanks for the heads up. |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
| Re: Oddity in latest 18F452 header file |
| Posted: Thu Jan 13, 2005 4:19 pm |
|
|
| Anonymous wrote: |
I dumped V3.16 yesterday because delay_ms(1000) does not not work.
|
Well that seems to be fixed now in the 'new' 3.216. |
|
|
Guest
|
|
| Posted: Fri Jan 14, 2005 6:28 am |
|
|
| Haplo wrote: | | Why they keep touching them, I don't know. |
| Darren Rook wrote: | | The header files are re-generated with each release to incorporate any changes made to the devices.dat. An employee of CCS doesn't actually write, or edit, each header file. |
Well then, why do they keep touching the devices.dat file for these PIC's?  |
|
|
Haplo
Joined: 06 Sep 2003
Posts: 659
Location: Sydney, Australia
|
|
| Posted: Fri Jan 14, 2005 7:23 am |
|
|
| Anonymous wrote: | | Haplo wrote: | | Why they keep touching them, I don't know. |
| Darren Rook wrote: | | The header files are re-generated with each release to incorporate any changes made to the devices.dat. An employee of CCS doesn't actually write, or edit, each header file. |
Well then, why do they keep touching the devices.dat file for these PIC's? |
Well I think he's got you there, Darren  |
|
|
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
|
| Posted: Fri Jan 14, 2005 8:55 am |
|
|
| Anonymous wrote: |
Well then, why do they keep touching the devices.dat file for these PIC's? |
Even if you don't touch the .DAT files, all header files get re-generated for that release. The generater borked for some reason. If you have a problem I suggest e-mailing tech support.
PS - The .dat holds more information that's in the headerfile. It also includes information about debugging (ICD) and programming (Mach-X) |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
