It is currently 19 Oct 2018 00:02

All times are UTC + 1 hour




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: 07 Jun 2017 07:38 
Offline

Joined: 08 Jan 2012 07:28
Posts: 120
Hi

I chanced upon this "bug" by accident and im not sure if this is by design but the wrong/accidental setting of this is bound to cause problems.
For example i have 2 variables whose bits are in use within the project. They are declared like :

var
Variable1, Somevariable: Byte;

const Variablebit0 = 0; register;
var Variablebit0_bit : sbit at Variable1.B0;
const Variablebit1 = 1; register;
var Variablebit1_bit : sbit at Variable1.B1;
...... and so on .........

const Somebit0 = 0; register;
var Somebit0_bit : sbit at Somevariable.B0;
const Somebit1 = 1; register;
var Somebit1_bit : sbit at Somevariable.B1;
........and so on.........

in my methods, if i accidentally setup the variables like :
Variable1.Somebit0 := 1; //notice they are interchanged

The compiler compiles without any warning at all. I can understand the bit access is common, but it should still be within context.
Also the code completion combobox should, technically speaking, load the relevant bits with respect to the variable.
Hopefully this will be looked into.

Thanks and regards


Top
 Profile  
 
PostPosted: 07 Jun 2017 12:44 
Offline

Joined: 18 Feb 2006 13:17
Posts: 4982
It would certainly be very practical if compiler issued warnings when one mistook bit name - especially in a register variable. But to make it possible to implement one would have to apply a way of declaring bit constants and variables that would let the compiler unequivocally recognize the connection, like
var   Variable1: byte;
const Variablebit0 = 0; register;
var   Variablebit0_bit: sbit at Variable1.Variablebit0;
or
var   INTCON: byte; absolute 0x00B; volatile; sfr;
const GIE = 7; register;
var   GIE_bit : sbit at INTCON.GIE;
In the above, the connection between holding byte and a bit name is specified in sbit declaration and thus makes test of correct use of bit constants possible.

Unfortunately, all processor definition files use standard bit names (B0..7) in sbit declarations instead of declared (usually directly above) constants.

_________________
Replacement libraries for mP PRO and PIC18 processors, mP PRO tips & trics


Top
 Profile  
 
PostPosted: 07 Jun 2017 13:30 
Offline

Joined: 08 Jan 2012 07:28
Posts: 120
Thanks Janni :)

I think this would be a better coding style to adopt, with explicit naming for the bits. Let me try it out.


Top
 Profile  
 
PostPosted: 07 Jun 2017 13:50 
Offline

Joined: 18 Feb 2006 13:17
Posts: 4982
It's the only sensible style in my opinion and I use it constantly. This way any changes in bit constants do not require changes in sbit declarations. For example, a block of bit constants declarations for every port pin makes future changes or even porting code to another processor much easier.

_________________
Replacement libraries for mP PRO and PIC18 processors, mP PRO tips & trics


Top
 Profile  
 
PostPosted: 07 Jun 2017 17:12 
Offline

Joined: 08 Jan 2012 07:28
Posts: 120
Hi Janni, I agree.
i need this to be portable between different environments and this method guarantees the bit numbering to remain constant. I think as Delphi users we have become too used to the strict compiler errors generated, thats why this erroneous declaration went unnoticed until i saw it accidentally.
OTOH, no harm in making MP for Pic a little more bullet-proof i guess.


Top
 Profile  
 
PostPosted: 28 Jun 2017 20:05 
Offline

Joined: 18 Jun 2008 11:43
Posts: 3764
Location: Nieuwpoort, Belgium
janni wrote:
It would certainly be very practical if compiler issued warnings when one mistook bit name - especially in a register variable. But to make it possible to implement one would have to apply a way of declaring bit constants and variables that would let the compiler unequivocally recognize the connection, like
var   Variable1: byte;
const Variablebit0 = 0; register;
var   Variablebit0_bit: sbit at Variable1.Variablebit0;
or
var   INTCON: byte; absolute 0x00B; volatile; sfr;
const GIE = 7; register;
var   GIE_bit : sbit at INTCON.GIE;
In the above, the connection between holding byte and a bit name is specified in sbit declaration and thus makes test of correct use of bit constants possible.


Indeed, but still nothing prevents you to use a bitnumber declaration on the "wrong" variable, e.g.:
var   INTCON_: byte; absolute 0x00B; volatile; sfr;
const GIE_ = 7; register;
var   GIE_bit_ : sbit at INTCON_.GIE_;
var   xxx_bit  : sbit at STATUS.GIE_;  // <------- here
In above code the bitnumber "GIE_" (meant for variable INTCON) is used to define a bit in variable "STATUS" which has no GIE bit at all, in fact bit 7 there has no meaning (in the PIC18F2550).

One can even declare:
var   GIE_bit_  : sbit at STATUS.GIE_;
which is totally wrong seen from the perspective of the user... but to the compiler this is Ok, it will not complain or warn.

Note: in above code I did add an underscore to all variable names to make it not conflicting with already existing declarations.

_________________
Kind regards, Dany.
There is a crack in everything, that's how the light gets in... (L. Cohen)


Top
 Profile  
 
PostPosted: 28 Jun 2017 23:31 
Offline

Joined: 18 Feb 2006 13:17
Posts: 4982
Hi Dany,

Dany wrote:
Indeed, but still nothing prevents you to use a bitnumber declaration on the "wrong" variable...
Indeed, just like it is now. But at least if processor definition files were prepared in this way and compiler paired bit names with SFR names, a user could only mess things up intentionally, by re-declaring SFRs.

_________________
Replacement libraries for mP PRO and PIC18 processors, mP PRO tips & trics


Top
 Profile  
 
PostPosted: 29 Jun 2017 03:48 
Offline

Joined: 08 Jan 2012 07:28
Posts: 120
Perhaps if the compiler had support for classes this issue would not be a problem even if one made a mistake. Most mcu compilers out there support the class structure. It would perhaps even help with cleaner and better defined peripheral libraries. Just my 2 cents.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


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 post attachments in this forum

Search for:
Jump to: