|
|
View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19195
|
|
Posted: Sat Aug 05, 2017 12:03 pm |
|
|
It would have been better if it has been called #USE_UART, however given this includes it's 'soft UART' modes, this would be just as likely to confuse.
Almost every term is just as likely to lead to confusion somewhere. SIO, would also cover the SSP, so could mislead here. Even UART can confuse, since some chips now have synchronous support as well.
Best just to live with the term and accept that a properly descriptive name would be impractical:
#USE_LOGIC_SERIAL_HARDWARE/SOFTWARE
would be rather inconvenient....
Remember if you don't like a term, you can always use a #DEFINE to give it your own name. |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Mon Aug 07, 2017 4:30 am |
|
|
Arakel, you seem to be under the misapprehension that we are CCS and can do anything about these "issues" you are concerned about. We are CCS users and cannot make changes to CCS products.
As for the issues themselves, well, I normally use the "16MHz" syntax for my clock rates, much preferring them to the bare, default numbers. I have done a fair bit of work recently with SCPI, which being case insensitive (i.e. m and M are the same) uses M for milli and MEG for mega. Dealing with MEG is a real pain frankly, particularly with frequencies, and especially in my line of work, RF, where anything less than 100MHz is pretty much considered DC. Personally I would never use M on its own: I'd always use the relevant units. I did not know CCS C accepted just M. Also you are sort of right about "small" and "large" multipliers, but small is not less than 0, its less than 1, and there have commonly used exceptions: it is only recently that engineers started to use K instead of k for 1^3.
I am not going to comment on the precedence issue, as others have covered that well already.
I strongly disagree about "setup_ADC_channel". It is not an initialisation function, which is what "setup" implies to me. Indeed, set_ADC-channel doesn't setup any functionality of the ADC channel (it night if there was filtering or the like) but instead merely selects which ADC channel to use. In my software, where I have wrapper functions to abstract some ADC functionality, I called the wrapper function "Select_ADC_Channel".
The pointer issue is primarily a result of lack of understanding C syntax, i.e. poor knowledge, resulting in imprecise usage. In any case with CCS C such bit level manipulations of SFRs is nearly always not needed, there being a better, more portable and readable solution provided by CCS. Using pointers to access SFRs seem, on the face of it, almost perverse and certainly obtuse. Additionally, while using eight bit binary patterns is fairly reasonable (notwithstanding the error in this particular example) using binary representation for 16 and 32 bit entities is much likely to cause errors. That is why other representations have been used from the earliest days of computing, these days generally hex, but also octal. There are good reasons why these are preferred over binary. For single bit manipulations, even naming the bits (e.g. #define MYBIT 0b00000010) is generally preferable. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19195
|
|
Posted: Mon Aug 07, 2017 6:08 am |
|
|
It's worth also just emphasising just how inefficient using the pointer syntax is.
The PIC is not really good at handling pointers. A lot of setup involved to program them. Putting a configuration value into a register using a pointer probably translates to perhaps 20 instructions, while just talking directly to the register, involves perhaps 3.... |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1899
|
|
Posted: Mon Aug 07, 2017 11:29 am |
|
|
Ttelmah wrote: | It's worth also just emphasising just how inefficient using the pointer syntax is.
The PIC is not really good at handling pointers. A lot of setup involved to program them. Putting a configuration value into a register using a pointer probably translates to perhaps 20 instructions, while just talking directly to the register, involves perhaps 3.... |
Code: | #include <18F24K40.h>
#device ADC=10
#use delay(clock=40000000,crystal=10000000)
#byte T6CON=getenv("SFR:T6CON")
void main(void) {
unsigned int8 *t6_pointer;
t6_pointer = &T6CON;
*t6_pointer = 0x80;
T6CON = 0;
T6CON = 0x60;
while (TRUE) {
}
} |
This compiles to:
Code: | .................... unsigned int8 *t6_pointer;
....................
.................... t6_pointer = &T6CON;
0032: MOVLW T6CON>>8
0034: MOVWF t6_pointer+1
0036: MOVLW T6CON
0038: MOVWF t6_pointer
....................
.................... *t6_pointer = 0x80;
003A: MOVFF t6_pointer,FSR0L
003E: MOVFF t6_pointer+1,FSR0H
0042: MOVLW 80
0044: MOVWF INDF0
....................
.................... T6CON = 0;
0046: CLRF T6CON
.................... T6CON = 0x60;
0048: MOVLW 60
004A: MOVWF T6CON |
Using pointers to access the SFRs is very inefficient at best. |
|
|
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
|
Posted: Wed Aug 16, 2017 8:46 am |
|
|
Thanks for the help everyone! _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
|
|
|
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
|