*** my previous post was incomplete, this one isn't (i hope) ***
> 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. >> 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. The file "Berts library for 16F877" includes: include 16f877a_inc_all include pic_general include format include delay_any_mc include adc_hardware include pic_data_eeprom include pic_program_eeprom include pwm_hardware include serial_hardware include random include jascii include extradelay Well... it turns out it are a dozen includes. With the pragma's defines and init-calls, this is the super-include. >> 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 ?... I can see why. I need a good night sleep and start on this shortly ;) I mean: what type of hardware make sense to put into this config file. It should be a fixed-board configuration with peripherals (not the one's in the chip, but lcd, keyboard etc) on designated pins. Wouters dwarf board has lots of possible configurations (5 ports * 5 boards is 25 combinations) and Stefs RPD board even has many more. I like the modularity but Jal can't handle this (you need a preprocessor of some kind for this, but that gets a bit off-topic). >> 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 ? Pragma's (which are the fuses) and also code if required (setting of the appropirate divider for 8mhz, enabling the watchdog. Would make it more easy to use complex functions but maybe it is too ambitieus/complex to implement... > 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 ? Would be nice if we get it to work. As an alternative, we could say: include 16f88 const ez = true include adc -- EZ mode activated, sequence activated, -- extrasolar module will be launched in 3... 2... 1... Not so nice, I agree. But it avoids a sensitive sequence of statements. > Looks like a marketing speech :) I like that ! .. > Let's never forget this: easy yet powerful and flexible ! You're not doing so bad yourself either. > 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" > > Procedures: > > "PWM_Set_DutyCycle(duty_for_channel_1, duty_for_channel_2)" becomes > "pwm1_set_duty_cycle(duty)" and "pwm2_set_duty_cycle(duty)" > This is basicly it. > (who said jallib was more complicated ?) I don't recall someone said jallib itself was more complicated. But it is different, you need to do a few more things (like setting the fuses) and (my guess most importantly) there is no guide that takes you by the hand to blink your first led and 49 more, logically ordered step with a bit of explanation on each step. And if you follow the book for the first time, I can imagine you don't want to add complexity by use a different library set. So do we want to compete with this book? I guess it's better to provide guidance for people who follow (maybe not to close) the book for the second time with jallib in stead of bertlib. But again: this is my assumption. I realy like to hear what Toon and other people who don't dream in jal think of this. >> >> 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" ? My suggestion was to buy one, not to write one. But as for writing one: as you know by now, i'm best at getting code to work (the debugging stuff), I'm comfortable with writing code and my software documentation skills (or is it discipline?) can be improved. But... I almost started on updating the pjal manual and if it was in doc or docx format I probably would have. > 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 ! It sure has been a while! And back in the early days, Eur also participated. Does anyone know he is these days? 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 -~----------~----~----~----~------~----~------~--~---
