Firmware Tips & Techniques - Revision history

Dirknerkle: /* Changing Firmware Settings */

2017-11-03T13:08:16Z

Changing Firmware Settings

Dirknerkle: /* Changing Firmware Settings */

2016-06-04T15:38:29Z

Changing Firmware Settings

Dirknerkle: /* Changing Firmware Settings */

2016-06-04T15:37:54Z

Changing Firmware Settings

Admin: /* The Programmer */

2015-06-28T14:36:01Z

The Programmer

Admin: /* Changing Firmware Settings */

2015-05-08T15:19:14Z

Changing Firmware Settings

Admin: /* Changing Firmware Settings */

2015-05-08T15:17:53Z

Changing Firmware Settings

Admin: /* Changing Firmware Settings */

2015-05-08T15:17:10Z

Changing Firmware Settings

Admin: /* Changing Firmware Settings */

2015-05-08T14:34:45Z

Changing Firmware Settings

Admin: /* Changing Firmware Settings */

2015-05-08T14:32:35Z

Changing Firmware Settings

Admin: /* Changing Firmware Settings */

2015-05-08T14:31:34Z

Changing Firmware Settings

@@ Line 70: / Line 70: @@
 First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code may be reserved for different functions, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search within the source code for the items that you can change. In some cases, the original programmer may insert comments into the code to tell you what you can change and what you should NOT change.
-But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just ''examples'' of some names that might have been used in the code you're reviewing:
+But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name: in some cases, defining an item to 0 or 1 means that 0 is the "off" or "false" setting while 1 is the "on" or "true" setting. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just ''examples'' of some names that might have been used in the code you're reviewing:
-* '''Oscillator or crystal speed.''' This is what sets the overall speed of the chip itself which relates to how fast it can process tasks. You might look for something like:
+* '''Oscillator or crystal speed.''' This is what sets the overall speed of the chip itself which relates to how fast it can process tasks. Some chips can operate at different speeds and this generally is used to set the chip to its best speed for optimum performance. You might look for something like:
 ::: #define CLOCKRATE 18432000
 ::: #define OSCRATE 16000000
 ::: #define CLKSPEED 12000000
-* '''Baud rate.''' This is the speed at which the firmware can receive data from the controller. Some ideas of things to look for:
+* '''Baud rate.''' This is the speed at which the firmware can receive data from the computer. For example, if the computer is set to send data at 57600 baud, then the chip has to be set the same way or it won't be able to receive the data. Some ideas of things to look for:
 ::: #define BAUDRATE 115200
 ::: #define COMSPEED 9600
@@ Line 87: / Line 87: @@
 ::: #define DMX_START_ADDRESS 1
-* '''PWM.''' This stands for 'pulse-width-modulation' and it relates to the method the firmware uses to deal with dimming.
+* '''PWM.''' This stands for 'pulse-width-modulation' and it relates to the method the firmware uses to deal with dimming. It can apply to either AC or DC lights. Generally speaking, PWM provides for smoother dimming.
 ::: #define PWM 1
 ::: #define PWM_MODE 0
 ::: #define PWM TRUE
-* '''DC settings.''' This usually relates to something that affects LED lighting and is sometimes closely related to PWM. If so, usually the firmware makes a comment about the setting itself.
+* '''DC settings.''' This usually relates to something that affects LED lighting and is sometimes closely related to PWM. If so, usually the firmware makes a comment about the setting itself. Generally speaking, the zero-cross signal is needed only for AC lights and in DC mode, the program can usually skip the AC-related computations, thus allowing the chip to be more efficient.
 ::: #define DC_BUILD 0
 ::: #define DCBUILD 1
-* '''CTR_LOCKOUT.''' This is more related to LED lighting than for A/C incandescents and isn't always used. It's a setting that can change how LEDs react to the firmware in the lower intensity range.
+* '''CTR_LOCKOUT.''' This is more related to LED lighting than for A/C incandescents and isn't always used. It's a setting that can change how LEDs react to the firmware in the lower intensity range -- the LEDs dim down further before they go out when this setting is lower.
 ::: #define CTR_LOCKOUT 40
 ::: #define CTR_LOCKOUT 32
 ::: #define CTRLOUT 16
-* '''Output Polarity.''' This is a tricky little thing that reverses the "on" setting from being high on the output pin (+5V) to being low (0v). Long explanation here, but it essentially changes whether the output reacts to positive output or negative output. Since it's a true/false setting and if it's active, the value becomes true. Simply placing a semi-colon comment mark at the very start of the program line turns the line off and logically sets the value to false.
+* '''Output Polarity.''' This is a tricky little thing that reverses the "on" setting from being high on the output pin (+5V) to being low (0v). Long explanation here, but it essentially changes whether the output reacts to positive output or negative output. Since it's a true/false setting and if it's active, the value becomes true. Simply placing a semi-colon comment mark at the very start of the program line turns the line off and logically sets the value to false. This setting exists to accommodate different kinds of electrical circuits: some of them invert the polarity of the signal on their own and this setting in effect "fools" them so when the circuit inverts the signal, the result is a properly polarized signal sent to the remote devices.
 ::: #define OUTPUT_NEGATIVE_TRUE
 ::: ; #define OUTPUT_NEGATIVE_TRUE   (the semi-colon at the start of the line would make it false)

