> > 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.
So, do you mean baudrate could be set as a default or not ? I strongly disagree to put it as default, it doesn't make sens IMO. > > > 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). Yes, that's on the program code, *not* in the libraries. > > > 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. Instead of having a punish_me_please_I_am_ready constant (...), we could put all those defaults in a single file, smart enough to select defaults that make sens according to the target chip (no ADC defaults if PIC doesn't have ADC module). This gives: include 16f88 include make_it_ez_for_me -- now I set fuse that aren't handle by "ez" lib pragma target blabla Is that what you suggest ? > > 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. Can you give an example ? I'm not sure to understand. > 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)? ??? Sorry, I'm lost :) Can you give some examples here as well ?... > 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?? You'll get plenty of config... Is 8Mhz_internal is procedure that define pragmas and fuses ? > > 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... Including this single file/lib on each lib that would use defaults defined in it, that's what I mean by poluting our current libs. Let's make it explicit, remember this is jallib, and being explicit is something we always wanted from the beginning. No secret, no mystery. Do you wanna switch to "EZ" mode, make it so: include 16f88 include ez include adc -- EZ mode activated, sequence activated, -- extrasolar module will be launched in 3... 2... 1... is clear and explicit. You know where defaults are, by reading the include statements. If you put "include ez" directly within adc lib for instance, you can't where it's come from. include 16f88 include adc -- are we in "EZ" mode ? > > Should I say it could save you time ? :) > This is absolutely correct: it will take take at first and *could* > save time later ;) sed "s/could/surely will/g" > >> 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. Looks like a marketing speech :) I like that ! > > Just like libraries that are easier to use (but are not crippled in > there power). Let's never forget this: easy yet powerful and flexible ! > > 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 ;) Well I have my idea on this too... But let's wait Toon's answer. > > 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). Something like: Includes: "include pwm_hardware_1.jal" becomes "include pwm_hardware" "include pwm_hardware_18f.jal" becomes "include pwm_hardware" "pwm_hardware_1_18f.jal" becomes "include pwm_hardware" (who said jallib was more complicated ?) Procedures: "PWM_Set_DutyCycle(duty_for_channel_1, duty_for_channel_2)" becomes "pwm1_set_duty_cycle(duty)" and "pwm2_set_duty_cycle(duty)" > 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. Are you suggesting you want to write a book ? "jalv2 and jallib in a nutshell" ? "The definitive jalv2/jallib guide" ? Seb PS: woaah... it's been a long time since we haven't debate like this, this reminds me the early days of jallib, my friend ! -- 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 -~----------~----~----~----~------~----~------~--~---
