Hi,
> Nice to read this. Though we already talked about having such "super
> include" libs (there were named "EZ" libs by that time). Sure we could
> provide this.
I do recall this and could look up this discussion. But maybe it is
better not to and use the insight of today.
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.
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.
3. A remaining issue would be the things that are pic-dependant. That
is where the broad range of jal (twice the library size, 30 times the
chips of the starterpack) makes it more difficult to come op with
sensible defaults that do work for each combination and are logical to
the user.
> 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).
>>
>> 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.
But maybe it is better advice in the manual to describe the various
parts of the 'super-include' that must be inserted into the main jal
file.
> I used to be in favor of providing such "ez" libs (or "super include" libs),
> but now I have doubts.
Why?
> 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?
> 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 ;)
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...
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
-~----------~----~----~----~------~----~------~--~---
