Question on blink samples

[rob...@hotmail.com]

Hello,

I have a question on blink samples. Some time ago there was a request for more blink samples using the internal oscillator instead of a crystal. I then uploaded some new blink samples using the internal oscillator for newer chips.

The blink-a-led-py script generates this samples but will initially generate a crystal version since that is what it checks as first item and then it stops. It can also generate the version with the internal oscillator but that is not done when a HS version is created.

If I change the order to first check for the internal oscillator, a lot of new blink samples using the internal oscillator are created. It will then not create the HS version (crystal version).

My questions are:

1) Should we move the priority from HS before internal oscillator to internal oscillator before HS?

2) Do we still want to keep the HS version if an internal oscillator version is available or should we remove them? Currently the script generates one of the two but I could change it to create both.

The reason for asking 2) is that the number of blink samples will increase a lot and there are already a lot of them.

Kind regards,

Rob

[Rob Hamerling]

Hi Rob,

On 13/02/2021 12.29, rob...@hotmail.com wrote:

The blink-a-led-py script generates this samples but will initially generate a crystal version since that is what it checks as first item and then it stops. It can also generate the version with the internal oscillator but that is not done when a HS version is created.

I didn't check the current blink-a-led script, but as far as I remember after initially generating an HS version for a certain PIC, the script checks if this PIC is member of a list of PICs for which ALSO a blink sample with INTOSC and/or a sample for USB must be generated. So all variants would be generated in one run.

If I change the order to first check for the internal oscillator, a lot of new blink samples using the internal oscillator are created. It will then not create the HS version (crystal version).

My questions are:

1) Should we move the priority from HS before internal oscillator to internal oscillator before HS?

2) Do we still want to keep the HS version if an internal oscillator version is available or should we remove them? Currently the script generates one of the two but I could change it to create both.

I would like to suggest to have all possible types of blink-a-led samples for all PICs and improve the directory structure: a subdirectory for HS, INTOSC and USB variants of the blink samples and a separate directory for the other samples (thus 4 sample directories).

Regards, Rob.

--
Rob Hamerling, Vianen, NL

[Rob CJ]

Hi Rob and all,

I made some changes to the blink-a-led script and it needs some fine tuning but with this change the number of blink samples goes from around 1000 to more than 1500. I think if we add this people will no longer see the forest through the trees. I agree with you that we would need some kind of split. I think the blink samples should be separate from the library samples.

I would not split it into HS, INTOSC and USB (there are only around 128 USB samples) but would rather split it in 10, 12, 16, 18 (although there are not many 10 and 12 samples).

In Jallib 1.6.0 there are around 2.000 sample files of which around 1.000 are currently blink sample files.

To summarize I would propose:

-) A library_sample directory (1000 files)

-) A blink_sample directory (1500 files with the modified script)

--) Under the blink_sample the following directories:

---) 10, 12, 16, 18

The motivation is that if you look for a library sample file, you use the name of the library so there should be no spilt under the library sample directory. If you look for a blink sample file you use the PIC type so a split seems logical.

With the modified script, the following number of blink sample files are created:

-) 10 :  6

-) 12:  27

-) 16: 522 (f and lf versions)

-) 18: 933 (f and lf versions)

I know this is easier said than done since it requires at least the following:

-) A restructuring on GitHub (the easiest part)

-) An update of TORELEASE (easy but a lot of work) 

-) Most important a change of the makefiles for the build and release (the unknown part for me) on the server of Kyle & Matt?

I know this discussion has been done in the past but I wonder if we are at a crosspoint to decide if we keep it like this or make a change. I am not sure if there are also other ideas for changes that should then be incorporated.

@All. Share your thoughts and concerns.

Thanks

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: zaterdag 13 februari 2021 13:59
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Question on blink samples

 

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/ca2f7c50-cac1-769b-4553-63f22e79028c%40gmail.com.

[Eur van Andel]

Op 13 Feb 2021, om 13:59:20 heeft Rob Hamerling <robham...@gmail.com> het volgende geschreven:

I would like to suggest to have all possible types of blink-a-led samples for all PICs and improve the directory structure: a subdirectory for HS, INTOSC and USB variants of the blink samples and a separate directory for the other samples (thus 4 sample directories).

I second that. Those blink samples have saved me from insanity more than once and every time I try a new PIC, I start with the blink sample.

Please make blink directory with intosc, hs, etc subdirectories. 

Yes, I agree that there are a lot of samples and I like that a lot. I check the samples every week, most by grep-ping stuff that I look for. Giving the samples their own (sub)directories makes scrolling the samples a lot easier. 

---

ir EE van Andel e...@fiwihex.nl  http://www.fiwihex.nl

Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands

tel+31-653-286573

[Rob CJ]

Hi Eur,

Thanks for your reply. Still I have a question.

If you look for a sample for a specific PIC, why then use the directory structure HS, INTOSC and USB and not the 10, 12, 16 and 18? I assume you look for a specific device number and if you use the number directory structure you find all blink sample types of that specific device in the same directory.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Eur van Andel <e...@fiwihex.nl>
Verzonden: maandag 15 februari 2021 17:47

Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Question on blink samples

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/0702E4D8-F163-48A2-961A-599FB9613E3C%40fiwihex.nl.

[rob...@hotmail.com]

Hi Eur,

I ran my new blink sample program which creates HS, INTOSC and USB samples if possible. It creates around 500 extra blink sample files which are not yet in Jallib.

The count then is:

-) HS: 833 blink samples

-) INTOSC:834 blink samples

-) USB: 124 blink samples

So your suggestion would be:

-) sample_blink_hs

-) sample_blink_intosc

-) sample_blink_usb

-) sample_library

The latter would be for the remaining sample files.

Is that correct?

Kind regards,

Rob

Op maandag 15 februari 2021 om 17:47:34 UTC+1 schreef Eur van Andel: