[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: test suites [SEC=UNCLASSIFIED]
From: Joe Pfeiffer ####@####.#### Date: 18 Aug 2011 17:54:02 -0000 Message-Id: <20045.20917.244324.551274@snowball.wb.pfeifferfamily.net> I'm working down at the bottom end (12F and 16F series), and assembly code (does a C compiler even exist?). I guess what I'm really looking for here is advice on reusable code (and reusing code using something more automated than copy-and-paste) down in this environment... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: test suites [SEC=UNCLASSIFIED]
From: Michael Waters ####@####.#### Date: 19 Aug 2011 02:31:18 -0000 Message-Id: <7548A47B0E2E8643BE38DBBD8FD9CA1AD549F4D060@BOM-VMBX-HO.bom.gov.au> Hi Joe, I use Small Device C Compiler (SDCC) which is an open source project supporting a range of micro-controller architectures. From the on-line documentation it does support the 16F series and at least some 12F PICs. I would use a C compiler as much as possible simply because the code is more readible when it comes to maintenance later on (even tho. assembler is more fun to write). If assembler is require it can be embedded in the C coded. The problem with SDCC is that it has a fairly steep learning curve. There is plenty of documentation but it doesn't spoon feed you. For this reason I would suggest getting some working code with a build system to use as a template. Mike W. ________________________________________ From: Joe Pfeiffer ####@####.#### Sent: Friday, 19 August 2011 3:53 AM To: ####@####.#### Subject: RE: test suites [SEC=UNCLASSIFIED] I'm working down at the bottom end (12F and 16F series), and assembly code (does a C compiler even exist?). I guess what I'm really looking for here is advice on reusable code (and reusing code using something more automated than copy-and-paste) down in this environment... --------------------------------------------------------------------- To unsubscribe, e-mail: ####@####.#### For additional commands, e-mail: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |