> It is possible to do a project in a single project-unique > file, but much of the power of the development environment > and modularization is lost if you do that. I tend to use > single files only for my 10F and a few 12F projects. Makes sense. Again, if the modules are standardized, the files can be made present for ALL projects and just not included from the main file unless they are used. e.g. an include file with stuff for LCD interfacing could be always present. Those standard modules could be developed as separate, single file projects and then moved into a "library" of modules when approved by you. It's a way to build the ability of the system without increasing the complexity or moving it off the central, host independent, server. > I suppose it would be possible to create a template where you > set a few configuration constants at the top, it takes care > of a bunch of mechanics largely using canned include files, > then has a banner labeled INSERT YOUR CODE HERE. That might > actually be instructive to get into PICs easily but starting > with the right discipline. Exactly so. > There would still need to be a > way to communicate the target PIC type outside the file so > that the build procedure can select the proper linker file. No problem. A pull down with all the know PIC types could easily be added to the web page above the text area where the source is pasted in. > There will have to be a custom wrapper program that parses > the PIC type from the source file, runs all the tools in the > right sequence, reports and aborts on errors, and hands back > your .COD and .HEX files on success. Or take the PIC type from the web page and prepend the necessary stuff to the source file for that type. > So I guess it's possible to do within some restrictions and > it wouldn't be hard to create the single build tool, but > would anyone actually use it? And that is the big question. The advantages are: - No install, easy to use, just select a processor, paste in the code and go. People who are curious about it could try without a large investment. - Commonly encountered problems are reported automatically (error reports) and the install is not a potential source of error. - All the compiled code could be (this is my reason for being interested) logged and shared with others. Each project is stored on the members home page for others to see and use. When a member makes a project and gets the code working, has Olimex make a PCB for it ( remember the free PCB contest? It's still running! ) and DIGG or whoever picks up on it, all the resources are in one place in a consistent format. - Successful compiles could be automatically posted to the PICList under a new [CODE] tag for review my the list members who choose to subscribe to that topic. We could even post failed compiles under [HELP] and play "catch the error". These topics would probably be off by default for new PICList subscribers. - Host independent. Linux, MAC, old PC, Library PC, Cell phone... Whatever... As long as it can access the internet, you can compile code. Getting the result into a pic is then another issue. - Access to the system can be controlled. Advanced modules, services, or assistance could become a paid option. Pay encourages development. On the other hand, this is not really what the PICList has been about. Please don't assume I'm advocating this. Disadvantages are: - The server may crash. - The work required to set it. - If no one uses it, it's a waste. - Microchip may lay an egg. Anyway... Since it is just Olin and I talking about it so far, I don't see that the interest is there... --- James Newton: PICList webmaster/Admin mailto:jamesnewton@piclist.com 1-619-652-0593 phone http://www.piclist.com/member/JMN-EFP-786 PIC/PICList FAQ: http://www.piclist.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist