Helpful ReplyHot!errors and warnings

Page: < 12 Showing page 2 of 2
Author
1and0
Access is Denied
  • Total Posts : 6965
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: errors and warnings 2017/10/19 21:44:23 (permalink)
+1 (1)
Since you are not going to post the definition of ALARM_FLAGbits, I'll assume those are single-bit bitfields and suggest declaring "safety_status" to be the same type as ALARM_FLAGbits so the following can be done:
ALARM_FLAGbits.OV_STA = safety_status.OV_STA;

instead of ANDing a bit mask.
 
 
#21
Andy_Taiwanese
Super Member
  • Total Posts : 355
  • Reward points : 0
  • Joined: 2014/12/19 02:59:38
  • Location: 0
  • Status: offline
Re: errors and warnings 2017/10/19 23:46:10 (permalink)
0
To 1and0:
you will find that the single-bit members of the first struct are defined as individual bit definitions, and notice these bit definitions are being deprecated.

What you said the individual bit definitions is this?
typedef union {
    struct {
        unsigned T2CKPS0 :1;//individual bit definition
        unsigned T2CKPS1 :1;//individual bit definition
        unsigned TMR2ON :1;//individual bit definition
        unsigned T2OUTPS0 :1;//individual bit definition
        unsigned T2OUTPS1 :1;//individual bit definition
        unsigned T2OUTPS2 :1;//individual bit definition
        unsigned T2OUTPS3 :1;//individual bit definition
    };
    struct {
        unsigned T2CKPS :2;
        unsigned :1;
        unsigned T2OUTPS :4;
    };
} T2CONbits_t;

Why these bit definition are being deprecated?
 
 
 
There are no bit definitions for the multiple-bit members of the second struct in the header file

I don't get it. There is an example that multiple-bit members of the second struct having bit definition in the header file.
typedef union {
    struct {
        unsigned PS0 :1;
        unsigned PS1 :1;
        unsigned PS2 :1;
        unsigned PSA :1;
        unsigned TMR0SE :1;
        unsigned TMR0CS :1;
        unsigned INTEDG :1;
        unsigned nWPUEN :1;
    };
    struct {
        unsigned PS :3;
        unsigned :1;
        unsigned T0SE :1;
        unsigned T0CS :1;
    };
} OPTION_REGbits_t;

 
 
 
The constant 0b10000000 is _not_ an unsigned int, it is a signed int. Like I said in my previous post, make that constant an unsigned value.
and the & operation will be carried out using unsigned int, which will make that warning disappear.

Thank you, the warning disappear.
I may want to ask why constant(literal) is NOT an unsigned int? Is this a conflict to XC8 user guide? I don't think so. What is the real meaning of this sentence?
All constants can be expressed in (unsigned) binary, octal, decimal or hexadecimal, as per normal C syntax.

 
 
 
You did not post the definition of ALARM_FLAGbit, even though I asked you to

Sorry I missed it. Here is the definition.
typedef struct{
    unsigned SCN_EVT :1;
    unsigned UT_STA :1;
    unsigned OT_STA :1;
    unsigned OV_STA :1;
    unsigned UV_STA :1;
    unsigned OC0_STA :1;
    unsigned CHG_STA :1;
    unsigned DHG_STA :1;
}ALARM_FLAG;

 
 
 
So I'll assume its members are in fact single-bit bitfields and not 16-bit unsigned int.

I don't get this, are you saying that there are two ways to defined struct, single-bit and 16-bit unsigned int?
As far as I know, there is no difference among:
typedef struct{
    int FIRST_INTERRUPT :1;
    unsigned int battery_malfunction :1;
    unsigned UV_overtime :1;
}OTHER_FLAG;

 
 
 
ALARM_FLAGbits.SCN_EVT = (unsigned) !!(safety_event & 0b10000000);

Does the double exclamation mark matter?
 
Thank you!
 
 
post edited by Andy_Taiwanese - 2017/10/19 23:52:34
#22
1and0
Access is Denied
  • Total Posts : 6965
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: errors and warnings 2017/10/20 07:12:20 (permalink)
+1 (1)
Andy_Taiwanese
you will find that the single-bit members of the first struct are defined as individual bit definitions, and notice these bit definitions are being deprecated.

What you said the individual bit definitions is this?
typedef union {
    struct {
        unsigned T2CKPS0 :1;//individual bit definition
        unsigned T2CKPS1 :1;//individual bit definition
        unsigned TMR2ON :1;//individual bit definition
        unsigned T2OUTPS0 :1;//individual bit definition
        unsigned T2OUTPS1 :1;//individual bit definition
        unsigned T2OUTPS2 :1;//individual bit definition
        unsigned T2OUTPS3 :1;//individual bit definition
    };
    struct {
        unsigned T2CKPS :2;
        unsigned :1;
        unsigned T2OUTPS :4;
    };
} T2CONbits_t;

Why these bit definition are being deprecated?

Use the "Find" function of your text editor and search for any of those member name and you will find them also listed under "Bit Definitions"; such as,
/*
* Bit Definitions
*/
#define _DEPRECATED __attribute__((__deprecated__))
 
