Hi Seb, 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?
2008/10/20, Sebastien LELONG <[EMAIL PROTECTED]>: > 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. 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 am not sure why you expect the number of tests to be significantly larger then the number of (non-device) libs, so please explain. > 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. 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. And it defines the oscillator type and frequency. 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. And the led is simple and easy to understand, compared to the 6-lines lcd interface... > 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). 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). > 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. See above: a 'board' file defines both the board and chip. So I have two board files for a 18-pin board - one for an 16f88 on it and one for a 16f648a on it. >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). An other way is to define the setup for each type of chip-housing (e.g. a 40-pin chip has lcd on bus C). Or... you can use a config file which describes the hardware. This is close to the current boardfile setup. > If so, could it be possible to generate only the config part ? > > (I hope someone here can understand what I mean...) I understand, since I've been there ;). 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. Joep --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
