Releasing untested device files

[rob...@hotmail.com]

Hi all,

When new PICs are released, I create new device files using the data provided in MPLABX.

Normally I do a test of a device file by running the blink-a-led sample program. For that I order free samples from Microchip.

Microchip seems to change this and now you must have a business (and a VAT number) in order to get samples and it seems that it is no longer free. Since I have no business and did not plan to buy all available PIC microcontroller I plan to release all new device files untested.

In the years that I have taken over the device file creation from Rob Hamerling I did not found any issues lately with device files since Microchip is doing a better job than in the past. 

The advantage of this is that I can release a device file as soon as it is available in MPLABX and you do not need to wait for me to get a sample to test it.

Let me know what you think.

Thanks

Kind regards,

Rob

[evan....@googlemail.com]

The strategy is a good one.  

Microchip have improved the quality of the device descriptions with MPLAB-X.  If the JALLIB process recreates the device file upon each MPLAB-X / DFP release (as Microchip do correct) then you have a robust process.

From a GCBASIC point of view - we will do the same.  

Evan

[Oliver Seitz]

Hi all,

If you would maintain a list of tested devices, all untested ones could have a compiler warning in the device file. That way, users would be warned that issues may arise, and they can be asked to inform Rob if no issues arise (and the device can be added to the "tested" list).

Greets,

Kiste

Am Montag, 26. Juni 2023 um 09:35:51 MESZ hat rob...@hotmail.com <rob...@hotmail.com> Folgendes geschrieben:

--
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/32e0d734-ab4e-455e-b66f-828dc78bd531n%40googlegroups.com.

[Rob CJ]

Hi Oliver,

Nice suggestion.

I could adapt the Python script that creates the device file to add a list of untested device files and add a compiler warning to these device files.

There is one thing I am not sure about. Normally all samples are validated and build when something changes and when that fails (compiler errors) no new bee-package is released.  What I am not sure about if all goes well if some samples will create compiler warnings. The fact is that these device files are tested with the corresponding blink samples so that will then create compiler warnings.

Question for anybody else who knows this. Is it allowed to have samples files that create warnings when being compiled? Does that not break the build?

Thanks.

Kind regards,

Rob

---

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 26 juni 2023 11:05
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Releasing untested device files

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1800797843.2813413.1687770347855%40mail.yahoo.com.

[hans]

Hi Rob,

Possibly a stupid comment on my part, but why must all types be included in the JAL package. I can imagine that companies have very specific wishes, but is this also the case with the JALLERS?

A JAL extract from this would at least be much easier for me and save you a lot of time answering my nagging .

regards

Hans

Op dinsdag 27 juni 2023 om 10:16:55 UTC+2 schreef Rob CJ:

[pinhe...@gmail.com]

Hi all,

One of the goals of jal (I guess), is to have a language that can easily be ported from one µc to another (within the limits of the compiler, here, PIC 8-bits cores).

In the early stages of a project, when I have to decide which PIC I will use, I can list the needed peripherals, number of pins and some other constraints to make a choice, but it is rarely a definitive choice.   Who can predict how much program memory and RAM memory the program will need ?   And what about the two more I/O pins needed that you overlooked and that will make you go from a 14-pin device to a 18 or 20-pin device ?

One of the power of JAL is its library.   For such a library, made available to all users, exhaustivity is always the ultimate goal.

JAL has pretty well fullfilled that mission.

In that exhaustivity, you can separate different aspects (or contents) of the library:

1. The device files

2. the internal peripherals common routines (ADC, MSSP, ...)

3. the emulation of hardware peripherals in software (SPI, I²C, ....)

4. the external peripherals common routines (ex: MAX7219,....)

5. the examples files (blink...)

Let's discuss them in reverse order:

- IMHO, the only part of it that could be overlooked are the "blink" examples.   One example for each big family (10F, 12F, 16F and 18F), and one example for hfintosc and one for extosc is enough.   Their goal is only to learn newcomers to the usage of jal.   Adapting  the blink example from, say, a PIC16F628 to a PIC16F1964 is an exercice that should be left to the user.

