[I start a new topic on this]

> > So maybe we could create a compatibility lib for Bert's starterpack?
> >
> > I have my doubts, but it depends on what that means. Have you an idea if
> > this is possible and thought about what would be needed and how to do it?
>
> You're right, this might not be such a good idea. I browsed through
> the starterspack and there is a lot of stuff we just got rid off -
> assembly code, that i2c lib with the nasty interface etc.
> I don't think we should be compatible with that!


There are also those duplicated libraries (3 for pic_data_eeprom, 2 for
random, 4 for pwm_hardware, ...). The pwm API is particularly weird:
pwm_hardware_1 is a nasty copy/paste from pwm_hardware.jal (which handles 2
channels). It has been commented out so the second channel is kind of
ignored (but there're still some computation on it). Still, the API remains
the same: procedure PWM_Set_DutyCycle(byte in duty1,byte in duty2) needs two
arguments, duty2 being ignored... This is quite confusing when you read the
client code.

Anyway... I can't stop thinking this is quite a pity, since we fixed many of
these inconsistencies. Yes we broke some API, and some old code, but know
what ? python2.5 did the same (and many other languages and libraries). I
first thought being starterpack-compatible would be an idea, but I see too
many defaults, to many inconsistencies, etc... Maybe we could do this for
just one PIC, to show it's doable...

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 !


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
-~----------~----~----~----~------~----~------~--~---

Reply via email to