View previous topic :: View next topic |
Author |
Message |
skybox63
Joined: 30 Jun 2018 Posts: 17
|
#Bit explanation |
Posted: Sat Jun 30, 2018 9:13 am |
|
|
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: 1907
|
|
Posted: Sat Jun 30, 2018 9:51 am |
|
|
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: 19504
|
|
Posted: Sat Jun 30, 2018 12:11 pm |
|
|
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
|
Re: #Bit explanation |
Posted: Sat Jun 30, 2018 12:34 pm |
|
|
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
|
|
Posted: Sat Jun 30, 2018 5:26 pm |
|
|
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: 19504
|
|
Posted: Sat Jun 30, 2018 11:55 pm |
|
|
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: 9225 Location: Greensville,Ontario
|
|
Posted: Sun Jul 01, 2018 6:33 am |
|
|
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
|
|
Posted: Sun Jul 01, 2018 5:12 pm |
|
|
Appreciate the follow-up. All good points to consider.
Roger |
|
|
|