To deal with multiple board files, your idea of setting a tag seems nice. But it also shouldn't prevent user from generating lots of samples with their board, with as few typing as possible.
Here's what I plan to implement: * deal with a "@jallib preferred-board" tag within board files, as you suggest * when using "-a" option, will preferably use these board files (it won't look for duplicate board files, just select the ones having these tags. this means if there's only one version of a board for a given PIC, and if this board doesn't have this tag, it won't be considered * when using "-b", "-t" and "-o" option, you can force to generate whatever you want. To save some typing, I'll add the following: if "-b" alone is used, it will use this board file whether there's a preferred tag or not, search for tests and generates and potential samples (output files being automatically saved in the correct place) Finally, about the prefix, for now, it produces "sample_<test name>.jal" output files. Eur uses "sample_" prefix, so there might be collisions. I suggest: Eur renames his samples, we use "sample_" prefix as a reserved one. Seb 2008/12/15 Joep Suijs <[email protected]> > > Hi Seb, > > I tried this but does not run on my computer, because it is not so > easy to invoke JAL with my setup. Later this week (or in the next two > weeks of holiday :) I'll try and setup a directory with all required > settings and retry. > > I do like the general idea that all board/test combinations are > generated. There are some issue's to concider though: > 1. there could be multiple board files for one pic-type (if others > start to use board/test files). I think there should only be one of > them used for sample generation. Maybe put a keyword in the board file > to indicate it should be used for sample generation? > > 2. Compile is a good way to filter out samples that won't work for > sure. And we agreed that we can't test everything. But if we discover > that a certain combination won't work, what can we do? Fix it is the > most obvious. But if we can't within a short time? > The best option i see now is to check for known not-working devices in > the lib and throw a compile error. > And to reduce the number of incorrect (compilable but not working > examples) is to check for required bits in stead of registers. ADC on > 16f88 is an example - setup is not properly supported, but since the > register name is the same (but not the bit fields within the chip) it > compiles and most of adc works. Setting the bits would break > compilation (is that what we want in this case?) but would also help > to prevent incorrect samples... > Bbut now I am back at the famous hardware version issue and this is > not directly related to sample generation. > > But the short version of my message: this is a mayor step in the right > direction. In time we should be able to handle multiple board files > for the same chip. > > Joep > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
