Professional Documents
Culture Documents
ME E4058
Fall 2015
Writing Embedded Programs for MicroChip Microcomputers
When you print your code, comments should not wrap. Keep in-line comments short or use full
lines.
General comments at the beginning of the program are surrounded by a line with 60 '*'
Initialization code is surrounded by 60 '%'
Main control loop is surrounded by 60 '&' (if applicable)
Interrupt service routines are surrounded by 60 '~'
The number of symbols is approximate (I will not be counting them.)
Feel free to use other symbols to delineate other parts of your code.
Labels start in column 1 and are on a separate line. Label names will have both uppercase and
lowercase characters
OpCodes start in column 8 (2 tabs in editor) again approximate. The important part is that
OpCodes, Operands and In Line Comments should line up.
OpCodes should be all lowercase.
Operands start in column 16 (1 or 2 additional tabs in editor)
There will always be a jump in location 4 to an interrupt service routine (even if it is a dummy)
All programs will have a State register with the bits called out in the general comments (You
should use it meaningfully)
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 1
Software Standard
Naming Standards
Initialization code will always have a label which starts with "init"
An interrupt service routine code will always have a label which starts with "isr" (interrupt
service routine)
User data storage names will have both uppercase and lowercase characters.
Special function registers will always be uppercase (Assembler requirement)
Programming Considerations
General
Your program must perform all the requirements listed in the case study.
Code should be as bug free as possible. Check all the warnings and messages that the
Assembler gives you and eliminate all that you can.
You should set all unused pins to inputs.
Set configuration bits in the code with " __CONFIG B'11111110110010' " (i.e. underscore
underscore CONFIG)
Comments
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 2
Software Standard
Efficiency
Efficiency in an Assembler program is measured by memory efficiency and execution speed.
Memory Efficiency
Program Memory
The VLIW MicroChip PIC16F74 uses 1 program memory location for each instruction.
The fewer the instructions, the more efficient use of program memory.
If a certain operation is used many times in a program, consider making it a subroutine and
calling it when you want to use it.
Data Memory
Data memory use depends on the number of registers that you define.
Special Function Registers (SFR) are always defined and do not add to data memory efficiency.
Consider using the same register for several operations.
Consider using SFRs instead of defining your own register.
Execution Speed
Trade-Off
There is often a trade-off between program memory size and execution speed. (For example,
subroutines require little memory but execute more slowly because the call and return
instructions each require 2 instruction cycles.)
When you write your program it is always desirable to comment why it was written a certain
way. (For example, you might say that some code is a copy of code from another operation but
was repeated for better execution speed.) This helps you understand your program when you
read it at a later time and helps your instructor with grading by demonstrating that you
understand the trade-off.
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 3
Software Standard
Creativity
Creativity in programming is difficult to quantify but you will know it when you do it.
Most creativity leads to better efficiency either in memory use or execution speed.
Creativity can also lead to efficient use of input / output ports. You cannot really demonstrate
this in your case study but if you can determine a more efficient use of ports, add a comment to
your program.
If you try to be very creative to the point where the instructor (who is assigning a grade) may
not understand what you are doing, add some comments.
Columbia University
Mechatronics and Embedded Microcomputer Control
(50 %)
(10 %)
(10 %)
(20 %)
(10 %)
F. R. Stolfi 4
Software Standard
Comments in a line start with 2 leading forward slashes (//). You can also start a multi-line
comment with a forward slash asterisk (/*) ending with an asterisk forward slash (*/)
In line comments should be short so they do not word wrap when printed.
Use a complete line for longer comments
General comments at the beginning of the program are surrounded by a line with 60 '*'
Initialization code is surrounded by 60 '%'
Main function is surrounded by 60 '&'
Interrupt service routines are surrounded by 60 '~'
Feel free to use other symbols to delineate other parts of your code. All C functions should be
surrounded by delimiters.
Naming Standards
Initialization functions will always have a name which starts with "init"
An interrupt service routine function will always have a name which starts with "isr". The
format is
(void) interrupt isrName (void)
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 5
Software Standard
Code should be as bug free as possible. In addition to all the warnings and messages, eliminate
any default declarations. (All undeclared variables and functions are assumed to be integers.
Even if you want these to be integers, you should declare them.)
The Microchip PIC16F74 has only an 8 level deep stack for subroutine calls. This means that
nesting C functions (a common C programming practice) can only be done to 8 levels.
Exceeding this will not give you an error during compile but will give you a runtime error
when you simulate your code.
Remember to set configuration bits for the code
Comments
You typically do not have to comment C code as much as Assembly since it is more readable
but the use of comments will still be considered in your grade. There is generally no such thing
as too many comments.
Your program should always have general comments at the beginning of the file. As in
Assembler, these general comments should state:
Efficiency
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 6
Software Standard
Avoid higher level math when possible. In particular, avoid floating point math. (If you
remember from Assembly, the microcomputer can add and subtract characters in one
instruction. The PIC16F74 and PIC16F73 do not have a hardware multiply.)
Since you are writing code for a processor dedicated to execute your program, there is
generally no advantage to declaring variables within functions rather than globally. (This would
not be the case if you were using a Real Time Operating System (RTOS) with the embedded
processor. An RTOS is not generally used in Mechatronics products.)
Creativity
Creativity in C is usually easier than in Assembly. In fact, creative C programs are the measure
of embedded programming ability in industry.
Again, if you try to be very creative to the point where the instructor may not understand what
you are doing, add some comments.
Columbia University
Mechatronics and Embedded Microcomputer Control
F. R. Stolfi 7
Software Standard