2009/1/3, Sebastien Lelong <[email protected]>:
> I first thought being starterpack-compatible would be an idea, but I see too
> many defaults, to many inconsistencies, etc...
Me too.
> Maybe we could do this for just one PIC, to show it's doable...
I played with C# for the last few days and am impressed by the help it
provides me to get me going. One specific situation was where I used
#define to get a range of constants. This gave an error and the
helpmessage (F1) told me that, just in case I used to program C,
ranges of constants should be defined in a different way.
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.
> But back to our sheep (french expression). Do you agree to build an "ez"
> layer with "ez" libs ? I think most of the work will remain in discussion :)
> I do think having "ez" device files could help. For example, just:
>
> {{{
> include 16f88_ez
> }}}
>
> would do what we usually do in samples: disable watchdog, disable lvp, set
> digital io pins, set some more specific registers (ccp1mux for isntance)
> and... set the clock configuration.
>
> And now we have a problem. Which to take ? 20Mhz ? 4MHz ? internal 8MHz ?
> Maybe we could follow tiny bootloader naming convention (I let you guess
> what's behind):
>
> - 16f88_20MHz_ez.jal
> - 16f88_4Mhz_ez.jal
> - 16f88_16Mhz_ez.jal
> - 16f88_i8Mhz_ez.jal
>
> 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 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.
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).
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 as oscillator frequency and baudrate is concerned, I think
defining this is part of the job. And it is no rocket science - if
users can write a working program, they can tell what the oscillator
frequency is.
BTW: the oscillator frequency of the internal oscillator of the 16f88
is an other cup of (I)Tee, 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.
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
-~----------~----~----~----~------~----~------~--~---
