Hi Joep,
Just was about to ask how to use the test section in the yaml file
> when I read this. Can you give me an example on this?
Don't invest too much time on "jallib" script, it's not ready. I worked
quite a lot on it, trying to provide an easy way to access the repos. Most
of work is for handling tests ("test" + "sample") so testers could have a
easy-to-use tool to perform tests, and report results. For now, I still have
to get information about svn revision. And deal with "test" map...
... tests are not handled by jallib. There are deactivated, because I don't
know yet how to deal with them.
Samples are easy: you look at "by_device", you have all PICs, then inside,
all available samples. jallib can then generate a new matrix, or update an
existing one, by exploring "sample" dir (jallib -u + all other options)
Tests are more complicated.
* I could look at "test" dir and search for "test_*" files, and register
them for all PIC. The problem is not all PIC can handled all tests (eg, as
you said before, testing 2 PWM channels on a PIC 16F88). So ? One
requirement for me: if a test or a sample is registered in the yaml file for
a given PIC, then it's relevant for this PIC. That way, every piece of
information in the testing matrix is valid/relevant.
* I could search for "board_*" files, and try to compile board + test. If
it compiles, I register test for the PIC defined in the board_ file. If not,
I skip the test. Will compilation always fail when it has to fail ?
* finally, we could manually register tests for each PIC which can handle
them.
Do you see any other options ?
> What you basicly want is a test matrix for each library x each pic
> (and maybe some variations in xtal freq, osc type etc). In practice,
> there will be some libraries (like serial_hardware and print) that are
> used in lots of tests.
I was basicly imagining a test files X PICs matrix, not a library X PICs
matrix. The latter seems to make more sense. I need to modify the HTML
generation, so it opens samples and tests files and look for "include"
statements.
> I am not sure why you expect the number of
> tests to be significantly larger then the number of (non-device) libs,
> so please explain.
Because you could write more tests than libraries ! But my worry isn't about
this, it's more about the number of row, that is, the number of PIC which
are handled in tests. For now, we have two board files: board_16f648a_js.jal
and board_16f877a_dwarf.jal. Will we have a lot more ? What I mean is we
have a lot of blink-a-led samples which are validated (which works), so lots
of rows (which is good). And, in the mean time, very few of this PICs have
tests. So, does a matrix with only few squares checked have a sens ?
I have also worries about samples which look like tests (yes, I can remember
the discussion, I'm not saying tests are bad, on the contrary). I'd prefer
samples being based on tests, or at least of their principle (test logic
separated from pic conf). Code duplication in samples *really* is a matter,
that's why I wonder if there's a way to generate them.
> The issue to resolve is not code duplication itself. It's about test
> hardware setup. The blink examples are simple, but dictate the pin
> where the led should be on.
That's the test logic, right ? Maybe not for all tests. Ex: for pwm, you
have to select a pin which is pwm'able.
> And it defines the oscillator type and
> frequency.
That's the PIC conf.
> If I want to test on a board with the led on an other pin
> or use the internal oscillator, I have to manually adapt this (each
> time the blink files are generated) before I can test this.
Yes, but at least you have a ready to compile sample. And I could modify
"jallib" so it could generate jal statement for PIC osc/clock/type on the
fly.
And the led is simple and easy to understand, compared to the 6-lines
> lcd interface...
I'd say it's only related to the test logic itself. Whether it's complicated
or not is not the problem, or do I miss something ? Do you mean the more the
test is complicated, the more its configuration will be complicated too ?
> I might have suggested this, but not any more ;)
> My current setup is that I use a main file which has only 2 statements
> in it: the include of a board file and the include of a test file. (to
> be more precise: all my board and test files are in this main file,
> only one of each beeing uncommented).
BTW, why don't you use "jalv2 -i board_file test_file" cmd line ? Do you
feel using a main jal file is easier to handle (with comment/uncomment,
etc...) ?
> >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.
>
> You can. But to do this, you need to define for example on which pins
> the lcd is connected. This can be done by assigning from pin a0 up. If
> so, you need adapt the hardware to the test and change the hardware
> when you change the test (pin A0 will be used by all tests). (and it
> will be a bit more complicated while not all pins can be used for all
> functions).
Is this a problem ? I'm not sure to understand what you mean. Yes, you'll to
define which pins to use, but isn't that the case now ? pin_A0 will be used
in many tests, but not at the same time, so is it a problem, too ?
> (I hope someone here can understand what I mean...)
>
> I understand, since I've been there ;).
Cool !
> The main issue is that you
> either dictate the configuration (if you even can define such a config
> for all pics) or need an configuration file, so the user can adapt
> this to it's own config before generating the testfiles itself. In
> that case, there is no added value to the board/test setup. Actually,
> the board/test combination is even easier to use, since it is just
> jal.
I have to final thoughts about that, no final target in mind. I just wonder
if it's possible to unfiy tests and samples, because I have worries about
deviation (either people write samples, either tests). On the long term, I
guess one or the other will be preferred, so I'm thinking about a way to
have one single way to this (that is, writing one piece of code, which be
used for both samples and tests, so effort are not wasted).
Cheers,
Seb
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
