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 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/38ff9ba4-999a-4826-b124-fbe79ca081b0n%40googlegroups.com.
