On Tue, Aug 13, 2002 at 12:17:41AM +0200, jumanji wrote:
> From: "Byron A Jeff" <byron@CC.GATECH.EDU>
>

I saw in a future post of your that you felt that you put everything you needed
to on the table. I just haven't had an oppotunity to respond to this post.
If you have time, I'd like to continue the discussion.

I'm pretty sure we reached consensus on the technical merits of each other's
views. Your are well thought out and solid. I don't think there's a need to
discuss them further unless you just feel like it.

What I'd like to further discuss are the differences in the goals and
philosophies of each approach. My thesis is that you primary list of goals:
simple interconnected modules that facilitates a lower barrier to entry on
a per project basis, works well for seasoned designers. However that from
both a novice and support standpoint that the system is more complicated.
I will do my best to both sitck to the point and keep it short.

> >The primary purposes are create a ready to use
> > development environment and to standardize the base so that everyone that
> > has one of these units can be assured of a base set of I/O devices when
> > developing or supporting a project.
>
> I don't see why my concept would obstruct the persuit of standardisation :)

It does obstruct because in your system all that's required is the PICbase.
The very fact that the system is modular means that other than the PICbase.

[Byron pulls another slip from the Analogy Machine and reads:] imagine the
C programming language without the C library. Everyone could write C but
each person would have to use a I/O library of their own choosing. No
matter how wide a variety of libraries that existed, an no matter how
clever or useful they are, there would be a barrier to standardization
precisely because choices are available.

Virtually every C programming environment comes with the C library. One
can write to that library specification with confidence because one knows
it's going to be there.

Further imagine trying to write the standard hello world program if the
printf function were optional.

There are issues in paring down the base.

And a reminder: I'm discussing the prototyping base, not the per project
base.

>
> > I think I finally have clarity on your dissent to I/O device integration,
> Your
> > PICbase fits well with the modular environment that you are describing
> where
> > you'll take the base and essentially permanently affix it to a project. So
> > for the next project, you'll start with a new base. Got it. And if that's
> the
> > tack then you are absolutely correct that the base should have as little
> > integration as possible.
>
> Tadaa heheh
>
> > Of course I'm tacking in a completely different direction...
>
> I knew it!! haha
>
> > > With putting alot of stuff on the same PCB as the PIC, you actually
> narrow
> > > its flexibility imo.
> > > With only the circuit to program, run & connect to a PIC on a PICbase,
> it
> > > can be used by everybody, for many many DIFFERENT things,  this is about
> the
> > > widest flexibilty I can Imagine. Plus, you can work on different
> projects at
> > > the same time, just buy more PICbases.
>
> > Bingo! This is the crux of the difference between our paths. You're
> thinking
> > in terms of multiple small units, one per project. My Designer concept
> only
> > has a single reusable unit. It's used to develop the project, but it isn't
> > integrated into the project at the end. Instead the final project is
> > transferred off onto its own board and then the Designer is reused for the
> > next project.
>
> Correct, but my method doesn't exclude yours :) plug a PICbase into a
> breadboard, your designer or similar thing & you're already a fair bit on
> the way with your project. You can keep this 1 system for all your
> developments/experiments & still other users can use the other advantages.

Here's the problem. Novice is presented with two choices: PICbase for $20 or
PICbase + Designer for say $100. Which do they choose?

[..as another slip emerges from the Analogy Machine] It's the difference
between and entire computer and just a CPU. The CPU is an essential component
to an entire computer, and is cheaper than an entire computer. However it
isn't sufficient.

This isn't an issue except for the fact that a novice will probably be unclear
of the distinction.

> program it with the aid of only a pencil & a piece of paper.
> (i.o.w. I don't think you'll program many PICs without any kind of computer
> :)

Ask Tony Nixon about his Fobbit. It certainly isn't a computer in the
traditional sense.

>
>
> > > Another motivation could be that the keyboard versions are more
> expensive.
>
> > Absolutely. However if our musical friend didn't have a PC and still had
> to
> > make the same choice, it wouldn't be such a cut and dried decision.
>
> See above :)
>
> > > And, if later you still want a keyboard, you either could buy a cheap
> MIDI
> > > controllerkeyboard or a more expensive master keyboard to add to it.
>
> > Again I failed because of my poor formulation of my argument. If we have
> > both components and they can only be used in a standalone, not modular,
> > configuration, then there is a bit more contrast between the choices.
>
> I'm not sure if I understood you here, but the mentioned keyboards don't
> have sounds onboard, so they would be complementary. (ofcourse they could
> have, with more investment :)

I missed again (sorry Phil Collins ;-). It's narrowmindedness on my part. I
own a digital piano. I'm used to keyboards being attached to sound modules.

>
> > Exactly. The problem is that developing for and supporting a modular
> system
> > is more difficult precisely because of the added complexity of modularity.
>
> I began my suggestion with a condition (if possible to be built ), I'm just
> trying to think of & describe how a max flexible system could look like in
> general terms,  like I said before, it may be even practically impossible to
> build it.

That's not it. It's imminently buildable. It's extremely useful. I'm only
speaking to supportability. As the project's supports we'll run into the
common situation with modularized components...

[ BAJ is an analogy fiend! ;-) ] Your scanner on your PC won't scan. Who do
you blame? The scanner manufacturer? The Operating System? The Driver? The
application? or is it an incompatibility with your port? Hmmmm.

Same idea here. A project with a PICbase doesn't work for a novice designer.
Where's the finger going to be pointed? I mean the PICbase was supposed to
facilitate getting my project going. But because of one misplaced or missing
wire on the designers own wired board it doesn't happen to work. But you'd
best believe we'd get a question or a report faster than your head could
spin.
>
> > If we have a system with 10 modular components and I develop a project
> with
> > modules 1,4 and 5 and you have modules 1,8, and 9, then for you to use,
> test,
> > or support my project, you'd have to purchase more modules.
>
> Yes naturally, but this over-modularising (you can take this to component
> level in all extremity), an edu board should be designed so it is complete
> on itself (incl PICbase then), for its intended purpose.

Which is where I started this discussion, except that I renew my objection to
calling the I/O board an edu board. ;-)

> If we were to build
> the same thing, let's say a HWsequencer, we both would buy a PICbase & you
> tell me (I'd hope heh ;) wat other stuff you are going to plug on (y)our
> development board (where we have plugged the PICbase in)
> & meanwhile some other kind soul is sharing another project with me, for
> which I have another PICbase & development board. :)

Right. I know. But everyone else with a PICbase wouldn't have the same
hardware we have. They wouldn't have to get it. It's both a plus (more
flexible, more modular, cheaper) and a minus (less standardization, harder
to support, requires additional hardware).

>
> > However if we both
> > shared a resuable base (my Designer, not your PICbase) that incorporated
> the
> > functionality of modules 1-6,
>
> We do share it :)

No because you make it optional. And while that's fine, absolutely fine,
for someone who knows how the system works, it can be a novice's worst
nightmare because while it gives the impression of being a complete unit,
it in fact is imcomplete. Then compared to something more complete, like
the Designer, it seems like a bargain... at first.

> I only gave examples of what could be on a board, the details are up to
> you,(I don't know which stuff is of equal level) its not that I have in mind
> stuff like 1 board with 6potmeters; 1 board with 3serial connectors; another
> board with with 13LEDs & a button etc etc..

I know. The only problem is that everything, absolutely everything, is
optional. Therefore there's no consensus as to what's shared.

At the risk of sounding repetitive, this is a beautiful environment for the
intermediate or experienced designer who understands that it's simply a
plug in component, a cog in the machine. But I have misgivings about how to
present such a system to folks walking in off the street as it were.

>
> I'm thinking of PICbase; Educational/experimenter boards ( number = ? mebbe
> its only 1, I can't tell) & development board(s.) + your (plural) ideas.

I can't see either the production of such a diverse system or more importantly
the support of such a diverse system.

>
> > then I could be assured that anyone that had
> > a Designer could run my project out of the box.
>
> You still could :)

No. Everything in your system is optional. It's like saying I can put a
printf in my C program, but the C compiler doesn't have to have the standard
I/O library. I cannot be assured that folks can run my program out of the box
because th library is optional.

BTW I run into this problem with Perl programs all the time.


