Writing good/proper code

[Bill Legge]

I've been using PBP, as a hobby, for two years.
Whilst my use of PBP and getting the PIC MCUs and peripherals working is improving, I and am starting to encounter a new rage of coding difficulties:

1. Programming Style. Some of my programs are over a 1000 lines and I find it tricky to keep them working - a change in one sub-routine stuffs-up another routine. This is despite avoiding spaghetti-code and using GOSUB rather than GOTO. Any advice or book recommended?

2. Long Term Stability. My code works OK but if I leave it running for a few days (e.g Weather Station software) it gets stuck. Re-Set the systems and they work OK - but tend to pack up after a few days (Problem is not power supply). I guess I'm missing some basic (pun or no-pun) commands? Anyone using some standard 'Keep thing working' commnads?

Regards Bill Legge

[Jerson]

A watchdog timer is the best way to ensure things are working. That is till the dog is alive and kicking - read power supply normal. If you stop feeding power to the dog, it dies and so does your code

There is no special magic to keep things going other than writing clean program flows. An example comes to mind from a few days ago. A post about a single 7 segment LED clock shows the type of coding that can assure you peace of mind.

I would also look specially at the stack nesting levels used in your code. Remember, many PICs can nest only 8 levels deep. Use of improper instructions. For example : using a gosub and returning with a goto can leave things on the stack. You should account for this.

[mackrackit]

I will add my two cents to what Jerson said.

If you do not have the GOSUB/GOTO mix up and your code runs all the way through hitting all of the variables and such along the way there is no reason for it to lock up after a hundred times. So it you are positive about the power supply there must be something else causing the problem. Stray EMF? Poor earth ground? MCLR getting a bad signal?

I think the best way of writing maintainable code is to write each sub routine as if it were a stand alone or destined as an include. Then all you have to do is change a variable name or aliases and it can even be used in another program. Love that copy/paste!
If written this way it should help the problem of one block messing another.

Add lots of comments, at least put a note in for each sub if not each line.

Books? Examples are free. Take a look at MELABS SDFS. Study the flow of that and you should learn alot. It is easy to maintain and tweak even though it is 2000+ lines with
comments.

[Bruce]

For me - I find it's easier to maintain large programs when they're broken into smaller
modules. With PBP I break tried & tested routines off into include or .bas files.

Then the majority of main routines using these include files end up being smaller more
managable programs. So you're not scrolling through thousands of lines of code in the
main routine.

One of the best examples here would be to look at all the neat stuff produced by Darrel
Taylor. He writes enormous utility routines as .bas or include files.

One example is DT_INTS-18.bas. It's around 949 lines of code. If code is specific to a
main project, I'll leave it in the main program. Generic utilities I'll place in include files
and just reuse them in other programs.

Over time you'll build up large tried & tested utility routines that you'll rarely need to debug
or worry about anymore, so the main programs get a LOT easier to write, maintain & debug.

[ruijc]

Hi all,

dont want to hijack this thread but Bruce just mentioned a good idea with the modules thing.

My question is simple:

Is there a thread or tutorial that teaches one to build include or .bas files ?

.

[mackrackit]

http://www.picbasic.co.uk/forum/showthread.php?t=3290


http://www.picbasic.co.uk/forum/show...=include+files

the above may help.

[jellis00]

Books? Examples are free. Take a look at MELABS SDFS. Study the flow of that and you should learn alot. It is easy to maintain and tweak even though it is 2000+ lines with
comments.

I went to MELABS site and tried to find what you were referring to as SDFS. Couldn't find anything. Can you explain? I would like to review it to see their coding structure recommendtions.

[mackrackit]

Looks like they call it SDFS3.zip now.
http://www.melabs.com/resources/samples.htm