About 18f2450_blink_II.jal (vs. other blink samples)
Sebastien Lelong
I've seen you put a lot new samples for 18f, and buildbot complains about "18f2450_blink_II.jal" (for instance) not being lowercased.
There are other *_blink_II.jal test files available, but they never go to "sample" map (maybe they should be removed from SVN). The reason is blink samples aren't generated from board + test files, but are generated from Rob's script. It's preferable to keep this script as the unique source for blink samples, and not even release these *_blink_II.jal samples (we may really need to remove them).
Now do you think existing samples, for example 18f2450_blink.jal, are enough, or do they have to be enriched with some fo your code ? (particularly some pragmas ?)
Cheers,
Seb
Rob Hamerling
Hi Seb, Albert,
Sebastien Lelong wrote:
> There are other *_blink_II.jal test files available, but they never go to
> "sample" map (maybe they should be removed from SVN). The reason is blink
> samples aren't generated from board + test files, but are generated from
> Rob's script. It's preferable to keep this script as the unique source for
> blink samples, and not even release these *_blink_II.jal samples (we may
> really need to remove them).
>
> Now do you think existing samples, for example 18f2450_blink.jal, are
> enough, or do they have to be enriched with some fo your code ?
> (particularly some pragmas ?)
It might be useful to have samples which use a different oscillator type
or frequency than the 'standard' 20MHz HS. Except for some baseline PICs
all my samples use a HS oscillator (all my test boards have a 20 MHz
resonator).
While we are at this subject: Albert, please be somewhat more careful:
the comments in the header of your samples do not always match the
contents of the program (for example: wrong PIC name, your name missing
after 'Adapted_by', date of generation).
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
a.f...@chello.nl
I removed the blink_ii samples and fixed the other validation errors
> contents of the program (for example: wrong PIC name, your name missing
> after 'Adapted_by', date of generation).
by, don't see much added value to add the author's name to the adapted
by line
Albert
Rob Hamerling
Hi Albert,
a.f...@chello.nl wrote:
> Rob can you explain what's the guideline when to fill in the adapted
> by, don't see much added value to add the author's name to the adapted
> by line
For this kind of questions the Jallib Style Guide (wiki) should give the
answer. But in this case it is not too explicit.
I see 'adapted-by' as help to find someone to fix a problem if you
cannot fix it yourself, and to give credit to those who helped to
develop a library.
a.f...@chello.nl
One of the issues is that the header of the board files are not copied
into the generated sample files. So if I change the board file, (re)
generate the samples
from the test file, I don't see any of the author/adapted by fields in
the header of the generated sample file. Modifying this by hand does
not seems
a proper solution, changing the original test file does not sounds
like a good solution either.
I can see two possible soltutions
1) Include the entire content of the board file into the generated
sample file
2) Keep the board files and generated sample file separated, the only
part in the sample generation process is to generate the a board file
include statement,
in addition the board files have to be copied into the sample
directory
Albert
Rob Hamerling
Hi Albert,
a.f...@chello.nl wrote:
> Hi Rob,
> One of the issues is that the header of the board files are not copied
> into the generated sample files.
> (ect)...
I haven't worked with the board and test files. Maybe Seb can work out
something.
Sebastien Lelong
I can see two possible soltutions
1) Include the entire content of the board file into the generated
sample file
But you would 2 headers: one from sample, one from board file...
2) Keep the board files and generated sample file separated, the only
part in the sample generation process is to generate the a board file
include statement,
in addition the board files have to be copied into the sample
directory
This would strongly add confusion when reading the sample. It's like "old" jal, you would keep opening files and files trying to find out where this parameter comes from ("provocative" example: 16f628_inc_all.jal => 16f628_inc.jal => 16f628.jal => p16f628.jal => ...). Having the *code* directly in sample is explicit, users just know where things come from, nothing more, nothing less.
The question is: which header is to keep ? The one coming board file, or the one coming from the test file ? Currently, this is the test file one which is kept. IMO this makes more sense (value is more in test file... right ?), but I can change this if you guys want to.
Cheers,
Seb
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org
a.f...@chello.nl
> The question is: which header is to keep ? The one coming board file, or the
> one coming from the test file ? Currently, this is the test file one which
> is kept. IMO this makes more sense (value is more in test file... right ?),
> but I can change this if you guys want to.
that is copied into the generated sample file.
Because a board file header can contain specific information (like a
description of the board,
links to schematics / PCBs etc), this information might be very
helpful for the user of the generated sample file
And there is of course the initial issue where Rob complained about,
when changing a board file, the generated sample
file will be modified, but this history information (author/adapted by
etc) you won't see back in the header of the generated sample file
Albert
Sebastien Lelong
Maybe I could merge *some* of headers' field, like "Notes", "Sources", 'Description", and other multi-line fields (actually those where yo expect to find information about the board) . Single line field like "Author", "Adapted-By" could be concat, but the result will be weird I guess (eg. "Title"), so I would prefer skip these.
Cheers,
Seb
Sunish Issac
Rob Hamerling
Hi Sunish,
Sunish Issac wrote:
> About the samples having different crystal frequency, I would suggest to use
> the internal oscillator for samples whenever possible. Makes life much
> easier.
I don't see why a circuit which uses the internal oscillator is so
*much* easier than using a resonator.
Maybe your suggestion does not apply to the current blink-an-LED
samples. but I would be happy to build a script to generate blink-an-LED
samples with the internal oscillator (some of the current blink samples
already using it)! But then I need a *method* to set the required
oscillator and configuration bits which covers *all* PICs in the
baseline, midrange and 18F series. Because of the variety of parameters
and differences in defaults settings that won't be easy and a lot of
work. If you could provide a method.....
To make my life somewhat easier I chose the 'HS' oscillator for the
current blink samples, which were primarily meant as test-vehicle for
the device files.
Sebastien Lelong
I too prefer internal clock, just because there are less parts... But I also understand and agree finding the method to set this internal clock for *all* PICs will cost a lot ! And if we have all set using internal, someone will complain and will want external... Since there are some using internal, it should be easy to migrate configuration from external to internal clock.
I suggest to let these samples as they are. Samples are, well... just samples. And the more diversified they are, the better it is.
My 0.2
Cheers,
Seb