>
> > And I'm in full agreement with you that if every project physically
> > incorporated the Designer, that it wouldn't work. But the Designer is the
> > prototyping platform, not the final target, so the extra baggage of I/O
> > devices it carries won't carry over to the final project.
>
> With a PICbase in your designer I develop some project.When it works, I
> unplug it (or I just use another) & put it in its final box. This has saved
> me soldering together a bunch of
> general-not-directly-project-related-&-always-recurring circuitry.(&
> possible errors I could make in it)

You're still missing my point. The final box will only have the actual
devices that it uses. It doesn't need to carry anything it doesn't actually
use.
>
> > > True, there will be a need to build different PCB's for the PBK, but on
> the
> > > other hand, alot more PICbases could be sold.
> > Since this isn't primarily a for profit venture, volumn sales isn't
> necessarily
> > a goal. However there is always the issue of mindshare.
>
> Well then, don't think about profit for the manufacturer, think about cost
> reduction for the enduser :)

And a loss of collective value for the community.

>
> > > Your system would be re-useable if i'm not wrong., so you develop
> something
> > > & when its all working & testing, you're gonna build a new circuit to
> run
> > > your PIC & talk to your project. Your PBK then serves for another
> development.
>
> > Bingo. I think we both understand each other.
>
> Yes, I'm starting to get it too :)

And see this is where I think the PICbase in some variant enters the stage.

>
> > > In my system, when some idea pops up, I buy a PICbase & I don't worry
> about
> > > a pwr
> > > supply or watever other gizmos it needs, nor do I waste time on
> soldering
> > > the same thing everytime. I just build the thing inside my project,
> basta :)
>
> > Right. But I think a cost analysis would need to be done as a comparison
> > of purchasing PICbases on a per project basis as opposed to prototyping on
> > a more expensive (initially) box then transferring the project to a real
> > cheap board.
>
> I bet a factory built PICbase is way cheaper & safer then buying the same
> components seperately in supersmall quantities as a hobbieist would do & If
> I were to let make a PCB for my project without the PICbase, the circuit
> would be also more complex.

Well that's a given. But the PICbase doesn't carry any of the I/O and there's
still going to be the issue of supplying those components. But since the
PICbase has no specification for standard I/O components, it'll be every use
for themself.

[ A bunch deleted... BAJ]

[The question were: Do I pay for extra I/O on the Designer? Even if I don't
use those components? ]

> > The answer is yes and yes. However it's only for common, resuable I/O.
> > Remember I agree it doesn't work in a modular scheme where you'd pay each
> time
> > you started a new project.
>
> In my modular system I dont buy 'more' then you, for every project you do,
> you will also buy a PIC, a crystal etc. (& solder it together)
> I buy the same thing, only as an assembled package, which saves me some work
> :)

But that's why our proposed projects are orthogonal and complementary.
The Designer can easily be done with a PICbase at its core. I don't have
any techological problem with that. The Designer only tangentially touches
upon the issue of project migration while the PICbase addresses it solidly.
The Designer provides a foundation for design and support that the PICbase
omits. They'll do very well together. The problem is how to get across the
point to novices that the Designer offers them significant value. Here's a
sample conversation to illustrate:

NU (New User): I just heard about the new PICLIST design system. I purchased
a PICbase for $20. How do I hook up an LCD to it?

PL (PICLIST):  Well while you can certainly choose whatever ports you like,
on the PICLIST Designer (PLD) the low 6 bits of PORTD are used.

NU: Well I didn't buy it. It cost too much. So if the LCD has 8 data lines then
how can I just use PORTD?

PL: The LCD is attached in 4 bit mode. Here's a sample project and schematic
that shows how it works.

NU: I look at it but my LCD has 22 pins while your shows 14. So how do they
map up?

PL: Well the Designer uses the standard 14 pin connector for 44780 LCD
controller. What type of LCD do you have?

...

NU: I hooked it up and tried the program. IT DIDN"T WORK! I can't even blink
an LED on a port.

PL: Well can you describe how you hooked everything up?

....

And so forth and so on. While the PICbase is standard, everything else is
so variable that there are any number of failure points along the way.

So in the end the question is not which system to use as both have their
applications. The issue is how to get the primary target audience, newcomers,
to come on board with the full program, the Designer, as opposed to its
core modular component, the PICbase.

BAJ

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu