[<<] [<] 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 [>] [>>] |