gnupic: Re: test suites [SEC=UNCLASSIFIED]
Subject:
RE: test suites [SEC=UNCLASSIFIED]
From:
Michael Waters ####@####.####
Date:
18 Aug 2011 05:33:56 -0000
Message-Id: <7548A47B0E2E8643BE38DBBD8FD9CA1AD549F4D05F@BOM-VMBX-HO.bom.gov.au>
Hi Joe,
Two techniques I have used and found helpful in C PIC code
development are :
- the object oriented paradigm and
- test applications.
I've been using PICs off and on for years and became frustrated with
having to maintain essentially the same code in several projects.
Any time I made an improvement to say an LCD interface it wouldn't
automatically transfer to other projects. Eventually I decided to bite
the bullet and try to create a library containing the latest code. I've
been developing the library modules over the last 6-12 months (eg.
LCD, button, keypad interfaces) using the above ideas. A module is
made up of a C source file and an include file where all externally
visible functions have a prefix to their name identifying it with the
module; this parallels a C++ object. A small demo. app. uses the
module and exercises it to both demonstrate how the module is used
and for testing / development.
I'm happy with the results so far and have been thinking about
releasing it under the GPL. The code has been developed for the
PIC18F452 but should work on other 18F PICs at least. If you would like
a copy let me know.
Regards
Mike W.
________________________________________
From: Joe Pfeiffer ####@####.####
Sent: Wednesday, 17 August 2011 12:00 PM
To: gnupic
Subject: test suites
I'm curious as to what strategies people use to create test suites for
their projects....
I'm working on Yet Another Shop Toaster Oven (in addition to the
standard computer-controlled solder reflow temperature profile, I want
to be able to do things like powder-coat small parts in mine), so I've
got more devices to deal with than most past projects: the
thermocouple, the zero-crossing detector, the lcd, the timer, the
keypad....
I'd like to get my code working in bite-size chunks: first get a test
pattern up on an lcd, then interface the keypad..... the thing is,
when I discover a bug in a later test (say I discover something was
wrong with my lcd driver when I'm working on the keypad), I want to
make sure my bugfix gets propagated back properly. OK, at some level
the right answer is "make sure I do it", but I've been programming
long enough to have nearly infinite confidence in my ability to make
stupid mistakes.
I started to work on a scheme to break up the code in to various
include files for bit settings, constants, init code, driver code...
and quickly realized that I was creating something that was massively
unwieldy, and also (since I basically had to set things like the
tristate registers with bit-by-but sets and clears) really
inefficient.
So now we come back to my question: what do you guys do? Lots of
include files? Just one big chunk of source code (OK, it sort of
can't be longer than 2000 lines so it isn't that big)? Some sort of
m4-hell?
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
