> > > Maybe we should focus on how we can help (former) bert-lib users to > get going the jallib way. An option woudl be to definie all missing > procedures and have the compiler issue an error on each of them with > info what the jallib equivalent is.
That's an idea. And if we have a lib which defines missing procedures and which do "pragma error", then we can give a try with a migration script... > > > > > I know there are plenty more combination, but those may be the most > commonly > > used. > > > > What about setting a usart ? Well, this is where I think defaults > shouldn't > > be defaults ! > > I don't know what you mean with this last remark. I mean I'm ok to create some files with different clock speed (because it's mostly related to the board), but specifying a baudrate is something too specific (because it's related to the application). > I don't like the idea of more libs. This means more files, more > cominations that can go wrong, more maintenance. > Besides that, I think that we should focus on make it as simple as > possible, not simpler (Einstein ;) > What I mean: we provide powerfull libs which suite almost every > situation and I think it is not a good idea to provide downgraded > versions since they create a threshold in the growing path of the > users. I wouldn't say a "downgraded" version. I just observe myself copying/pasting the same code there and there (pragma WDT disabled, ...). Not a big deal, but we may propose some solutions. > We could however do some things to make the current lib more easy to > use without limiting the options or create different libs for similar > functions. > First we could build some obvious defaults into the libs itself. Iirc > I mentioned the SPI option for the serial_hw lib. If not defined, we > could set it ourselfs to async. (if it is of use at all in this > specific situation). Careful with defaults in library. I like having flexible libs, and that's why I'd put this "defaults" elsewhere, in another layer. (well, you know what I'm thinking about this :)) > Second, we could define a constant that enables 'common defaults', > These common defaults would be the LVP off (if we are sure this would > not lock users with an lvp-only programmer out of there own pics), WDT > off etc, But all libraries should check this constant. We could however provide a common_defaults.jal library, which does set these defaults. Other libraries don't even have to know it exists. -- common_defaults.jal pragma WDT disabled pragma LVP disabled enable_digital_io() -- mytest.jal include 16f88 include common_defaults pragma CLOCK 8_000_000 -- etc... Yes, I can still get my hand dirty and enable WDT, disable LVP (the current way). > BTW: the oscillator frequency of the internal oscillator of the 16f88 > is an other cup of (I)Tee, "(I)Tee" ? Mmmmh, I can feel a joke, but can't see which... > since there is also a register. I think it > would be a good idea if the device file would contain code that sets > the presscaler if the internal oscillator is enabled. The value can be > determined by the oscillator frequency. But is this possible in device files ? How would you do that ? INTOSC_NOCLKOUT is in a "pragma fuse_def" block. Grand Master Rob ? Cheers, 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 -~----------~----~----~----~------~----~------~--~---
