CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

#Bit explanation

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
skybox63



Joined: 30 Jun 2018
Posts: 17

View user's profile Send private message

#Bit explanation
PostPosted: Sat Jun 30, 2018 9:13 am     Reply with quote

Hello this is my first post.

I'm attempting to wrap my head around the theory behind #bit use.

Using an example I found illustrates my question:
Code:

#BIT Data_Pin = 0xF81.0                      // Data pin mapped to PortB.0

#BIT Data_Pin_Direction = 0xF93.0      // Mapped to TRISB.0

Questions:

1. Are the hex vales assigning memory locations that can be subsequently accessed? For example: Data_Pin_Direction = 0/1

2. Are the hex vales arbitrary as long as they refer to an acceptable RAM location or are they specific to different MCUs?

Thanks
Roger
newguy



Joined: 24 Jun 2004
Posts: 1909

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 9:51 am     Reply with quote

You can refer to specific RAM locations, SFRs (special function registers), or just plain old variables. If you want to reference a particular SFR such as the port A tris, look at the #getenv directive. Very handy feature of the compiler which negates the need to look up the SFR's address in the data sheet.
Ttelmah



Joined: 11 Mar 2010
Posts: 19548

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 12:11 pm     Reply with quote

Step back.

Start by looking at #locate.

#locate allows you to 'locate' a variable at a specific memory location.
You create a varible, and can then place this at a particular location in memory.

Then there are the derivative functions of this:

#word
#byte
#bit

#word automatically creates an int16 variable, and locates this at a specific location.
#byte creates an int8 variable and locates this at a specific location
#bit creates an int1 varible and locates this at the specific location.

Each of these also has a 'secondary' operation, that if you create a variable 'first', and then use this name as the target, this variable is located at the specified location. Exactly like #locate.

The variables automatically created are all just normal variables. Exactly like any other. Existing variable names can also be used as locations.

So:
Code:

#BYTE PortB=0xF81
//creates a variable called 'PortB' located at 0xF81 in RAM
#BYTE PortB=getenv("SFR:PORTB")
//automatically creates a variable called PortB located
//at the system register called PORTB

#BIT Data_Pin = 0xF81.0
//Creates an int1 variable 'Data_Pin' located as bit 0 of the register
//at 0xF81

#BIT Data_Pin = PORTB.0
//If you have a variable called 'PORTB' defined. This creates an
//int1 variable pointing to the bottom bit of this.



All the variables created can be read or written just like any other.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

Re: #Bit explanation
PostPosted: Sat Jun 30, 2018 12:34 pm     Reply with quote

To give more direct answers,
skybox63 wrote:

1. Are the hex vales assigning memory locations that can be
subsequently accessed? For example: Data_Pin_Direction = 0/1

Yes.

skybox63 wrote:

2. Are the hex values arbitrary as long as they refer to an acceptable
RAM location ?

Yes, the hex values can be any arbitrary RAM location.

skybox63 wrote:
or are they specific to different MCUs?

Yes, in your particular example, they are (RAM-based) register addresses
which are specific to different MCUs.
skybox63



Joined: 30 Jun 2018
Posts: 17

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 5:26 pm     Reply with quote

Thanks everyone. Where I was getting hung-up is not understanding the correlation of the SFRs and the hex values used in the code.

Best
Roger
Ttelmah



Joined: 11 Mar 2010
Posts: 19548

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 11:55 pm     Reply with quote

As a comment, using hex values for the locations can be very dangerous. It is vital if you do this, that you document it really well. Something like:

//0xF81 is the address of the PortB SFR

Otherwise in a few months time you will find yourself having problems working out why the value was used... :(

Better now to use the getenv and locate to a named SFR.

One of the commonest mistakes is to get an address wrong. Using the getenv reduces the chance of this happening.
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jul 01, 2018 6:33 am     Reply with quote

another comment.
When you read the datasheet, you'll see that most mfrs use hex notation for the 'memory map'.
Now that there are 1,000s of PIC to choose from ,it's GREAT that CCS added the getenv() function as it makes transporting code from one PIC to another series PIC easy( well...easier...)

Jay
skybox63



Joined: 30 Jun 2018
Posts: 17

View user's profile Send private message

PostPosted: Sun Jul 01, 2018 5:12 pm     Reply with quote

Appreciate the follow-up. All good points to consider.

Roger
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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