Program Organization

[rossfree]

Hi all,

As I continue to learn programming skills I find myself second guessing how I go about organizing my program structure so that it is both readable and simple to modify. I was surprised that searching with keyword "organization" brought up only one or two threads having very little to do with program writing.

Can a few experts out there share there thoughts on how they go about organizing their program structure?

Thank you,

Ross

[mister_e]

Since everybody do it different. It depend on what you think is *easy to modify* and what is readdable. For my case i use common name for my variable and my called procedure. like

PiezoOutput VAR PORTA.0 ;Piezo pin

ReadI2cEEprom:
I2CRead ......
.....
return


I also add a lot of comment on my code, even on most lines. I Do a lot of subroutine and call them. So when i want to modify them i know exactly where to do (Easy to jump to with MicroCode Studio). Usually i do the same orgarnisation structure


DEFINES (osc , a/d ,Hser.....)
PINS definition and alias (Who and where)
VAR definition (what i use to work)

Main Procedure


Subroutine called by main or other subroutines

Hope this help

[Melanie]

You know I'm sure I've answered this very topic before, but damned if I can find it. Perhaps it was on the email list when I used to subscribe to that...

Anyhow... I near enough follow the same program structure every time for most of my programs... I can write a book about how and why things should be structured a particular way, but basically I pretty much ALWAYS follow the same pattern...

1. Comments & Objectives
2. PIC Config Fuse Definitions
3. PIC Hardware Definitions (ie Pin-Out & Port Assignments)
4. Software Definitions
4a. EEPROM Assignments
4b. RAM Assignments & variables
4c. Software Constants
5. Actual Program Start (usually a "Goto Start" jump)
6. Subroutines
7. Start: (Program Starts Here)
8. PIC Register Initialisation
9. External Hardware Initialisation (eg LCD's)
9a. External Hardware Settling Delay (usually needed with LCD's)
10. Loop: (Main Program Loop Point)
11. Main Program Body
12. Loop Counter & PIC/LCD Reinitialisation
13. Goto Loop
14. Interrupt Handler
15. Error & Special Handlers
16. End

Sometimes for simpler programs I put my subroutines at section 15 rather than at section 6 and do away with item 5, however placing the subroutines at 6 does save on Program Codespace (see other threads for further comments on this).

I am however MOST PARTICULAR that ALL Hardware definitions are together, all RAM definitions are together (and more often than not in alphabetical order too), likewise Constants, Subroutines etc etc. That way, I know where to find whatever I'm looking for. In larger more complex programs, I even place my subroutines in alphabetical order so I can find them easier (ie the subroutine GetKey will be located before the subroutine GetMessageExternal). Little things like that all help.

Section 12 needs some explanation. You initialise the PIC Registers at section 8. It's naïve to assume that they will stay that way forever. Static, EMP's and other disturbances do affect your hardware. To guard against those, I reinitialise my important PIC's registers (TRIS, OPTION_REG, CMCON etc etc) every 'n' times through the Loop (and secondary registers like ADCON before I use that particular piece of PIC hardware). Doing it at every pass is a waste, but I tend to reinitialise sometime between five and twenty seconds or so, and if I have an LCD, I ensure the display is cleared ($FE,1) and completely redisplayed at least once per minute. To this end I have PICs in the field that have been running constant 24/7 Mission Critical applications without break for YEARS on end in hostile Industrial Environments without failure. Obviously if your applications are not Mission Critical and you can afford to have your PIC throw an occasional wobbly, you can skip section 12.

Any one of these sections (especially individual subroutines) can be replaced with an "include" statement. My 3-Button Keyboard handler for example is pretty much identical in every program I've ever written that uses those 3 Buttons, as are subroutines for certain functions like displaying messages from Internal or External EEPROM, Date and Time verification, higher Math functions, and the list goes on and on. They are obvious targets for using "include". But I don’t do it.

Why? Because I like to 'see' everything in my program when I scroll through it. Sometimes you'll spot something obvious that you'd otherwise miss if it was invisible (having being linked with an "include"). But that's just my personal preference.

Melanie