Hi Guys, > I agree. The discussion will be which parameter can be "weak". But I'm sure > we'll agree on a compromise. > For instance, I'm sure nobody wants to consider the baudrate as a "weak" > parameter, right ? > This means users *have* to define this constant, no > default here. The problem is Bert's libs defines such a constant. How will > you deal with this ? Will you put a default baudrate in these "ez" > libraries, to make them compatible with starterpack ? No weak constant (or should we say 'default') means: you should define this or you will be punished by an error while compiling. So the only case I can imagine that a parameter can't have a default is that there is no meaningfull default. And this does not apply for baudrate.
> I can also remember > that in the book, it's said that a given library must copied into the > program's directory, so a specific parameter can be changed (I'll try to > find the page). How will you deal with that too ?... By using definitions, in a file (old-jal style pin file, like i2c and lcd had) or in the source (like we do it in the samples). Just for the record: I don't think compiling 'bertlib' project with jallib without a change is feasable (without *major* effort). But I do think that we can reduce the effort required to make the switch. > Like our board files, Bert's libs are for a specific hardware setup (though > baudrate, for instance, isn't related to hardware, and definitively > shouldn't go into a lib) . If we go with "EZ" libs (or "super include" > libs), we'll provide a set of libraries dedicated to a specific hardware > setup. A well defined hardware setup is also an important point for the > beginners when dealing with PICs for the first time. Maybe even more than > the libs themselves. Like we've centralized, shared and build a set of > libraries for jalv2, to have a common tool to work this, maybe we should > also have a shared, centralized, common hardware setup. Like jaluino for > instance :) (ok, forgive me, but I also had to say this too...:)) I think I forgot to mention this, but IMO we should not have more (easy) libs or super includes. What I suggest is to put in all defaults that could make sense. And we could add a define like 'make_it_hard_for_me_so_no_defaults' that disables the defaults for those who want to be punished by the compiler ;). A major discussion will be what the default fuses would be. But once we have those, the burden of configuration for the user will be largly reduced. What i noticed that bert's 'super-include' only includes half a dozen libraries and all other are optional. So maybe we could provide a list of the (jallib alternative of this) libs. And in addition to this, some hardware configuration files look like an opportunity. What could they be used for? lcd connection? keyboard? A led (which does not have a correspondig library but it would make a blinking led portable)? And maybe some 'logical configuration sets' like 8MHz_internal', '20MHz_xtal' 'enable_watchdog' which set the fuses (and maybe some code, like for the 8 MHz 16f88 internal osc) required for the selected pic?? >> >> 2. I am not in favor of multiple libs for the same function, not even >> when it is only a different entry point. But we could extend beyond >> obvious defaults like above with a EZ-constant definition that would, >> say, disable the watchdog, disable lvp, set all pins to digital mode >> etc. Oh, I did mention this ;) > Just some thoughts: I would prefer not having such a constant polluting our > current libs. I mean I'd prefer having the code dealing with this constant > in distinct libraries, other files. Else we'll have plenty of "if > defined(EZ) == true then... end if" statements, in libraries that don't even > have to know such a constant exist. Having this in a separate lib also > centralized the way "EZ" is defined. One separate file seem ideal. But it might introduce a sequence issue. The file is included directly by the user (include defaults) or within each lib that uses a default (which effectivly includes it with the first lib). In both cases you have to define *all* values (even regardless if they are default or not) before this include or you will get a compile error. So the 'good practice' of keeping defines just before the corresponding include isn't possible any more. Have to give this some thought... > Should I say it could save you time ? :) This is absolutely correct: it will take take at first and *could* save time later ;) >> This is not true. Even if people don't take step two, they still have >> adapted to the jallib API, use the datasheet naming conventions etc. >> And from there, they will write jallib-compatible code. > > So what's the purpose ? Helping people getting from starterpack to jallib ? > Or providing libraries that are easier to use than current ones ? Both! Helping people from starterpack to jallib will give these people more functionality, give more users, larger community, more feedback, more support, better libs. Just like libraries that are easier to use (but are not crippled in there power). >> > I used to be in favor of providing such "ez" libs (or "super include" >> > libs), >> > but now I have doubts. >> Why? > > Because current libs aren't that difficult to use, except some points which > I was talking after: for instance, setting up a 8MHz internal clock, with > IRCF bits isn't that user-friendly. Setting up a 48MHz clock with a 20MHz > for 18F, with PLL setup, is far from user-friendly, and looks more like a > "Harry Potter's curse"... Maybe the 'logical configuration sets' mentioned above could help... > Now I would ask this... Users have great experiences with Bert's book, which > I clearly understand and approve. A great help to help getting started with > PICs and jalv2. Now, is it mostly because of the documentation (ie. content > of the book itself), or the libraries ? The answer should tell us where we > should focus our energy... Good question. Maybe Toon can answer this. This is his field of expertise, until we pollute him with knowledge ;) > I think we should make some specific points easier to deal with (like clock > setting, maybe having enable_digital_io() called by default, ...). And > produce more documentation, learning by examples and experiments. But if the > real problem is about converting examples from the book into jallib > compliant code, the easier way, that would really makes sens, is what Toon > suggested: rewrite all examples with jallib. IP restrictions, I know... Maybe there is a way inbetween. I don't know the book, but it probably starts with a simple program / a few procedures and extends on that. What we should provide is a 'translation manual' for the procedures used. That does not need us to publish the orignal examples (which btw are on the web to download if I am correct). The good thing about the pjal manual was that at the time it was a pretty complete reference manual for the compiler and it's libs (like 'programming perl'). I'd love to have such a manual on my shelf, preferable as a real book. 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 -~----------~----~----~----~------~----~------~--~---
