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 ! Le mardi 27 juin 2023 à 15:07:50 UTC+2, Rob CJ a écrit : > 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]. > 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/6bb4435d-491b-4df6-bb75-c4a6b630ac70n%40googlegroups.com.