- The external peripherals library is, IMHO, something ***VERY*** useful and could (should) be enhanced.   I confess I have several such libraries in my pipeline, but I struggle a bit with the style guide which I find very restrictive.  Anyway, it's not the point here.

My opinion is that the more externals peripherals are available in the library, the more JAL will become an attractive language.

See for example (beware, I will write the ugly word....) the libraries available for Arduino.....   

Why not porting some of them ?

- The emulation of internal harware in software can come very handy when for example you need a second I²C bus when the chosen PIC only has the hardware to handle one.   A lot of time (and sometimes money) can be saved with that kind of libraries.  So, in my opinion, they should be continued to be maintained and enhanced when a new major PIC family is distributed.

- No discussion about the internal peripherals routines: this is mandatory and should also be maintained and enhanced with each new major family

- The device files are, in my understanding, automatically generated based on information retrieved from MPLABX and from Microchip themselves.   Therefore, we can easily trust their content, and unless proven otherwise, there's no need to exhaustively test every one and each of them

OK.  Now, what's the problem faced by Rob ?

Since apparently Microchip does not distribute samples anymore to hobbyist, Rob cannot afford to buy each variant of a new PIC to test them.

That's understandable, and Rob is not to blame.

My proposal for debate is:

WHEN A NEW MODEL OF PIC IS SOLD:

- Don't exhaustively create a blink example for each PIC anymore

- Consider the generated device file as trustfully.

- If that PIC contains changes in the way an internal peripheral works, adapt the corresponding jallib file.   If possible, test it in hardware (can be done also by someone else than Rob).   Otherwise, test it in the simulator.  As suggested, a warning can be issued during compilation to point that the library is not totally tested, but anyway, it should also be mentionned in the comments of it (the user of a library will then be responsible to check if all goes well).    It can be asked to the community of users (how many are we ?) to report any problem with the library, but ALSO to report when all went well.  In that case the library or at least some of the procedures in it can be considered validated.  (As a sidenote, this would probably imply new releases of the lib more often than once a year... another topic to discuss)

- Emulation of hardware in software would probably not be affected by the use in a new PIC, so, don't bother.

- The same goes for the libraries for external devices

I also think that there are not enough people available to help Rob in maintaining and enhancing jallib.

This is also (correct me if I'm wrong) almost a one-man labour of love.....   and we all know, from our own experience, what risks this implies....

I am not as good a programmer nor a hardware designer than most of you (I am an electronics engineer how graduated 30 years ago, but never professionnaly worked in electronics....  I worked in computer science, but at a management level, so I'm completely incompetent ;-)  ), but I'm OK to submit whatever work I do in jal for peer reviewing and inclusion in jallib if it can help the community.

BUT I HOPE MORE WILL JOIN THE EFFORT !!!

One last suggestion (to Rob): As I understood, you know some people at Microchip with whom you have contact to get technical data about the PICS that are not publicely available.  Have you considered to contact them or Microchip Sales Support to explain your problematic, and maybe they could consider to continue to send you the samples you need, freely ?

Since jal is a non-profit initiative, and that by promoting it, it also promotes the use of PIC's, this could help in your argumentation.

Just my 2c, because I really think jal and jallib deserve more visibility than they receive for now, even with the books of Bert Van Dam.

I'm eager to read your reactions,

Have a nice day,

David

[Rob CJ]

Hi David,

Thanks for your elaborate reponse!

I agree with you that all new PICs should be in for the reason you describe. Some time ago it even happened that somebody was asking for a device file of a new PIC which was on GiitHub but not released because I did not have the sample to test it. So sometimes things go faster than I expected.

Yes we should have more libraries for external parts. Normally I create them on request but you always need to have the hardware. Luckily sometimes people send me the chip as long as I create the library 🙂. In many cases I look at Arduino libraries for inspiration (also not how to make one) and sometimes this is a must since IC's from Chinese Manufacturer are often incomplete and/or incorrect and then an existing library helps to get things working. It would be very nice to have more contributors. 

About the style guide. I think it is good that we have it since it makes libraries more consistent. If you look at Arduino libraries they are all very different and some are very bad (and some are very good). If you want I can review/rework your libraries to make them compliant with the style guide.

About my background. I studied electronics and did a lot of embedded software development at Philips (also more than 30 years ago). Nowadays I am - like you - in management (managing a software group that works in the Azure Cloud with C# .NET) but I decided to pick up my embedded software passion when I started with the PIC in 2013 and became part of the Jallib community around 2018 after contacting Rob Hamerling about the device files he had on his website. So although in management, you are not lost nor incompetent 🙂.

About Microchip. I have contacted support several times in the past since normally you could only het samples if you have a business e-mail address and I am using my Hotmail address. So they fixed that for me but now they changed stuff again and I am again in discussion with support to see if they can work without a VAT and I am checking if free samples are still available (since it does not look like that). Reponse of Microchip is not very fast so I have to see what comes out of it. If also contacted sales in the past but they did not respond at all but I will give that a try.

And do not forget the contributions of Matt for maintaining the website and getting the releases out. Note that releasing once a year would be OK since you can aways download the weekly bee-packages (currently not because of an issue but Matt will have a look at it).

So for now my love for JAL remains 😉 but more contributors would be welcome. Like you I have no idea how many JAL users we have. Some time ago Yahoo stopped with the Jallist forum so I created this group on Google since Jallib was already there. If you look at Jallist there are 68 members. On Jallib there are 268 but a lot of them are not active. Any suggestions to promote JAL would be welcome.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens pinhe...@gmail.com <pinhe...@gmail.com>
Verzonden: dinsdag 27 juni 2023 13:56
Aan: jallib <jal...@googlegroups.com>

You received this message because you are subscribed to a topic in the Google Groups "jallib" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallib/XrU5caeqIxc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/38ff9ba4-999a-4826-b124-fbe79ca081b0n%40googlegroups.com.

[pinhe...@gmail.com]

A quick response about the promotion of JAL:

There's a certain RobBest publishing nice projects on Instructable.   He has the same jal icon as you, so I guess he's you :-)

That is certainly one way to go, but Hackaday.io has also a big visibility.

Mentionning also the EEVBlog forum, in the "projects" section.

There are plenty of places where a project can be published: just focus on those with a worldwide and large audience.

I'm also OK to do it, when I have a "clean" and working project that I can share.

In each publication, there should also be a link to get a complete package (JalEdit, compiler, Help files, Jallib....) ready to install (one click to install, everything configured with default paths and settings: people get lazy when it comes to new things....) and in the project folder, some more projects (the ones already there are already great !)

One thing I always wanted but was also too lazy to set up, as a configuraiton file for setting up the syntax coloring and complier command lines for jal in NotePad++.

And maybe also other popular editors you may know of.....

Finally, my apologies to Matt: I certainly didn't want to underestimate his contribution....  Sorry, Matt !

[Rob Hamerling]

Hi David,

On 27-06-2023 18:04, pinhe...@gmail.com wrote:

One thing I always wanted but was also too lazy to set up, as a configuraiton file for setting up the syntax coloring and complier command lines for jal in NotePad++.

And maybe also other popular editors you may know of.....

Although I'm not doing much with JAL these days I made a Jal syntax highlighting file for XED and GEDIT not so long ago. Maybe it can help you to make something alike for NotePad++ (whatever that may be). In that case see:
      https://gitlab.com/robhamerling/jal_language_highlighting_with_gtksourceview

Regards, Rob.

--
Rob Hamerling, Vianen, NL

[Rob CJ]

Hi David,

Why not use the syntax highlighting in Visual Studio Code using the JAL extension made by Sunish? VS Code is free.

Looks very nice (and I find VS Code a very nice editor since you can easily spilt a JAL file and edit in 2 windows at the same time) and it works on Windows, Linux and MAC. A screenshot is given below.

The installation of installing the VS Code plug-in is described in the Jallib Tutorial.

Nowadays I only use VS Code for all my development.

And you are correct. RobBest on Instructables is me since my name is Rob and I live in Best in The Netherlands 🙂. I indeed post these project to promote JAL. 

Currently I am working on my Digital Alarm Clock project. The clock broke down but instead of throwing it away I decided to make the a version using a PIC and JAL. I can then finally make use of some of the libraries that I created earlier 🙂.  The project will be posted on Instructable once I have completed the project. 

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: dinsdag 27 juni 2023 19:59

Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Releasing untested device files

--

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/e13fe273-174d-b1d9-3059-0dbb3f047df3%40gmail.com.

[pinhe...@gmail.com]

Thanks for the tip,

I already tried VS Code but abandonned it because:

- Probably a font problem, but the text in the edit window appears  blurry.  A very strange effect that I cannot capture in a screenshot, but renders the work very difficult.

- No matter how, I didn't find how to configure to get a way to compile the source and get the compiler messages.   I probably have to re-read the tutorial for this....

So, in the meantime, since I am not very patient (and did I already mentionned I was also lazy ? ;-) ),  I remained with JalEdit.

[vasi vasi]

One excellent attribute of the jallib project was the trustworthy device files. And that because they did not trust Microchip... 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/bb2bfa53-3539-42d3-973c-1861c2017f07n%40googlegroups.com.

--

Vasi

[pinhe...@gmail.com]

@vasi

On the other hand, to be fair, device files and the other library files (especially those commanding/emulating internal peripherals) will never be completely and extensively tested.

To do so, they should be tested with every silicon revision made available for each PIC model, which adds another order of magnitude of complexity to the process.

That means that, to a certain extent, Microchip has to be trusted....

[vsurducan]

Rob, why don't you use the FM i2c radio module as clock alarm? :)  It's a cool chip. Perhaps you can program it to wake up on different FM frequencies each morning....

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB16374DFE707BC64A43168C2EE627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

[vsurducan]

Actually, the better choice is a random FM selection each time you need an alarm.

I wrote a while ago one 32bit pseudorandom generator, I think... :)

Even better: a random wake-up hour for your clock!   :) :P

[Rob CJ]

Hi Vasile,

I am using a single chip FM radio chip for my alarm clock that uses IIC as interface.

I even made a JAL library for it (rda5807m.jal) and a video: https://youtu.be/ou3_I3khLIU

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: woensdag 28 juni 2023 20:16

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsuNJUjz%3DzxQj1E_gUm4Gp5gQmboBROqmFvmo-JWTdWhw%40mail.gmail.com.

[vsurducan]

Very nice! One of the chinese kit I have is not able to memorize the last frequency. After powering up it starts always at 107MHz. 

However, having a clock to wake you up with a different broadcasted program on each morning can be considered too. :) 
And a better speaker.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB163701DA3202759A4689BD26E625A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

[vsurducan]

Sorry for this android mess.

The speaker you may consider is thatype from this picture:

https://www.aliexpress.com/item/1005005665700141.html

[Rob CJ]

Hi Evan,

An update about his issue after e-mailing with Microchip and a lot of waiting. I made a mistake in ordering free samples.

I selected a PIC for which there where no free samples available. Normally you get this special icon that you need to click to order free samples. If the icon is not there and you click on the PIC you want then you get a page with paid samples.

So you have to check if the free sample icon is there. I ordered some PICs but unfortunately there where no free samples in the package I wanted so I ordered them in another package.

So it is still possible to test device files before releasing them 🙂.

Kind regards,

Rob

---

Van: 'evan....@googlemail.com' via jallib <jal...@googlegroups.com>
Verzonden: maandag 26 juni 2023 10:27
Aan: jallib <jal...@googlegroups.com>
Onderwerp: [jallib] Re: Releasing untested device files

 

--
You received this message because you are subscribed to a topic in the Google Groups "jallib" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallib/XrU5caeqIxc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/136efd04-8bd0-4759-b5ed-361d785d4f4bn%40googlegroups.com.