Hi Joep,
> 1. We should have as many as possible 'weak defines'. Like in > serial_common: > if (defined(usart_hw_serial) == false) then > const bit usart_hw_serial = true -- default is async mode (not sync) > end if > Almost nobody uses usart in sync mode and due to the statement above, > you don't have to tell this every time but have the option to use > synch mode if you need it. > More of these defaults could reduce the burden of defining constants > for each lib. 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 ? 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 ?... 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...:)) > 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. 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. > > > About regression tests, you can also use unittests, at least > > for non-18F PICs (OK, I had to say that :)). > Noted for the record and used below... (I just won't free up the time > required to work on this in the near future - sorry). Should I say it could save you time ? :) > > > >> > >> 1. include the super-include and change all function calls from bert > >> to jal format. > >> 2. move the required part of the super-include to you program and > >> remove the super include itself. > > > > ... will people get to this step #2 ? I guess no, they'll stay on step > 1., > > because once it's working, it's kept "as is". So this is not really > > *conversion* procedure, but a new level in our libraries, one step above > > current libs. > 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 ? > > 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"... > > I know some points are still too complicated in > > jallib, like clock configuration (and some fuse settings in general). We > > should work on this too, to improve usability. > Any ideas? No, not yet :) We'll probably have to access fuse values within jal code, as Rob and I wanted when dealing with CCP1MIX setting. This would need a compiler update. > > Except this, I think this is > > not about being too complicated or not, this is, IMHO, a matter of > > documentation, we have to provide more, high quality documentation. > This is universaly true (and espcialy true for jallib). The thing > about 'good' (high quality) documentation that it fits the purpose - > not too extensive and not too brief. And since you mentioned unit > testing again, I will in turn mention the pjal manual of javier, dave > and vasile again ;) Fair enough :) > > Such a manual, covering the language, compiler and all major jallib > modules would be invaluble (and even keep me from peeking in the > source again and again). Provided of course it is complete, correct > and up to date. And to achieve that is an major task... Yes, a major task... 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... 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... Cheers, Seb -- Sébastien Lelong --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
