Sebastien LELONG wrote:
>
> My main worry is how the number of test can grow (number of columns
> in the matrix), while the number of target could stay low (number of
> rows). I mean, how many board files will we have ? Do people have as
> many boards as PICs ? About the number of columns, while generating
> the matrix, I thought it would be better to check what if the feature
> used in the tests. This means looking into the code, search for
> "include" statement, and report them: columns don't show tests, but
> the lib they use.
If you mean special test-boards which are only populated for a specific
test than you might be able to use it for different PICs. This is 'more'
true for the 28- and 40-pins DIP packages than for the smaller PICs,
which have very different pin configurations. For the simple
blink-an-LED tests, which I did on a breadboard, I needed at least 6
different 'boards' and even than had to vary connections.
As a rule I would say: more complicated function tests than blink-an-led
require a dedicated board per PIC.
> One of the big advantages of tests is to avoid code duplication: the
> test logic remains the same, while the chip configuration always
> change. The drawback is you can't get one single file and compile it.
> Samples can do this, are not so good (even bad), because of code
> duplication.
>
> I can remember Joep was suggesting to have three files: one for the
> test logic itself, one for the target chip configuration, one for the
> board configuration (correct me if I'm wrong). While there might not
> be a lot of different board files (I guess), there can be a lot of
> target conf files. At least, because some people here seem to have a
> *LOT* of PICs, on which they can test a blink samples: this doesn't
> require a board, but a different conf for each target. This blink
> samples are generated by our famous Rob. My question is: could it be
> possible to generate samples ? I mean: you take a test code (just the
> test logic) + a target conf = a ready-to-compile sample.
The script with which I generate the blink-an-led samples was meant in
the first place to check the 'compilability' of all device files, and
was later enhanced for the JSG-check and to build really working
samples. The generation of the samples works like you assummed above.
But as usual the exceptions make it more difficult than at first sight.
For example: some PICs have no PORTA, some PICs have no HS oscillator
possibility. For these kinds of exceptions the script scans the device
file to be able to build a working program.
In the case of one-board-one-PIC these exceptions can be hard coded for
every board, which makes it probably easier to generate a program.
BTW: I needed the many PICs for the development of my Xwisp2 support
program for the Wisp628 (now Wisp648) programmer of Wouter.
> This means we could migrate samples into test logic only code
> (potentially the same as tests), and generate them for a lot of
> different PIC. I don't know what should gone into the configuration
> file, maybe that's not feasible, because it's too variable, I just
> don't know. Rob, how do you do this with your blink samples ? How did
> you define the target configuration ? If we take only the
> configuration part of your blink samples (clock, osc, wdt, ....),
> would it make sense ? If so, could it be possible to generate only
> the config part ?
The dev2jal script has now a dedicated default fuse-setting for every
PIC (in the external devicespecific script). This fuse setting is
currently generated from MPLAB files, but can be (and probably should
be!) partly corrected to ensure that the sample programs work without
any specification in the program (OSC=HS, WDT=off, and probably some more).
This is quite a lot of work (datasheet reading!), but may save nasty
reports and support work/time later. It would also largely simplify
generation of test programs.
> In other words, we have plenty of blink samples, because there are
> generated. Could we have the same for all samples ? (provided they
> support the tested feature, of course). We would only have to write
> the test logic, in the "test" map, then run the magical script to
> generate a lot, a lot of samples ! Wow...
Generating lots of samples may be possible, actually testing them is a
different story!
> (I hope someone here can understand what I mean...)
Uhhhh, how do we know?
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---