extern volatile __bit  T2CKPS0       @ (((unsigned) &T2CON)*8) + 0;
#define                T2CKPS0_bit   BANKMASK(T2CON), 0
extern volatile __bit  T2CKPS1       @ (((unsigned) &T2CON)*8) + 1;
#define                T2CKPS1_bit   BANKMASK(T2CON), 1
extern volatile __bit  T2OUTPS0      @ (((unsigned) &T2CON)*8) + 3;
#define                T2OUTPS0_bit  BANKMASK(T2CON), 3
extern volatile __bit  T2OUTPS1      @ (((unsigned) &T2CON)*8) + 4;
#define                T2OUTPS1_bit  BANKMASK(T2CON), 4
extern volatile __bit  T2OUTPS2      @ (((unsigned) &T2CON)*8) + 5;
#define                T2OUTPS2_bit  BANKMASK(T2CON), 5
extern volatile __bit  T2OUTPS3      @ (((unsigned) &T2CON)*8) + 6;
#define                T2OUTPS3_bit  BANKMASK(T2CON), 6

Deprecation -- "While a deprecated software feature remains in the software, its use may raise warning messages recommending alternative practices; deprecated status may also indicate the feature will be removed in the future. Features are deprecated rather than immediately removed, to provide backward compatibility, and to give programmers time to bring affected code into compliance with the new standard."
  
I don't get it. There is an example that multiple-bit members of the second struct having bit definition in the header file.

These are bit-field members of a struct, not bit definitions.  See above.
  

I may want to ask why constant(literal) is NOT an unsigned int? Is this a conflict to XC8 user guide? I don't think so. What is the real meaning of this sentence?
All constants can be expressed in (unsigned) binary, octal, decimal or hexadecimal, as per normal C syntax.


Constants can be signed or unsigned; without the suffix 'u' it is signed, with the suffix 'u' it is unsigned. Simple, right?  To me, that sentence just means constants can be written as binary, octal, decimal or hexadecimal according to the C notation; and they can be unsigned too. 
 

Sorry I missed it. Here is the definition.
typedef struct{
    unsigned SCN_EVT :1;
    unsigned UT_STA :1;
    unsigned OT_STA :1;
    unsigned OV_STA :1;
    unsigned UV_STA :1;
    unsigned OC0_STA :1;
    unsigned CHG_STA :1;
    unsigned DHG_STA :1;
}ALARM_FLAG;


So see my last post regarding using these bit-fields instead using bit-mask.
  

So I'll assume its members are in fact single-bit bitfields and not 16-bit unsigned int.

I don't get this, are you saying that there are two ways to defined struct, single-bit and 16-bit unsigned int?
As far as I know, there is no difference among:
typedef struct{
    int FIRST_INTERRUPT :1;
    unsigned int battery_malfunction :1;
    unsigned UV_overtime :1;
}OTHER_FLAG;


In Post #18 you said, "Come back to strcut ALARM_FLAGbit, the member SCN_EVT is defined as unsigned int."  The members in your definition are not "unsigned int" which is 16-bit width, the members in your struct are bit-fields of 1-bit width. Since XC8 does not support signed bit-fields, I suggest you to use plain "unsigned" for bit-fields instead of "int" and "unsigned int".
 

ALARM_FLAGbits.SCN_EVT = (unsigned) !!(safety_event & 0b10000000);

Does the double exclamation mark matter?

Yes it does, or else I would not put them there. ;)
 
I gotta go ...
 
post edited by 1and0 - 2017/10/20 09:14:29
#23
jtemples
Super Member
  • Total Posts : 10199
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: errors and warnings 2017/10/20 12:42:11 (permalink)
+2 (2)
Constants can be signed or unsigned; without the suffix 'u' it is signed, with the suffix 'u' it is unsigned. Simple, right?

 
As is often the case with C, it's not quite that simple.  An unsuffixed decimal constant will never be an "unsigned int", but it can be an "unsigned long" if it's >= 2^31(*).  Hex constants such as 0x8001 are "unsigned int" if int is 16 bits (like XC8), while 0x7FFF is plain "int".  Binary constants aren't standard so I don't know what XC8 does with them.
 
Of course, best practice is to be explicit when you want unsigned.
 
*This changes in C99 because of the "long long" type, which XC8 has, but XC8's "long long" is only 32 bits, so I have no idea what it does here.
#24
1and0
Access is Denied
  • Total Posts : 6965
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: errors and warnings 2017/10/20 15:12:48 (permalink)
0
jtemples
As is often the case with C, it's not quite that simple.  An unsuffixed decimal constant will never be an "unsigned int", but it can be an "unsigned long" if it's >= 2^31(*).  Hex constants such as 0x8001 are "unsigned int" if int is 16 bits (like XC8), while 0x7FFF is plain "int".  Binary constants aren't standard so I don't know what XC8 does with them.
 
Of course, best practice is to be explicit when you want unsigned.

Fair points, unsuffixed decimal constant >= 2^31 overflows since the maximum value of "signed long" is 0x7FFFFFFF.  C11 § 6.4.4.1 Integer Constants specifies the type given for an integer constant. XC compilers should go by these rules and treat binary constant as hex constant.
 
General rule is to explicitly add suffix u or U to the constant (even binary and hex) if you want unsigned, or cast the constant like ((uint16_t)0x7FFF).
post edited by 1and0 - 2017/10/20 15:14:36
#25
mlp
boots too small
  • Total Posts : 498
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: Microchip XC8 and XCLM team
  • Status: offline
Re: errors and warnings 2017/10/20 16:22:50 (permalink)
+1 (1)
jtemplesthe "long long" type, which XC8 has

Sorry, John, but XC8 does not yet have long long.
What XC8 has is a lazy parser which sets a bit for each qualifier it reads in a declaration, but does not care how many times it does this for a given declaration.
 
You can (as far as I'm aware) use unsigned multiple times, but it does not make the object any more unsigned than using it just once.
Likewise, multiple occurrences of long don't increase the length any further, just as multiple shorts don't keep making it shorter.
 
As an aside, this is also why short long was easy to add as a new type name.

Please, before you post, read the Forum Guidelines
To get a useful answer, always state which PIC you are using!
 
Mark (not paid to state the opinions of Microchip Technology Inc.)


#26
qhb
Superb Member
  • Total Posts : 5824
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: errors and warnings 2017/10/20 16:46:38 (permalink)
+1 (1)
mark.pappin
As an aside, this is also why short long was easy to add as a new type name.

and volatile const too I guess. :)
 
#27
DarioG
Scheisse Menschen
  • Total Posts : 52447
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: hi there
  • Status: online
Re: errors and warnings 2017/10/21 06:20:07 (permalink)
0
mark.pappin
 
What XC8 has is a lazy parser which sets a bit for each qualifier it reads in a declaration, but does not care how many times it does this for a given declaration.

 
Hey, this is exactly how my parser worked in 1989 C compiler grin
#28
mlp
boots too small
  • Total Posts : 498
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: Microchip XC8 and XCLM team
  • Status: offline
Re: errors and warnings 2017/10/23 06:51:14 (permalink)
+1 (1)
qhb
mark.pappin
As an aside, this is also why short long was easy to add as a new type name.

and volatile const too I guess. :)



Yes, but no, as volatile and const do not mean "contradictory" things like short and long do.
 
volatile means "Hey, compiler, this thing might change behind your back so don't optimize away any reads."
const means "Hey, compiler, don't allow me to write to this thing."
Putting both on a single object is quite reasonable with any compiler.
 
(volatile also means "Hey, compiler, writing to this thing causes a special effect so don't optimize away any writes", but that's not important right now.)
 

Please, before you post, read the Forum Guidelines
To get a useful answer, always state which PIC you are using!
 
Mark (not paid to state the opinions of Microchip Technology Inc.)


#29
1and0
Access is Denied
  • Total Posts : 6965
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: errors and warnings 2017/10/23 07:34:54 (permalink)
+1 (1)
mark.pappin
 
Yes, but no, as volatile and const do not mean "contradictory" things like short and long do.
 
Good thing the compiler does not like unsigned signed. ;)
 

volatile means "Hey, compiler, this thing might change behind your back so don't optimize away any reads."
const means "Hey, compiler, don't allow me to write to this thing."
Putting both on a single object is quite reasonable with any compiler.
 
(volatile also means "Hey, compiler, writing to this thing causes a special effect so don't optimize away any writes", but that's not important right now.)

As I understand it and how I see it, volatile is not telling the compiler that the data might change behind its back. It is telling the compiler that it should do exactly as many read and write accesses, and in exactly the same order, as stated in the source code.
 
#30
DarioG
Scheisse Menschen
  • Total Posts : 52447
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: hi there
  • Status: online
Re: errors and warnings 2017/10/23 07:36:37 (permalink)
0
unsigned signed would be nice grin
 
That could be an alias for Zero. Or NaN !!
#31
Gort2015
Klaatu Barada Nikto
  • Total Posts : 1360
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: online
Re: errors and warnings 2017/10/23 10:17:21 (permalink)
+1 (1)
That is illogical Captain.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#32
1and0
Access is Denied
  • Total Posts : 6965
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: errors and warnings 2017/10/23 10:24:21 (permalink)
+1 (1)
DarioG
That could be an alias for Zero. Or NaN !!

Actually, some number representations allow the existence of two zeros, +0 and -0.  Even the IEEE-754 floating point has both +0 and -0.  So, does this mean zero is signed?  As for NaN it can be (0.0)/(0.0) ... <edit> and then there are +NaN (+0)/(+0) and -NaN (+0)/(-0)  ;) </edit>


 
 
post edited by 1and0 - 2017/10/23 10:37:38
#33
DarioG
Scheisse Menschen
  • Total Posts : 52447
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: hi there
  • Status: online
Re: errors and warnings 2017/10/23 10:45:19 (permalink)
0
Correct! yeah, makes sense...
#34
Page: < 12 Showing page 2 of 2
Jump to:
© 2017 APG vNext Commercial Version 4.5