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: [email protected] <[email protected]> namens [email protected] <[email protected]> Verzonden: dinsdag 27 juni 2023 13:56 Aan: jallib <[email protected]> Onderwerp: Re: [jallib] Releasing untested device files 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 Le mardi 27 juin 2023 à 11:45:40 UTC+2, hans a écrit : 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: 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 <[email protected]> Verzonden: maandag 26 juni 2023 11:05 Aan: [email protected] <[email protected]> Onderwerp: Re: [jallib] Releasing untested device files 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 [email protected] <[email protected]> Folgendes geschrieben: 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/32e0d734-ab4e-455e-b66f-828dc78bd531n%40googlegroups.com<https://groups.google.com/d/msgid/jallib/32e0d734-ab4e-455e-b66f-828dc78bd531n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1800797843.2813413.1687770347855%40mail.yahoo.com<https://groups.google.com/d/msgid/jallib/1800797843.2813413.1687770347855%40mail.yahoo.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/38ff9ba4-999a-4826-b124-fbe79ca081b0n%40googlegroups.com<https://groups.google.com/d/msgid/jallib/38ff9ba4-999a-4826-b124-fbe79ca081b0n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB163727EF7D7FA6449D22BBA3E627A%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.
