• AVR Freaks

Helpful ReplyHot!"__bit" type variable initialization

Page: 12 > Showing page 1 of 2
Author
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
2020/01/23 07:04:02 (permalink)
0

"__bit" type variable initialization

I'm using XC8 v2.10 and I'd like to ask, if and how I can initialize a "__bit" variable.
I mean to define e.g.
__bit ConvertFlag = 1;

 
I'm using bit-field structs and I want to replace them with a __bit type variable to reduce the size of the code.
#1
mbrowning
USNA79
  • Total Posts : 1628
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: "__bit" type variable initialization 2020/01/23 08:50:06 (permalink) ☄ Helpfulby dirfys 2020/01/24 12:26:20
+1 (3)
__bit ConvertFlag;
 
void main(void) {
  ConvertFlag = 1;
}

 
#2
NKurzman
A Guy on the Net
  • Total Posts : 18266
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: "__bit" type variable initialization 2020/01/23 10:06:46 (permalink)
+1 (1)
Check the manual.  They may need to be global.  And can not be initialized to 1 ( it accepts 0)
This is how previous versions worked.
#3
ric
Super Member
  • Total Posts : 25592
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: "__bit" type variable initialization 2020/01/23 12:26:44 (permalink)
+1 (1)
As NKurzman stated. From "4.4.2.1 BIT DATA TYPES AND VARIABLES" in the user guide:

It is not possible to declare a pointer to bit types or assign the address of a bit object to
any pointer. Nor is it possible to statically initialize bit variables so they must be
assigned any non-zero starting value (i.e., 1) in the code itself. Bit objects will be
cleared on startup, unless the bit is qualified __persistent.

 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#4
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: "__bit" type variable initialization 2020/01/24 12:32:49 (permalink)
0
Thank you mbrowning for your suggestion.
But the drawback is that the bit variable can't be set as __persistent.
Well, we can't have everything in this life. Smile: SmileSmile: SmileSmile: Smile
#5
1and0
Access is Denied
  • Total Posts : 10346
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: "__bit" type variable initialization 2020/01/24 12:41:23 (permalink)
0
dirfys
But the drawback is that the bit variable can't be set as __persistent.
Well, we can't have everything in this life. Smile:

Did you miss Ric's post immediately before your post? pink: pink
#6
mbrowning
USNA79
  • Total Posts : 1628
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: "__bit" type variable initialization 2020/01/24 12:43:29 (permalink)
0
According to the legacy user guide section 5.4.2.1 and c99 mode user guide section 4.4.2.1, bit objects can be qualified as persistent.
#7
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: "__bit" type variable initialization 2020/01/25 10:30:51 (permalink)
0
What I mean is that since the bit variables are initialized (=1) right after the main starts and before the 'while', even if they are qualified as persistent they will always have the value 1 after a reset.
#8
mbrowning
USNA79
  • Total Posts : 1628
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: "__bit" type variable initialization 2020/01/25 12:03:37 (permalink)
0
You need to determine the type of reset and only initialize on POR and maybe BOR. Or use EEPROM to restore. I am not sure how this is different from persistent non-bit variables.
#9
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11577
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: "__bit" type variable initialization 2020/01/25 16:25:35 (permalink)
+1 (1)
I'm using bit-field structs and I want to replace them with a __bit type variable to reduce the size of the code.

 
What has led you to believe the compiler would generate different code for a __bit vs. a single-bit bit-field?
#10
ric
Super Member
  • Total Posts : 25592
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: "__bit" type variable initialization 2020/01/25 16:33:01 (permalink)
+1 (1)
+1
Never assume what the compiler has done. Look in the .LST file output, and then you will KNOW. :)
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#11
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 02:14:35 (permalink)
0
I have replaced 6 structs (with less than 48 bits in total) and the program memory has been reduced about more than 100 bytes. It may not seem a big reduction but, as you can understand, every single byte worths.
To avoid any misunderstandings, I don't want to criticize mbrowning's suggestion but it was just an observation.
post edited by dirfys - 2020/01/26 02:15:42
#12
ric
Super Member
  • Total Posts : 25592
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: "__bit" type variable initialization 2020/01/26 03:02:34 (permalink)
0
So were there lots of unused bits in all those structs?
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#13
1and0
Access is Denied
  • Total Posts : 10346
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 05:47:49 (permalink)
+1 (1)
dirfys
I have replaced 6 structs (with less than 48 bits in total) and the program memory has been reduced about more than 100 bytes. It may not seem a big reduction but, as you can understand, every single byte worths.

Single-bit bit-fields and bit variables should be the same and generate the same code, provided they are used in the same way.
 
<edit>
By any chance you're using a PIC16 device?  I am thinking maybe your organization of the bit-fields resulted in more banking instructions. In other words, the compiler groups the bit variables better than your use of structs. ;)  You said it reduces the program memory usage, what about the data memory usage?
</edit>
 

To avoid any misunderstandings, I don't want to criticize mbrowning's suggestion but it was just an observation.

Constructive criticism are helpful. ;)
 
 
Anyway, I know what the XC8 User's Guide stated. But, just wondering, why bit variables cannot be initialized and instead must be assigned after their definitions?
post edited by 1and0 - 2020/01/26 06:07:55
#14
Mysil
Super Member
  • Total Posts : 3642
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 07:36:52 (permalink)
0
Anyway, I know what the XC8 User's Guide stated. But, just wondering, why bit variables cannot be initialized and instead must be assigned after their definitions?

A possible reason is that linker shall be free to locate  __bit variables
from different compilation units together in the same byte(s), preferably in access bank or common RAM.
And Linker logic have maybe not been developed to handle combination of initialization values for __bit variables
from different compilation units into the same byte.
 
Bool types and bitfield structures are much simpler for the Linker,
if there are no additional bits in the same struct, then the rest of the byte is unused.
and bool type variables use a whole byte anyway.
 
Regards,
    Mysil
#15
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 09:25:06 (permalink)
0
ric
So were there lots of unused bits in all those structs?
 

 
1and0
 By any chance you're using a PIC16 device?  I am thinking maybe your organization of the bit-fields resulted in more banking instructions. In other words, the compiler groups the bit variables better than your use of structs. ;)  You said it reduces the program memory usage, what about the data memory usage?


I'm using the PIC16F1789 chip and these are the structures that I've replaced. The first 5 structs (w/o initialization) are used at the main header (the first 2 in the ISR) while the rest of them (at which some bits are initialized) are used to other files and the "spare_flags" bits are not used. The only exception is the last struct which is static and is initialized and it cannot be replaced by the __bit types.
The Data memory is reduced by 2 bytes, which is in accordance with the calculations (unused/used bit-fields).
The unused bits in each structure don't affect for sure the Data memory and I think the same applies for the Program memory.

struct MAIN_flags {
unsigned WDT:1;
unsigned OnOffLED:1; //Change the LED status between On/Off states.
unsigned BuzzerBeep:1; //Has the MAX_LED_BlinkPeriod elapsed?
unsigned KeyWaitExpired:1; //Has the 'MAX_KeyWaitPeriod' elapsed?
unsigned ClearDisplay:1; //Clear the display when 'MAX_ClearDisplayPeriod' has elapsed.
unsigned StartADConv4Temperature:1; //Is the system ready for the ADC conversion?
unsigned StartADConversion:1; //Is the system ready for the ADC conversion?
unsigned Ready2WakeUP:1; //Is it the time to Wake up from SLEEP? Is the Main battery discharged or removed?
}; //ISR_flags
 
struct MAIN_flags2 {
unsigned msec500:1; //Check the temperature at the Preheat zone.
unsigned sec9:1; //Check the temperature at the Soak zone.
unsigned sec1:1; //Check the temperature at the Reflow zone.
unsigned ReflowTimerExpired:1; //Check the duration at the ReflowPeak zone.
unsigned StartADConv4TempIndicator:1; //Is the system ready for the ADC conversion?
unsigned RefreshLCD:1; //TRUE --> Refresh the LCD data.
unsigned StoreTemperature;
unsigned spare_flag7:1;
}; //ISR_flags2
 
/****************************************************/
 
struct Global_flags {
unsigned HourFormat12h:1; //Is the hour format '12h'=1 or '24H'=0?
unsigned AfterTheNoon:1; //AM=0, PM=1
unsigned Ready2Sleep:1; //Set the PIC to SLEEP mode.
unsigned PbFree:1; //Without Pb=1, With Pb=0.
unsigned ClearLCD:1; //TRUE --> Start clearing the LCD.
unsigned CheckTemp:1; //Has the final temperature been calculated? Default: True, in order to bypass the arbitrary value of Temperature during PIC startup.
unsigned Skip1stADC:1; //Used to solve the problem where the 1st ADC after PIC power on is wrong
unsigned CalcBatLevel:1; //Has the final battery voltage been calculated? Default: False.
}; //Global
 
struct Global_flags2 {
unsigned NoMainBattery:1; //Is the main battery removed or discharged (Voltage < CutOffVoltageLevel)?
unsigned LowBattery:1; //Is the main battery voltage level LOW (1) or not (0)?
unsigned PS5V:1; //True if 5V Power Supply has been connected.
unsigned Bat9V:1; //True if 9V Battery has been connected.
unsigned Switch1:1;
unsigned spare_flag5:1;
unsigned spare_flag6:1;
unsigned spare_flag7:1;
}; Global_2
 
struct Global_flags3 {
unsigned EEPROM_Read:1; //Read from EEPROM? Yes=1, No=0
unsigned EEPROM_Write:1; //Write in EEPROM? Yes=1, No=0
unsigned QuickFormat:1; //True for the Quick Format activation.
unsigned LowLevelFormat:1; //True for the Low Level Format activation.
unsigned spare_flag4:1;
unsigned spare_flag5:1;
unsigned spare_flag6:1;
unsigned CharStorage:1; //Store the characters read by EUSART? Yes=1, No=0
}; Global_3
 
struct RTC {
unsigned FirstDigit:1; //Store the first digit?
unsigned SecondDigit:1; //Store the second digit?
unsigned NextPair:1; //Continue with the next pair of digits?
unsigned SkipPair:1; //Skip the next pair of digits?
unsigned spare_flag5:1;
unsigned spare_flag6:1;
unsigned spare_flag7:1;
unsigned spare_flag8:1;
} RealTimeClock = {1, 0, 0, 0, 0, 0, 0, 0};
 
struct TemperatureApplications_flags{
unsigned PreheatZoneAudio1:1;
unsigned SoakZoneAudio2:1;
unsigned ReflowZoneAudio3:1;
unsigned ReflowPeakZoneAudio4:1;
unsigned ContAfterReset:1;
unsigned spare_flag5:1;
unsigned spare_flag6:1;
unsigned Rdy2HeatOven:1; //Turn off, by default, the oven.
} ReflowZones = {0,1,1,1,1,0,0,1};
 
struct Alarm_flags {
unsigned MasterCodeCorrect:1; //Is the type Master code correct?
unsigned ArmAlarm:1; //Is the alarm armed?
unsigned Ready2WriteInEEPROM:1; //Control the EEPROM write.
unsigned MasterCodeTyped:1; //Have all 4 digits been typed?
unsigned spare_flag5:1;
unsigned spare_flag6:1;
unsigned spare_flag7:1;
unsigned spare_flag8:1;
} Alarm = {0, 0, 1, 0, 0, 0, 0, 0};
 
static struct MasterCode_flags {
unsigned PWdigit1:1; //Has the 1st digit entered?
unsigned PWdigit2:1; //Has the 2nd digit entered?
unsigned PWdigit3:1; //Has the 3rd digit entered?
unsigned PWdigit4:1; //Has the 4th digit entered?
unsigned DigitsCollected:1; //Have all the digits been collected?
unsigned spare_flag6:1;
unsigned spare_flag7:1;
unsigned spare_flag8:1;
} PWflags = {1, 0, 0, 0, 0};

post edited by dirfys - 2020/01/27 05:14:58
#16
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11577
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 11:33:37 (permalink)
+1 (1)
The comparison in code size would be more realistic if you removed the initialization code from the structs, since you're not doing that with the __bit objects.
#17
1and0
Access is Denied
  • Total Posts : 10346
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 11:40:59 (permalink)
+2 (2)
dirfys
I'm using the PIC16F1789 chip and these are the structures that I've replaced. The first 5 structs (w/o initialization) are used at the main header (the first 2 in the ISR) while the rest of them (at which some bits are initialized) are used to other files and the "spare_flags" bits are not used. The only exception is the last struct which is static and is initialized and it cannot be replaced by the __bit types.
The Data memory is reduced by 2 bytes, which is in accordance with the calculations (unused/used bit-fields).
}; ISR_flags
}; ISR_flags2
}; Global
}; Global_2
}; Global_3


The semicolons here are at the wrong places. ;)
 

} RealTimeClock = {1, 0, 0, 0, 0, 0, 0, 0};
} ReflowZones = {0,1,1,1,1,0,0,1};
} Alarm = {0, 0, 1, 0, 0, 0, 0, 0};
} PWflags = {1, 0, 0, 0, 0};


As Jtemples said, these initialization will take up code space.
#18
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11577
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: "__bit" type variable initialization 2020/01/26 11:47:05 (permalink)
+1 (1)
A small test program with XC8 2.10 PRO shows bit test/set on bit-fields are one instruction on PIC16 and PIC18.
#19
dirfys
Super Member
  • Total Posts : 258
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: "__bit" type variable initialization 2020/01/27 05:13:20 (permalink)
+1 (1)
1and0
The semicolons here are at the wrong places. ;)
 

You are right. It's a typo. They are comments. I've already corrected it at my previous post.

jtemples
The comparison in code size would be more realistic if you removed the initialization code from the structs, since you're not doing that with the __bit objects.

 
Before I start this discussion I had already replaced the non initialized bit-fields and I had observed this reduction of ~100 bytes. I don't think that the initialization of the bit-fields or the __bit types (in the way that it's has been done) should affect the amount of the occupied memory.
post edited by dirfys - 2020/01/27 05:16:06
#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2020 APG vNext Commercial Version 4.5