Searching \ for '[PIC:] Software Testing - How create PIC routine t' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Software Testing - How create PIC routine t'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Software Testing - How create PIC routine t'
2004\08\12@103612 by Ed Sutton

flavicon
face
I want to write test cases for all our PIC routines, for example, 16-bit
math routines, etc.  I am interested on how others have done this.

Can the simulator be used for test cases? Should it be?  I was hoping
there might be some scriptable way to provide inputs and log outputs.

Thanks in advance for any tips or suggestions,

-Ed

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@105934 by Sergio Masci

picon face
----- Original Message -----
From: Ed Sutton <.....esuttonKILLspamspam@spam@NOMADICS.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 3:35 PM
Subject: [PIC:] Software Testing - How create PIC routine test cases?


> I want to write test cases for all our PIC routines, for example, 16-bit
> math routines, etc.  I am interested on how others have done this.
>
> Can the simulator be used for test cases? Should it be?  I was hoping
> there might be some scriptable way to provide inputs and log outputs.
>
> Thanks in advance for any tips or suggestions,
>
> -Ed

Using the XCASM assembler and XCSIM simulator you can embed high level
simulation statements directly in the assembler source. This mechanism allows
you to generate complex values as inputs to routines and complex values to
compare against the results. XCASM and XCSIM are not free. More info can be
found at
http://www.xcprod.com/titan/ASM-DOC/XCSIM/statements.html

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@110349 by M. Adam Davis

flavicon
face
In C is relatively easy since that's a portable language.

Assembly is probably best done using a simulator.  I haven't done it
myself, but you might look at GPSIM, which I suspect has (or is) a
command line mode that will accept input and produce output.

-Adam

Ed Sutton wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@111600 by Randy Glenn

picon face
Interesting idea - a testing framework for PIC assembler code. Makes
me want to dig up the source for JUnit or NUnit...

I don't know about the Microchip simulator, but GPSIM seems only to
allow stimulus from within the UI, not from the command line.

The problem with stiumulus is that (I think) it can only be used on
the I/O ports, not just a given register.

On Thu, 12 Aug 2004 09:35:25 -0500, Ed Sutton <@spam@esuttonKILLspamspamnomadics.com> wrote:
{Quote hidden}

--
-Randy Glenn
Computer Eng. and Mgt. Year IV, McMaster University
Chair, McMaster IEEE Student Branch

randy.glenn-at-gmail.com - glennrb-at-mcmaster.ca
randy.glenn-at-computer.org - randy_glenn-at-ieee.org
http://www.randyglenn.ca

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@112427 by Russell McMahon

face
flavicon
face
> > I want to write test cases for all our PIC routines, for example, 16-bit
> > math routines, etc.  I am interested on how others have done this.


Very crude universal real world solution:
Assemble routines and (eg serial) I/O
Send data to PIC and return answer.
Complete data generated and result logging then under control of PC.
As long as transfer to and from serial routines is OK this should allow
rigorous testing.

       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@122244 by Scott Dattalo

face
flavicon
face
On Thu, 12 Aug 2004, Ed Sutton wrote:

> I want to write test cases for all our PIC routines, for example, 16-bit
> math routines, etc.  I am interested on how others have done this.
>
> Can the simulator be used for test cases? Should it be?  I was hoping
> there might be some scriptable way to provide inputs and log outputs.
>
> Thanks in advance for any tips or suggestions,

Ed,

Here are two ways to write regression tests. First, you can write self
checking code. For example, if you're writing a regression test to varify
a new algorithm, then you can either try comparing it to a different
implementation of the algorithm (that presumably is correct) or by
explicitly checking the return results. Some of the square root routines
that I've tested use this approach. For example, I know that the sum of
the first N odd integers is equal to N^2. So I wrote a routine that kept a
running sum of the first N odd integers and fed that sum to a square root
routine. The code checks itself and will jump to a routine that indicates
a failure.

A similar technique is the way in which the SDCC PIC regression tests were
constructed. For this, I wrote code that supplied specific inputs and
verified that the proper output was returned. This was automated by a
series of scripts.

The second way to perform regression tests is along the lines Sergio
suggests. Essentially, you instrument your source code with special
pragmas that provide an interface to an external application. I'd consider
Sergio's XCASM if I were you since MPASM is a relatively primitive
assembler by comparison.

Despite MPASM's (and thus gpasm's) limitations, I'm in the process of
extending gpsim (http://www.dattalo.com/gnupic/gpsim.html) in a way that
will allow such tests. Probably the most powerful newly added feature is a
socket interface to the simulator. The socket interface allows you to
start the simulator in the background, but control it from a separate
application. In your case, you could do something like instruct the
simulator to load a certain source file, instrument it with breakpoints,
execute it, examine registers, etc.

In addition to the socket interface, I've recently added other regression
testing features. For example, gpsim now supports register assertions and
three state numbers (a bit can be high, low, or uninitialized). The
register assertions are associated with specific instructions and will
halt the execution if the assertion is false. The three state numbers are
useful for verifying that stuff is initialized before it's used.

These new features to gpsim still are being worked on. However, gpsim
already supports a variety of tools like scripting, rich breakpoints,
stimuli, external modules, etc...

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@125534 by Ed Sutton

flavicon
face
Hi Scott,

Scott Dattalo wrote:

> Despite MPASM's (and thus gpasm's) limitations, I'm in the process of
> extending gpsim (http://www.dattalo.com/gnupic/gpsim.html) in a way that
> will allow such tests. Probably the most powerful newly added feature is a
> socket interface to the simulator. The socket interface allows you to
> start the simulator in the background, but control it from a separate
> application. In your case, you could do something like instruct the
> simulator to load a certain source file, instrument it with breakpoints,
> execute it, examine registers, etc.

It sounds like this would do what I want.  Using GPSIM I could do all
this programatically right?

1 - Load math routine under test into simulator
2 - Break at inputs to modify inputs
3 - Break at outputs to read and log outputs
4 - Repeat until done

Sergio's XCASM assembler and XCSIM approach sounded good as well.

Also, automating a serial I/O interface for inputs and output logging
sounded like a good approach as well.

Once I get into this deeper, building a NUnit/Junit interface might be
worthwhile as well.

http://www.nunit.org/
http://www.junit.org/

-Ed

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...