The more I read this, the more I think it's not possible to generate conf file for target chips which could be used in many samples...
Ex: pwm lib, one channel. How to generate a conf file which would specify pin_c2 for 16f877, and pin_b0 for 16f88 ? Seb Le Monday 20 October 2008 21:05:47 Sebastien LELONG, vous avez écrit : > Hi there, > > While I was working on the testing matrix, I've played with tests, and this > gave some thoughts, even worries... Here there are, not very structure, I'm > sorry, they come as they are :) > > 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. > > 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. > > 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 ? > > 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... > > > (I hope someone here can understand what I mean...) > > > Seb -- Sébastien LELONG http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
