On 31 Aug 2008, at 17:06 , Joep Suijs wrote: > But before the final validation, there is long process of creating and > improving files. If we assume that most of the changes are > improvements, I think it makes sense to move files linke blink - tests > for a specific chip - to /validated. It means 'it works, or at least, > it has worked'. OK.
> We could argue if the device file should be migrated too. I would not > do this since there is still work to do on those (i think, seeing they > are still updated regularly) and most of the features aren't tested > yet. > > This brings me to an other point: are we capable of supporting a > specific peripheral (like serial_hardware) on all pic's before we > concider it validated? No. That will take forever. > I think this is a huge amount of work, and > with bugs for 18F chips* > > An option would be: > - blink goes to validated if it works OK. > - generic libs (external and jal) go to validated if they work on at > least 2 different chips. Well, if we do not move the device files, we can't release anything. > - periperal libs go to validated if they work on at least 2 different > chips. But if a periperal lib supports different versions of the > periperal, it should be tested on at least one version of each. Nice, but what are "different chips"? Do the 16F819 and 16F818 (smaller memory) count as different? Or do they need to be on different datasheets? > - device libs move to validated if they work with the relevant generic > and periperal libs. (Relevant means the lib should support the chip. > If serial_hardware has no 18F support, 18F device files can be moved > to validated). > > Joep > > > * I think Kyle is right when states 18F support is hardly used. It has > been on the whish list for a long time, but when it was implemented, > nobody put in enough effort to get it up and running. I fully intend to do just that! The only reason I switched to JALV2 is the 18F support. I had some code running, including ISRs on 18F chips, but I had to hack the ASM file by hand to improve ISR context saving. That was the moment I thought I had reached the end of the JAL v4.60 compiler. Since my knowledge of JALV2 was nil, it was a good moment to help with the jallib, since I needed to create all those samples myself. For the last weeks I look at 10 datasheets each day and I have 30 of them open all the time. I'm learning more about PICs than ever before. > This is > including myself: I gave it a try but ran into a few bug and did not > have the time (priority) to work on it. So there will be bugs left, > limiting the use. Okay, there where a few messages on the subject on > the jallist, but to put this into perspective: the orginal JAL > compiler took over 1500 messages by a dozen people and 6 months for > beta-testing. 18F support will be less, but still substantial. If this > effort is not invested, 18F support will be hardly used... For my work, I need to port to a PIC18F4620 a large program with a 200 asm lines 10 kHz ISR, which I have running on a PIC16F877. So I'm quite committed. --- ir EE van Andel [EMAIL PROTECTED] http://www.fiwihex.nl Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands tel+31-546-491106 fax+31-546-491107 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
