Hi Seb, I'm not so sure any more we understand each other perfectly...
2008/10/21, Sebastien Lelong <[EMAIL PROTECTED]>: > 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 ? Not if I remain the only one to use this ;) There will be a board file for each test board setup. This means that when I replace the 16f648a with an 16f88, i also need to create a new board file. And when I want to run this 16f88 on it's internal oscillator for some tests, there will be an other one. So, if we use this construct and run tests on a lot of different pics, we have a lot of different board files. > 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). I share your concern. If you create a new library, you need some code to test it. And if you creat this just straight forward, you have a sample: a program that shows how a lib works and works on a specific board and specific PIC (your development setup). With a litte extra work, you can separate the two and have a generic test file. > Code duplication in samples *really* is a matter, > that's why I wonder if there's a way to generate them. Basicly: take a board file, add a test file and you're done. But... there are a lot of definitions of pin's that won't be used in this setup and these distract attention from the sample itself. Secondly, there are a few pin definitions that are used only once and - analog with the pin direction setup of libs - should not be done trough vars. I don't no how hard it is to do this cleanup in a script... > > 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 ? You have to split this in a logical and physical test case/logic. Logical: I need a pin with GPIO functionality, able to drive both high and low, with a led connected to this. Physical: use pin A0 (and connect that led!) > Maybe not for all tests. Ex: for pwm, you > have to select a pin which is pwm'able. Logical: the pin that is pwm'able by ccp1 and has a led connected to it. > > And it defines the oscillator type and > > frequency. > > That's the PIC conf. Maybe, but it for sure is a test condition (which can be changed - does it work with an other crystal, with the pll, with the internal osc?). > > 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. True, but I still have to match the program with the hardware setup (led on pin A3) > And I could modify > "jallib" so it could generate jal statement for PIC osc/clock/type on the > fly. True, but you still have to tell the script to do this for the specific situation you want. > > > 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 ? No. I mean there is more work in adapting the test when there are more IO lines used. This comes to the core of the issue, IMHO. So an example: Say you create a lib which uses an lcd on an 16f88 and also a sample program (that is: setup and test combined) to show how it works. I have a board with an 16f648a and an lcd also, but this probably won't use the same pins for the lcd as your 16f88. So I have to adapt the chip type and maybe some fuses for the other chip. Then I need to adapt the io line defs and statements that set the io lines to output to match my board. So far so good. But then: 1) you create an other test program, which also uses the lcd to display test results. I need to adapt this test program also, in the same way, to work on my board. 2) there is some enhancement in the first test program, so you update it. This means I have to make the changes again. > 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...) ? It works good for me. I have a separate working directory which has only the main file and a makefile. All other files are in the jallib tree, all target files come in the working directory. And the main file also gives me the overview of all relevant files. > > 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 ? Not a problem, just not that convenient. The main issue is that the test programs determine how the hardware setup needs to be. Take i2c_software for example. This could use the first two gpio pins, but then the test i2c eeprom is on other pins when we test i2c_hardware. > > 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). > I think this main issue still stands: I don't believe in a script that generates lcd-based, pwm-based etc test programs for all pics and uses some algorithm to assign the used pins. So you need some way to define: if you use the lcd, de E-pin is on A5 etc. And about the test vs samples; I agree - see above. 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 -~----------~----~----~----~------~----~------~--~---
