> What do you mean by config file ? Is it the one you're putting defaults in ? No, the hardware file.
> The hardware stuff is one step above, distinct from EZ mode. Layers could > be: > > > 3. libraries tied to hardware > ------------------------- > 2. EZ mode, defaults > ------------------------- > 1. jallib libraries, as we know them by now You keep ignoring my remark that as a consequence, the baudrate setting and include serial need to be split. Why is this? Am I wrong? Don't you concider this important? > But it pollutes our current libraries: they have to deal with an external > constant, related to their proper usage. Only to the degree that we might need to make a ez-lib (default-file) for each other library and there is an include statement in the orginal library. As I said, this is not perfect, but better then the alternative. >> But... I almost started on updating the pjal manual and if it was in >> doc or docx format I probably would have. > > Nice ! Don't you think a format which could be put under SVN would be better > ? I mean ASCII format, like docbook or LaTEX ? What's the current format ? It is currently in lyx format.I downloaded an editor and played around with it for an hour or so with little result, so I put it asside at the time (also since no-one seems to give this a high prioriy). I am willing to take the editor role but do need support - people writing & reviewing parts and perferable a native english speaker to translate it from denglish to english ;) And about the baudrate: I don't see the fundemental difference why you should specify baudrate but can use a default for async (vs sync). But it is okay with me to give defaults for all items execpt for baudrate. I do suspect that there will be new 'baudrate' alike discussions so what would be the criteria. For instance for the chip pragma's. I think most users use an external oscillator at the highest possible frequency, do not use lvp and do not want the watchdog. Could we agree that these become defaults (provided it is doable)? Note: one could argue those need to be in the hardware/board file. This makes it easier when you have pre-defined board (jalduino..). But it make things more complex in other cases (in the way that people might see two different ways of handling - in the program itself or in a board file). Joep 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 -~----------~----~----~----~------~----~------~--~---
