![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
RLScott
Joined: 10 Jul 2007 Posts: 465
|
"Generate include file" omits address for TRISA in |
Posted: Wed Jun 28, 2017 4:35 pm |
|
|
Run PCW, File version 5.51.22.10 (October 2015), select Tools, Device Selector, Registers, Select PIC18F1320, Make Include File, Pack into struct's, combine High/Low byte registers into one int16,check all types of SFRs, Generate, we get:
Code: |
struct {
unsigned int TRISB0:1;
unsigned int TRISB1:1;
unsigned int TRISB2:1;
unsigned int TRISB3:1;
unsigned int TRISB4:1;
unsigned int TRISB5:1;
unsigned int TRISB6:1;
unsigned int TRISB7:1;
} TRISB;
#byte TRISB = 0xF93
struct {
unsigned int TRISA0:1;
unsigned int TRISA1:1;
unsigned int TRISA2:1;
unsigned int TRISA3:1;
unsigned int TRISA4:1;
unsigned int TRISA5:1;
unsigned int TRISA6:1;
unsigned int TRISA7:1;
} TRISA;
struct {
unsigned int LATB0:1;
unsigned int LATB1:1;
unsigned int LATB2:1;
unsigned int LATB3:1;
unsigned int LATB4:1;
unsigned int LATB5:1;
unsigned int LATB6:1;
unsigned int LATB7:1;
} LATB;
#byte LATB = 0xF8A
|
The address for TRISA is completely missing, which is not a compile error. It makes TRISA into a general RAM location, which makes for some really hairy debugging. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Thu Jun 29, 2017 12:11 am |
|
|
Report it to CCS.
However the reason it hasn't been noticed, is that very few people use the register defines.... |
|
![](templates/subSilver/images/spacer.gif) |
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Thu Jun 29, 2017 2:47 pm |
|
|
Ttelmah wrote: |
However the reason it hasn't been noticed, is that very few people use the register defines.... |
Using register defines is the only way I use the CCS compiler. I have never used the peripheral library. Take async, for example. Sometimes the real-time requirements of the job require polling. Other times the application requires interrupts for receiving. And even when interrupts are required, sometimes I use a software FIFO, and sometimes I need to do some primitive parsing right there in the ISR. And when I use a FIFO, different applications require a different size FIFO. The library routines for async may be OK for some applications, but I find that the flexibility to design the interface software exactly the way I want it outweighs the benefit of not having to understand the registers themselves. Accessing peripherals through their Microchip-defined registers is the only way I will do it. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jun 29, 2017 5:25 pm |
|
|
Fair enough. You want complete control. But what then makes CCS
significantly different enough for you than any other PIC compiler ?
Is it CCS's memory allocation, ram and rom ? |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Thu Jun 29, 2017 5:43 pm |
|
|
Just FYI...
In PCWHD 5.071 it works correctly... _________________ Google and Forum Search are some of your best tools!!!! |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Fri Jun 30, 2017 4:37 am |
|
|
RLScott wrote: |
Sometimes the real-time requirements of the job require polling. Other times the application requires interrupts for receiving. And even when interrupts are required, sometimes I use a software FIFO, and sometimes I need to do some primitive parsing right there in the ISR. And when I use a FIFO, different applications require a different size FIFO. |
I've done all those things and never once used a register define. The only time I encountered the defines was recently when working with CCS's port of Microchip's TCP/IP stack, where the defines are used as a compatibility fix. I have to say they caused a few problems....
Quote: | Accessing peripherals through their Microchip-defined registers is the only way I will do it. |
That's your perogative, of course, but you are unnecessarily limiting what you can do and slowing down your development processes, and as others have said, why are you choosing to use CCS C when you are effectively throwing away one of its key selling points? Personally I'd never use the defines unless I had a cast-iron reason, and no other realistic choice, for using them, as above in the TCP/IP stack, where they were already there and to strip them out would have required a lot of extra work. |
|
![](templates/subSilver/images/spacer.gif) |
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Fri Jun 30, 2017 7:47 am |
|
|
RF_Developer wrote: |
That's your perogative, of course, but you are unnecessarily limiting what you can do and slowing down your development processes, and as others have said, why are you choosing to use CCS C when you are effectively throwing away one of its key selling points? Personally I'd never use the defines unless I had a cast-iron reason, and no other realistic choice, for using them, as above in the TCP/IP stack, where they were already there and to strip them out would have required a lot of extra work. |
For me writing my own peripheral access code is generally one of the smallest parts of a project, and has not caused me any trouble. I find it almost as hard to fully comprehend the usage documentation for library routines as the hardware documentation. Some of my work is time-critical, down to counting instruction cycles in ISRs. I need to know exactly what my ISRs are doing.
I would probably use the library functions for something like a TCP/IP stack, or definitely a USB driver, because those routines do a lot more than just give me access. They implement protocols beyond the hardware.
As for the reason I use CCS, it was the first one I tried. It was inexpensive. And it was reliable. Perhaps others are better. I don't know. But this compiler has served me well. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|