James Newton, Host wrote:
> 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.

This can work for some modules, like the standard PORT module.  It
initializes the I/O ports according to the /INBIT and /OUTBIT preprocessor
directives, and is now totally canned.  Many other modules are templates
that expect you to fill in sections (like the interrupt module), or do a few
minor customizations (like setting the baud rate in the UART module).  Some
of this is alleviated by having a single project file which merges my
existing STRT, INIT, and MAIN modules.

> e.g. an include file with stuff for LCD interfacing could be always
> present.

Right, but what about various configuration options?  I have never done a
project with a character LCD, so I'm not that familiar with them, but isn't
there something that needs to be configured for your particular hardware
setup?  The oscillator speed and I/O pin assignments are already configured
in the main file, but is it really possible to can a LCD module?  Even if
so, what about modules that can't be quite so easily canned?

Some subsystems can be configured with a few numeric parameters.  The UART
baud rate is one example.  I suppose the UART module could require UART_BAUD
as a previously defined constant and produce a appropriate assembly time
error if it is not specified.

> 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 wouldn't want to be the keeper of the modules.  I'm willing to help set
this up and make what I have available, but not to be the code police.  Each
module submitted would have to stand on the reputation of the author.
Remember, I'm not going to be using this system.  I've already got my
environment nicely set up on my own machines with code I know I can trust.

I'm not clear on how you can pass configuration parameters to canned
modules, have a single source file from the end user point of view, and
still have each of the canned modules separately assembled to avoid name
space collision.

There needs to be a distinction between global settings and the private code
added by the user.  All the canned library modules have to be separately
assembled because there is no way to guarantee namespace uniqueness, but
some parameters need to be globally known.  This is why I have two include
files for each project, xxxlib.ins.aspic and xxx.ins.aspic.  The first sets
global parameters and is visible to canned include files.  The second is
visible to all project-specific files and includes the first.  There is a
stub file for each canned module which includes the xxxlib.ins.aspic file
for the project, then the library file, then the END directive.

Since you have a stateless connection and need the user to submit a single
file, that file will probably contain some special syntax to distinguish the
global section from the private user code.  A program parses this, breaks
the pieces apart, and orchestrates all the builds.  It may sound
complicated, but is actually pretty easy to do.

>> 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.

But since you have a stateless connection, how do you remember this from
build to build?  You wouldn't want to have to specify the PIC type every
build.

I guess if you really wanted to get fancy, there would be a special syntax
in each canned module that explained in a machine readable way what
parameters it required and what their defaults are, if any.  This could be
parsed and presented as a configuration page via some sort of web magic.
The results would be written to the header section of the user's single
file.  I have no idea how to do this or even if it's reasonably tractable.

> 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.

All to avoid installing my environment directly?  Well, yeah, I guess my
install and setup procedure is not trivial.  You need to be Alan or
Jan-Erik.

> - 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.

Sounds like a great deal of work on your end.

> - 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.

Do you really want to do all this work?

> - 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.

Gee, maybe it can suggest an appropriate programmer ;-)

> - 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.

While pay might encourage someone to provide a nicely canned module with a
good set of tweak options, I can't see anyone actually paying for this.
Remember, this would be limited to small starter projects.  Nobody is going
to do a commercial project this way, and the single user code module
limitation would be too restrictive for any "real" projects.

If there is a value to this, it's the approachable hold-your-hand way to get
that first LED blinking or "Hello world" out the UART or onto a character
LCD.  A secondary advantage is it provides a common framework and
conventions for sharing example code or doing quick demonstrations in trying
to explain bigger concepts.  If a newbie had a question about the A/D, for
example, one could provide a complete working project that reads the A/D and
writes the result to a port or the UART or something, with all the I/O
mechanics hidden so that only the dozen lines to access the A/D actually
need to be written and provided.

The last thing I would want to see is something like Microchip's visual
device initializer.  I wish they'd never done that.  It presents the
impression that creating a real PIC project is easier than it really is.
Too lazy to read the manual?  No problem, just clickety-click your way thru
a few menus and poof, your PIC project is all done.  Of course it's not that
simple, but managers paying for expert consulting services don't always
understand that.

If you do this, it should be made abundantly clear that this web service is
just to learning tool for making a few starter projects, and definitely not
the way to create "real" projects.

> Disadvantages are:
>
> - The server may crash.

Then the user can get all his money back he paid for it.

> - The work required to set it.

That's totally up to you of course.  If you're serious I'm willing to
provide some template files and special build tools, but you're on your own
with all the web magic.

> - If no one uses it, it's a waste.
>
> - Microchip may lay an egg.

Huh?  All this is to their advantage.  I can't imagine why they would
object.  Besides, everything you are proposing is perfectly legal as I
understand it, so they don't have to like it anyway.

> Anyway... Since it is just Olin and I talking about it so far, I don't
> see that the interest is there...

I'm not convinced either.  You'd be taking on the bulk of the work, so this
is up to you.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist