> 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. well, 1200 makes more sense then error to me. But I do prefere 115200 as a default. (but to be honest, a default that also works with the 8mhz oscillator of 16f88 would be betrer and for skipping bertlib users, bert his default would be best, so I suggest we use that one).
>> > 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. True, but what is your point? That it is different from bertlibs - of course it is, since copying whole libs is a bad idea (where 'whole' means libs with actual code - opposed to 'pin libs' of the old jal). > > 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 ? would be nice but won't work unless you put all definitions before 'include make_it_ez_for_me' and all other includes after this. This is because the 'defaults' work like 'you have not provided a value so it will be set to default'. So this 'default' should be close to the actual use. Unless.... The optimiser >> >> 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 -~----------~----~----~----~------~----~------~--~---
