Embedded Programming Tips for CCS C - Revision history

Hwang: /* Volatile Variables */

2008-12-14T23:08:58Z

Volatile Variables

← Older revision		Revision as of 18:08, 14 December 2008
Line 80:		Line 80:

	==Volatile Variables==		==Volatile Variables==
	~~Volatile~~ keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt). For example, you may have a variable that is constantly being read in a loop and never written to in the loop, but is written to in an ISR. A compiler might decide that your value is constant and replace it with a constant if it doesn't see the change being made in the ISR.		The '''volatile''' keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt). For example, you may have a variable that is constantly being read in a loop and never written to in the loop, but is written to in an ISR. A compiler might decide that your value is constant and replace it with a constant if it doesn't see the change being made in the ISR.

	When to use "volatile":		When to use "volatile":

Hwang: /* Volatile Variables */

2008-12-14T23:08:43Z

Volatile Variables

← Older revision		Revision as of 18:08, 14 December 2008
Line 80:		Line 80:

	==Volatile Variables==		==Volatile Variables==
	Volatile keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt). For example, you may have a variable that is constantly being read in a loop and never written to in the loop, but is written to in an ISR. A compiler might decide that your value is constant and replace it with a constant if it doesn't see the change being made in the ISR>		Volatile keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt). For example, you may have a variable that is constantly being read in a loop and never written to in the loop, but is written to in an ISR. A compiler might decide that your value is constant and replace it with a constant if it doesn't see the change being made in the ISR.

	When to use "volatile":		When to use "volatile":

Hwang: /* Volatile Variables */

2008-12-09T07:25:13Z

Volatile Variables

← Older revision		Revision as of 02:25, 9 December 2008
Line 80:		Line 80:

	==Volatile Variables==		==Volatile Variables==
	~~volatile~~ keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt)		Volatile keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt). For example, you may have a variable that is constantly being read in a loop and never written to in the loop, but is written to in an ISR. A compiler might decide that your value is constant and replace it with a constant if it doesn't see the change being made in the ISR>

	When to use "volatile":		When to use "volatile":

Hwang at 07:22, 9 December 2008

2008-12-09T07:22:42Z

← Older revision		Revision as of 02:22, 9 December 2008
Line 78:		Line 78:
	</pre>		</pre>
	We can also use the <tt>#ifndef</tt> directive, which means "if not defined".		We can also use the <tt>#ifndef</tt> directive, which means "if not defined".

			==Volatile Variables==
			volatile keyword tells compiler not to optimize the variable because it can change unexpectedly (e.g. through hardware or an interrupt)

			When to use "volatile":
			*global variables that can be changed by an ISR
			*variables that can be changed by hardware (e.g. if you put your variable in the hardware register of a counter)

			example:
			volatile unsigned int counter_val; //this will declare counter_val to be volatile

Hwang: /* Conditional Compilation */

2008-12-09T07:00:18Z

Conditional Compilation

← Older revision		Revision as of 02:00, 9 December 2008
Line 74:		Line 74:
	...		...
	#else		#else
	...		...
	#endif		#endif
	</pre>		</pre>
			We can also use the <tt>#ifndef</tt> directive, which means "if not defined".

Hwang at 06:55, 9 December 2008

2008-12-09T06:55:22Z

@@ Line 40: / Line 40: @@
 *PR5H = 10000/256;
 *PR5L = 10000%256;
 </pre>

Hwang: /* Writing Directly to a Memory Address */

2008-12-09T06:31:33Z

Writing Directly to a Memory Address

← Older revision		Revision as of 01:31, 9 December 2008
Line 1:		Line 1:
	__TOC__		__TOC__
			==Declaring Variables==
			Implementation of datatypes like char, int, long, short, etc. are compiler specific. For example, the keyword <tt>int</tt> may mean an 8-bit unsigned integer in one compiler and a 16-bit signed integer in another compiler. This will often cause problems when people try to read or reuse your code. '''Be as specific as possible'''.
			<pre>
			good:
			int8 some_int;
			int32 some_32bit_int;
			unsigned char some_unsigned_8_bit_char;

			bad:
			char some_char;
			int some_int;
			</pre>

	==Writing Directly to a Memory Address==		==Writing Directly to a Memory Address==
	When configuring the peripherals of the PIC, one usually checks the PIC's datasheet and manually writes the bits corresponding to the desired settings to the special function registers (SFRs). The CCS library attempts to make things easier by wrapping up the SFRs into function calls such as <tt>setup_adc</tt>, etc. However, some functionality may be "lost in translation," or the documentation may be so vague that it's easier just to the write the correct bits directly to the SFRs. Unfortunately, the SFR names used in the datasheet are not defined in CCS's device <tt>.h</tt> files, so we'll have to define them ourselves.		When configuring the peripherals of the PIC, one usually checks the PIC's datasheet and manually writes the bits corresponding to the desired settings to the special function registers (SFRs). The CCS library attempts to make things easier by wrapping up the SFRs into function calls such as <tt>setup_adc</tt>, etc. However, some functionality may be "lost in translation," or the documentation may be so vague that it's easier just to the write the correct bits directly to the SFRs. Unfortunately, the SFR names used in the datasheet are not defined in CCS's device <tt>.h</tt> files, so we'll have to define them ourselves.
Line 5:		Line 18:
	As an example, the CCS library doesn't have a function that will write to PR5 (Timer5 period match register) for devices (such as the PIC18F4431) that have them. However, we can look in the datasheet in the "Special Function Registers" section to find memory address of the SFR we want.		As an example, the CCS library doesn't have a function that will write to PR5 (Timer5 period match register) for devices (such as the PIC18F4431) that have them. However, we can look in the datasheet in the "Special Function Registers" section to find memory address of the SFR we want.

	''Note:'' When writing to 16-bit SFRs with a high and low byte which may be changing (such as a timer register), it is important to write to the high byte first and write to the low byte second. When reading from the 16-bit register, read the low byte first and the high byte second. The high byte is actually a buffer; writing to the low byte will automatically load the high byte into the register, and reading from the low byte will automatically copy the current value into the high byte register, in a single operation. This prevents the data from changing or rolling over in the time between reading or writing the first and second registers.		'''Note:''' When writing to 16-bit SFRs with a high and low byte which may be changing (such as a timer register), it is important to write to the high byte first and write to the low byte second. When reading from the 16-bit register, read the low byte first and the high byte second. The high byte is actually a buffer; writing to the low byte will automatically load the high byte into the register, and reading from the low byte will automatically copy the current value into the high byte register, in a single operation. This prevents the data from changing or rolling over in the time between reading or writing the first and second registers.

	For the CCS compiler, you can use the <tt>#byte</tt> preprocessor directive to tell it to place a variable at a specific memory address. Look up the correct memory address in the datasheet (the 0x denotes hexadecimal notation):		For the CCS compiler, you can use the <tt>#byte</tt> preprocessor directive to tell it to place a variable at a specific memory address. Look up the correct memory address in the datasheet (the 0x denotes hexadecimal notation):

Hwang: /* Writing Directly to a Memory Address */

2008-12-09T06:26:28Z

Writing Directly to a Memory Address

← Older revision		Revision as of 01:26, 9 December 2008
Line 5:		Line 5:
	As an example, the CCS library doesn't have a function that will write to PR5 (Timer5 period match register) for devices (such as the PIC18F4431) that have them. However, we can look in the datasheet in the "Special Function Registers" section to find memory address of the SFR we want.		As an example, the CCS library doesn't have a function that will write to PR5 (Timer5 period match register) for devices (such as the PIC18F4431) that have them. However, we can look in the datasheet in the "Special Function Registers" section to find memory address of the SFR we want.

	''Note:'' When writing to 16-bit SFRs which may be changing (such as a timer register), it is important to write to the high byte first and write to the low byte second.		''Note:'' When writing to 16-bit SFRs with a high and low byte which may be changing (such as a timer register), it is important to write to the high byte first and write to the low byte second. When reading from the 16-bit register, read the low byte first and the high byte second. The high byte is actually a buffer; writing to the low byte will automatically load the high byte into the register, and reading from the low byte will automatically copy the current value into the high byte register, in a single operation. This prevents the data from changing or rolling over in the time between reading or writing the first and second registers.

			For the CCS compiler, you can use the <tt>#byte</tt> preprocessor directive to tell it to place a variable at a specific memory address. Look up the correct memory address in the datasheet (the 0x denotes hexadecimal notation):
			<pre>
	//put variables at memory location		//put variables at memory location
	#byte PR5L=0xF90 //PR5 low byte		#byte PR5L=0xF90 //PR5 low byte
	#byte PR5H=0xF91 //PR6 high byte		#byte PR5H=0xF91 //PR6 high byte
			</pre>
	...
			Later in the code, when we want to set the values, we can set it like any other variable:
⚫	PR5H = 10000/256;
			<pre>
⚫	PR5L = 10000%256;
		⚫	PR5H = 10000/256; //take only high bits
		⚫	PR5L = 10000%256; //take only low bits
			</pre>

	~~Can~~ also use pointers:		Alternatively, we can also use pointers:
			<pre>
	int8* PR5H;		int8* PR5H;
	int8* PRHL;		int8* PRHL;
Line 21:		Line 27:
	*PR5H = 10000/256;		*PR5H = 10000/256;
	*PR5L = 10000%256;		*PR5L = 10000%256;
			</pre>

Hwang at 06:18, 9 December 2008

2008-12-09T06:18:59Z

New page

__TOC__
==Writing Directly to a Memory Address==
When configuring the peripherals of the PIC, one usually checks the PIC's datasheet and manually writes the bits corresponding to the desired settings to the special function registers (SFRs). The CCS library attempts to make things easier by wrapping up the SFRs into function calls such as <tt>setup_adc</tt>, etc. However, some functionality may be "lost in translation," or the documentation may be so vague that it's easier just to the write the correct bits directly to the SFRs. Unfortunately, the SFR names used in the datasheet are not defined in CCS's device <tt>.h</tt> files, so we'll have to define them ourselves.

As an example, the CCS library doesn't have a function that will write to PR5 (Timer5 period match register) for devices (such as the PIC18F4431) that have them. However, we can look in the datasheet in the "Special Function Registers" section to find memory address of the SFR we want.

''Note:'' When writing to 16-bit SFRs which may be changing (such as a timer register), it is important to write to the high byte first and write to the low byte second.

//put variables at memory location
#byte PR5L=0xF90 //PR5 low byte
#byte PR5H=0xF91 //PR6 high byte
...
PR5H = 10000/256;
PR5L = 10000%256;

Can also use pointers:
int8* PR5H;
int8* PRHL;
PR5H = 0xF91;
PR5H = 0xF90;
*PR5H = 10000/256;
*PR5L = 10000%256;