@@ Line 70: / Line 70: @@
 First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code may be reserved for different functions, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search within the source code for the items that you can change. In some cases, the original programmer may insert comments into the code to tell you what you can change and what you should NOT change.
-But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just [[examples]] of some names that might have been used in the code you're reviewing:
+But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just ''examples'' of some names that might have been used in the code you're reviewing:
 * '''Oscillator or crystal speed.''' This is what sets the overall speed of the chip itself which relates to how fast it can process tasks. You might look for something like:

@@ Line 70: / Line 70: @@
 First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code may be reserved for different functions, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search within the source code for the items that you can change. In some cases, the original programmer may insert comments into the code to tell you what you can change and what you should NOT change.
-But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just examples of some names that might have been used in the code you're reviewing:
+But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just [[examples]] of some names that might have been used in the code you're reviewing:
 * '''Oscillator or crystal speed.''' This is what sets the overall speed of the chip itself which relates to how fast it can process tasks. You might look for something like:

@@ Line 46: / Line 46: @@
 :* The computer doesn't recognize the USB device.
 :* The compiler software doesn't recognize the programming device.
-:* The device is cheaply made or assembled, causing inconsistent behavior.
+:* The programmer is cheaply made or assembled, causing inconsistent behavior.
 :* There is no support from the manufacturer; don't expect Microchip to support non-Microchip products.
 :* Standalone programming software may not recognize the programming device.
-:* The device may have flaws that produce inconsistently programmed chips, which then perform erratically if at all.
+:* The programmer may have flaws that produce inconsistently programmed chips, which then perform erratically if at all.
 == ICSP ==

@@ Line 69: / Line 69: @@
 First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code may be reserved for different functions, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search within the source code for the items that you can change. In some cases, the original programmer may insert comments into the code to tell you what you can change and what you should NOT change.
-But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything.
+But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything. The variable names here are just examples of some names that might have been used in the code you're reviewing:
 * '''Oscillator or crystal speed.''' This is what sets the overall speed of the chip itself which relates to how fast it can process tasks. You might look for something like:

@@ Line 67: / Line 67: @@
 == Changing Firmware Settings ==
-First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code is reserved for different things, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search for the items that you can change.
+First of all, understand that program source code is written by many different authors and consequently, code design is usually different using perhaps different words, different variable names, different locations within the code may be reserved for different functions, etc. Therefore, there isn't a hard-and-fast rule for declaring and designing the code -- and to make changes, sometimes you have to search within the source code for the items that you can change. In some cases, the original programmer may insert comments into the code to tell you what you can change and what you should NOT change.
 But there are many common items that users change and it's worth noting some of them here. More often than not, you'll find these items somewhere near the beginning/top sections of the source code and they're often listed as a #define variable. Do NOT change the name of the variable -- they are usually upper/lower case sensitive. Usually all you need to change is the number or value that follows the variable name. Also take heed of the formatting of the line which is very specific; where there's a space, keep the space. Don't insert any extra spaces between anything.

@@ Line 102: / Line 102: @@
 * '''Output Polarity.''' This is a tricky little thing that reverses the "on" setting from being high on the output pin to being low. Long explanation here, but it essentially changes whether the output reacts to positive output or negative output. Since it's a true/false setting and if it's active, the value becomes true. Simply placing a semi-colon comment mark at the very start of the program line turns it off and effectively sets it to false.
 ::: #define OUTPUT_NEGATIVE_TRUE
-::: ; #define OUTPUT_NEGATIVE_TRUE   (the semi-colon at the start of the line would turn it off)
+::: ; #define OUTPUT_NEGATIVE_TRUE   (the semi-colon at the start of the line would make it false)

← Older revision		Revision as of 14:31, 8 May 2015
Line 102:		Line 102:
	* '''Output Polarity.''' This is a tricky little thing that reverses the "on" setting from being high on the output pin to being low. Long explanation here, but it essentially changes whether the output reacts to positive output or negative output. Since it's a true/false setting and if it's active, the value becomes true. Simply placing a semi-colon comment mark at the very start of the program line turns it off and effectively sets it to false.		* '''Output Polarity.''' This is a tricky little thing that reverses the "on" setting from being high on the output pin to being low. Long explanation here, but it essentially changes whether the output reacts to positive output or negative output. Since it's a true/false setting and if it's active, the value becomes true. Simply placing a semi-colon comment mark at the very start of the program line turns it off and effectively sets it to false.
	::: #define OUTPUT_NEGATIVE_TRUE		::: #define OUTPUT_NEGATIVE_TRUE
		+	::: ; #define OUTPUT_NEGATIVE_TRUE (the semi-colon at the start of the line would turn it off)