Writing good/proper code

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

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.

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.

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.

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 ?

.

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


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

the above may help.

Nice work Dave. Perfect links to great reasons.

I was getting random resets and crashes like you describe but now I always refresh all TRIS, PORT and ADCON, CMCON, etc every time through the main loop or at least once per second.

As processors get smaller, run at lower voltages and faster, the impact of nearby static, lightning, fluoroescent light and electrical motor transients, cosmic rays, etc, etc all get worse.

My code runs over a year now without any hangs after I refreshed as above. The WDT approach is also helpful and can be used to increment a value in EEROM at each hard reset so you can analyse later if you got any WDT events but don't rely just on the WDT to save your code.

HTH
BrianT

Thanks for the advice to date.

I'm not clear what use should be made of the Watch Dog timer?

Assume that no activity after X Seconds means something is wrong and re-start? Or is there more to this?

On a new additional subject: ST input pins. Recently I wanted to use the hysterisis of the ST pins and did a test to check the thresholds.
Found that PORTB.0 (used as an interrupt INT0) was way off spec for the chip PIC18F8722:

Go off at 1.6 V
Go on at 2.7 V

The spec gives:
Go off at 1.5 to 1.3 V
Go on at 3.0 to 3.4 V

Test voltages supplied via a 10k pot and measured with a good meter - my new FLUKE! The differences are considerably outside spec. Anyone else had difficulties with the ST pins?

Regards Bill Legge

Hi Bill,

You got the WDT right.

I must say that i've gone through more than my share of Microchips datasheets and i can't remember ever seeing anything else than the usual 0,2-0,8Vdd spec for ST inputs. So if you're running your pic on 5v, anything less than 1v(0,2*Vdd) is guaranteed to be read as a 0(low) by the pic. Anything above 4v(0,8*Vdd) is guaranteed to be seen as 1(high). Everything in between is to be considered as unknown. This means that your trippoint should be found somewhere in this region. It does not say anything about the amount of hysteresis. I haven't checked this for many years but when i did i found that the trippoint was just below 0.5Vdd and the hysteresis was quite small (<100mv). My memory may be way off though.

So, if i need an input with a specified trippoint and a specified ammount of hysteresis i use a comparator(or op) with external resistors.

/Ingvar

Quote:

---

Originally Posted by mackrackit

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.

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