2008/10/27, Sebastien Lelong <[EMAIL PROTECTED]>: > > Hi Joep, > > > > That could do the job! We could name a group of pin definitions, like > > led, hd44780 etc. And within the test file, we mention the defintions > > used. > > I was thinking the other way: let the test file cleaned from any tags, > etc..., and put them in the board file, to let the code as clean as > possible. I guess this is the same, since if we (I) parse these files, we > (I) can remove obscure tags. In that case, you have to parse the test file and if you can do that, we don't need tags at all. An example: in the boardfile, the pins to which the lcd is connceted, are defined. There are multiple test files that use lcd. So, the test file needs to tags to indicate it needs the lcd setup.
> > I don't think we have to indicate the end of the definition . Just a > > statement that a definition starts is okay like: > > -- definition LED > > The end of tag is just here to show the end of block. Else, the end of block > is detected as soon as there's an empty line (like api doc when parsing > comments above functions). I suggest the end of the block is defined by the next definition. And we can end all definitions with an unused tag. >This may be quite annoying when writing jal code > not to have line break. The coder has to be "free" to organize the code the > layout he wants. I agree, and don't want empty lines to become significant. > Also, for the same reason, we should use a special char, something like > @led, @ldc, etc... like javadoc or the like. My pseudo xml tags were just > examples, I'm not in favor of using them. Okay, pick your choice! > > When you (someone ;) parses the test file first, it knows the groups > > which are relevant. All others (excecpt for the one without a name, at > > the start) can be removed. > > Except the first, which can even be generated on the fly, with appropriate > clock speed, xtal type, etc... I was wondering if we could also generate > board files :) I missing the point here. The first is the one without the name in my idea. What can be generated on the fly? And sure, we can generate board files. But the key issue is that board files contain implementation-specific info that has to be defined somewhere. The main limitation of board files is that contains a info on a specific pic with a specific config (mostly (all?) fuses, say, internal oscillator) on a specific board. All those three can vary independed from each other within limits. One of the limits is for instance the RB0/3 pin selection for 16F88. You can change it if both pins are not used for other tasks and there is a led connected to both of them. For now, board files define a led pin, a pwm pin (also with led), the standard lcd and i2c pin's (with i2c eeprom connected). I can't think of any more 'generic' external devices for testing. Only specific sensors, a specific keyboard etc. But maybe some else can and tells me? 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 -~----------~----~----~----~------~----~------~--~---
