Mike, I'm sure your the best a documentation since you have experience with it. However, I feel that you have great skill with other things (such as getting more processor types implemented). Maybe your skills could be used better elsewhere for now?
This multitasking thing sounds interesting, do you have any samples? Matt. On Apr 2, 12:29 am, "m...@watty" <[email protected]> wrote: > On Apr 2, 3:12 am, mattschinkel <[email protected]> wrote: > > > Kyle's documentation is strictly about the language, we have that > > already. > > > Matt. > > Kyle's document is rather sparse and has some information lacking. It > certainly needs simple *and* more complex examples. What I was > thinking of would have 3 reference sections (core language, chipdefs/ > Pragmas and compiler directives), with NO examples. > > The "main" part would take each part in complexity with simple > examples > Part 1 > 1) Declaring scaler constants & variables > 2) Expressions > 3) Built in functions > 4) Tests > 5) Declaring vector constants and variables (arrays) > 7) Loops > 8) Blocks, Procedures, Functions and Interrupts > 9) Pseudo vars with non-trivial examples > 10) Using information declared in chip include and other Pragmas > 11) Using assembler and why mostly you should not. > > Part 2 > Complete programs (with and without libraries) > > Part 3 > Issues of performance etc of 16F vs 18F and why for 18pins + the > default choice today for new projects is 18F > > Part 4 > Various examples of multitasking without "start" or "suspend". Why an > actual language extension for multitasking on PIC is a bad idea. > Complete programs with multiple ISRs demonstrating Multitasking. > > Part 5 > appendix 1 Kyle's language ref expanded > appendix 2 Kyle's pragma ref expanded > appendix 3 chip include and chip def documented > appendix 4 Compiler options. > appendix 6 Recommended PIC from 8 pin DIP to 40pin DIP and 18pin SO > to 64pin TQFP. Compare 18F and 16F. Why other Microchip parts may not > be "PIC" in the sense that 10/12/16 and 18 families are. > appendix 7 Programmers, Tools develop boards, Sources etc. > > I think the jallib itself is likely to be be too changeable to have > an reference section.Put Links to here. > I think the style should not be that of jallib as it's not (IMO) the > optimal in readability and is not the language. The majority of > existing programmers will easily follow jallib style to use libraries. > Few people will produce libraries. The majority of people will be used > to a more flexible coding style. > > Anyway, above is book I am going to write. Based on writing such for C+ > + and reading such books for Ada, Prolog, VB, Modula-2, Occam, C, C++, > Pascal, Forth. A simple reference isn't very useful. I found with > existing documentation recently having to write a lot of snippits and > see if (a) Compile, (b) Work as expected and yet I'm a little > experienced with programming. > > Unlike C, pascal, Ada or Basic I think the PIC has to come more into > the text. > > There are a confusing selection of PIC, many for historical reasons, > which should not be used in new designs. I think thus last appendix is > important -- 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.
