You are on page 1of 7

Mechatronics & Embedded Microcomputer Control

ME E4058
Fall 2015
Writing Embedded Programs for MicroChip Microcomputers

Software Standard for Assembly


Standards for Comments

Comments start with a leading semicolon (;)

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.

Standards for 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)

In line comments start in column 20 (1 or 2 additional tabs in editor)


In line comments should be short so they do not word wrap when printed.
Use a complete line for longer comments starting in column 8 (so they line up with OpCodes)

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

Comments on every line of Assembler code is recommended. (Assembly is difficult to read.)

General comments at the beginning of the program should state:


The overall purpose of the code.
The different modes (if applicable).
How the program operates (program flow) (for example, how the buttons and
switches work).
How the hardware is connected (to which ports and pins)
How registers are used.

Obscure points in the code should be explained.


Line comments should not wrap when printed. If you want to write a long comment, use
several lines and begin the comment at the margin.

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

Execution speed primarily depends on the number of instructions required to perform a


particular operation.
The branch instructions: goto, call, and the various return instructions require 2
instruction cycles.
The test instructions: incfsz and decfsz and the bit test btfsc and btfss require
2 instruction cycles if the test is positive. Otherwise, they use 1 instruction cycle.
All other instructions use 1 instruction cycle.
Therefore, in line code with few branches or tests has the highest execution speed.
Execution speed can be measured with the stopwatch in the development system.

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.

Grades for code case studies will be based on:


1.
2.
3.
4.
5.

Successful execution of all parts & bug free


Following the software standard
Liberal use of comments
Efficiency and creativity
Answers to questions

Columbia University
Mechatronics and Embedded Microcomputer Control

(50 %)
(10 %)
(10 %)
(20 %)
(10 %)

F. R. Stolfi 4
Software Standard

Software Standard for C


Standards for Comments

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.

Standards for Code

All instructions within functions (including main) should be indented.


All instructions within loops (for, while and do while) and conditionals (if, else if
and else) should be further indented.
Labels start in column 1 and are on a separate line (must end in a colon (:)).
Curly brackets ( { and } ) should be on a separate line and should align for a particular
instruction. (i.e. if the { for a while loop is in column 20, the } for the same loop should be in
column 20)
Additional indenting and spacing (C ignores whitespace) can be used to increase readability.

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)

User data storage names will have lowercase characters


Special function registers will always be uppercase (Compiler requirement)

Columbia University
Mechatronics and Embedded Microcomputer Control

F. R. Stolfi 5
Software Standard

Additional Programming Considerations for C


General

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:

The overall purpose of the code.


The different modes (if applicable).
How the program operates (program flow).
How the hardware is connected (to which ports and pins)
How registers are used.

Obscure points in the code should always be explained.

Efficiency

Efficiency in a C program is difficult to measure. In fact, memory efficiency, execution speed


and execution determinism (knowing exactly how long a particular bit of code requires to
execute) are the primary reasons why embedded programmers write in Assembly instead of C.
The compiler generates a file with the same filename as your source code and the extension lst
which shows how many Assembly instructions are generated by each of your C instructions if
you are interested.
You generally want to write short programs. Long programs will be considered to be inefficient
and points for inefficiency will be deducted.
You should reuse variables when possible (to save data memory).
You should declare variables to only be as large as required. (Do not use a double when an
unsigned integer will suffice or an integer when a character will suffice.)

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

You might also like