Real-Time Programming Good Practices N. Delson

Objective of Good Programming  Programs that can be easily updated and modified.  Programs that can be easily verified and debugged.  Programs that can be easily understood by others (including author three months after writing). Additional Objectives for Real-Time Programming  High speed  Low memory use  Meet accuracy recruitments often with integer math Objective of Good Programming  Programs that can be easily updated and modified.  Programs that can be easily verified and debugged.  Programs that can be easily understood by others (including author three months after writing). Additional Objectives for Real-Time Programming  High speed  Low memory use  Meet accuracy recruitments often with integer math

Good Programming Methods  Modularity Modularity  Generalization Generalization  Documentation and Notation Documentation and Notation Good Programming Methods  Modularity Modularity  Generalization Generalization  Documentation and Notation Documentation and Notation

 Use meaningful variable names  Document as you write code  Use meaningful variable names  Document as you write code Good ExampleBad Example % GOOD DOCUMENTATION % Define system parameters arm_length = 0.5; % arm length in meters alpha = 25*pi/180; % angle of motion in radians dalpha = 0.1; % angular velocity in radians / second time_step = 0.01; % seconds % Calc new angle using Euler method alpha_new = alpha + dalpha*time_step; % BAD DOCUMENTATION % (bad: no short overview of code) length = 0.5; % (bad: no units!) a = 25; % (bad: variable name too short and use of angles instead of radians) da = 0.1; % (bad: no units) time = 0.01; %(bad: ambiguous variable name) % (bad: no short overview of code) a = a + da*time; % (bad: reuse of variable name is confusing)

Modularity  In a well-written modular program, one module can be updated without requiring changes in the other parts of the program. When should one use a subroutines or functions?  When there are logical separate functional needs  Whenever one finds repeated code Printer dialog box example

Generalization  Never hardcode values into program; use variable or constants instead.  Use arrays instead of sequentially numbered variables.  Never hardcode values into program; use variable or constants instead.  Use arrays instead of sequentially numbered variables. Good ExampleBad Example % GOOD CODE % Define number of links as variable % and use arrays when possible nlink = 4; % number of links % use loop to easily display link lengths for ilink=1:nlink disp(link_length(ilink)); end % No code changes are required if the value of nlink is changed. % More importantly code corrections need to be done in one location only % BAD CODE % The following code may be easy to start writing, % but does not allow easy changes to number of links or use of loops disp(link_length_1); disp(link_length_2); disp(link_length_3); disp(link_length_4);

Real-Time Examples  Analog to Digital Input (A/D)  Digital Input  Positive and Negative Numbers  Integer Math  Serial Communication  Motor Driver  Analog to Digital Input (A/D)  Digital Input  Positive and Negative Numbers  Integer Math  Serial Communication  Motor Driver