gnupic: Thread: test suites


[<<] [<] Page 1 of 1 [>] [>>]
Subject: test suites
From: Joe Pfeiffer ####@####.####
Date: 17 Aug 2011 02:00:30 -0000
Message-Id: <20043.8377.92716.36133@snowball.wb.pfeifferfamily.net>

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?
Subject: Re: test suites
From: Joe M ####@####.####
Date: 18 Aug 2011 12:13:02 -0000
Message-Id: <CA+ib0oCFo+jA9o+H3Ma=3=L2UBjfWYex=z5ypw+z7ab34VL3Gw@mail.gmail.com>

Hello Joe,

I put my tests in a haskell script that spawned gpsim and ran all the
tests. It was easier to manage in Haskell as I was able to break up
the tests into modules, based on functionality.

Good luck,
Another Joe


On Tue, Aug 16, 2011 at 10:00 PM, Joe Pfeiffer
####@####.#### wrote:
> 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: ####@####.####
>
>
Subject: Re: test suites
From: Antonio Peixoto ####@####.####
Date: 19 Aug 2011 17:12:34 -0000
Message-Id: <CAGM4s9xU5jhROsB41yQt99CHp90ePKKUEPKDBowyGCxq64P-Gw@mail.gmail.com>

Hi Joe,

Microchip suite development offers you the MPASM™ Assembler, MPLINK™ Object
Linker and MPLIB™ Object Librarian.

See "DS33014K - MPASM™ Assembler, MPLINK™ Object Linker MPLIB™ Object
Librarian User’s Guide" for a detailed use of it.

With MPASM you can generate executable file or object file. So you can make
one file to each module you want (lcd, keyboard etc) and generate object
file to each module. You main program will call the functions in these
modules. When you compile your main program the MPLINK will join the code on
the modules with your main code and produce an executable code.

MPLIB helps you to maintain related function on libraries of function so you
can organize it in a better fashion. MPLINK also accept libraries as input.

I suggest you to maintain each function in a directory that contains:

   - the function code that will compiled as relocatable object file
   - A main program that will call the function in question. For these
   program you must know all inputs and expected outputs
   - A test suite data if is the case

I recommend you maintain your code under control version. MPLAB has
interface with various control version systems like Subversion, CVS e the
like. I use and like VisualSVN ans subversion server that you can download
at http://www.visualsvn.com/visualsvn/download/pre-release/.<http://www.visualsvn.com/visualsvn/download/pre-release/>You
can install an SVN Client if you want to see old version of the files
under control version, see what lines was changed, recover old version of
the function and so on. I use Tortoise Subversion Client that you can
download on the same link
above<http://www.visualsvn.com/visualsvn/download/pre-release/>
.

In MPLAB you can include last release of the object file in your project
(see view project tree). Doing so MPASM and MPLINK will be able to resolve
all references to external functions.

A good idea is to use the MPLAB to generate a makefile, so you will see and
learn more about what happens when you make or build all the code.

You can also use command line interface to generate your code, in this case
using make utility will be pretty beautiful.

Go ahead. Good Luck!!!

Peixoto


2011/8/16 Joe Pfeiffer ####@####.####

> 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: ####@####.####
>
>
Subject: Re: test suites
From: Joe Pfeiffer ####@####.####
Date: 20 Aug 2011 17:20:18 -0000
Message-Id: <20047.60620.509540.307441@snowball.wb.pfeifferfamily.net>

Thanks for comments so far on test suites and reusable code!  SDCC
looks really interesting to me -- you're certainly correct that C is
more readable than assembly code; I'm a little surprised that
something as small and screwy as a 12- or 16- series PIC could be
programmed effectively in C.  I'm going to have to play with that.
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.