On Mon, Aug 19, 2002 at 07:18:15AM -0400, Olin Lathrop wrote:

It's time for my concession speech. I'm abandoning my single processor design
and switching my vote to Alan's preliminary design that he posted (with a
few caveats which I'll talk about below)). There were a couple of factors than
changed my mind. Let's start with Olin:

----------------------------------------
> 4  -  The bootloader uses the hardware UART.  New firmware (except for the
> bootloader and the reset vector) can be uploaded into a 16F877 in about 37
> seconds using 115.2Kbaud.
----------------------------------------

That's one thing that cannot be done easily with a single processor design.
In fact I realize that's a deal killer because if the FT232 USB to serial
design is used, that rate can be pumped all the way up to 2 Mbits/Sec. In a
single processor design one cannot afford to give the hardware UART to the
bootloader side as it's too important for developement.

Second is Jason's clarification of his pin monitor:
--------------------------------------------------
The logic monitor (NOT "analyzer", that implies capabilities that it
doesn't have) in my design IS for for displaying output and supplying
input.  Think of it like one of those clip-on monitors that have a LED or
LCD element per IC pin, except that it displays on the computer screen
instead, and has the ability to set individual lines as outputs (with
automatic reversion to a hi-Z input if there's a conflict).  Think of it as
a LED on every port A, B, and C pin of the target PIC, except that you
don't need all those LEDs (I did specify at least one actual LED on the
device, just for real-world experience), and aren't loading the pins nearly
as much as a LED would.  Think of it as an optional pushbutton or toggle
switch on any of those port pins, except that you don't need physical
switches (again, one actual pushbutton specified for real-world experience
with debouncing).

Sample rate?  Tens of times a second perhaps, this is for human-rate I/O.

Storage of samples?  Hardware triggers?  Nonexistant, that's not what this
feature is for.
-----------------------------------------------------

In short virtualizing I/O. This I can see as an extremely useful feature. It
of course gives the crossplatform support junkie in me the willies, but as
long as the specification for the monitor is available I'm sure that one of
us GNUPIC folks can write a monitor in Perl or Python that we'll be able to
use. BTW the gpsim simulator already has the concept of virtual I/O modules
that will run in the simulation. This simply extends the concept further out
to the real hardware I/O pins.

The final nail in the coffin was Alan's initial diagram. I finally realized
that he actually wanted a 3 chip system with one chip dedicated to the host
and the other two as sockets. This makes a lot of sense.

That's why talk isn't necessarily cheap and advocacy is important. Each of
these points have come out in extended discussion.

So I'd like to move on to comments on Alan's initial design...

* Despite all of its faults, the prototyping area has to be a breadboard or
  something that's resuable. I read '...consists of all spare PCB area filled
  with dual in line pads or "measle dot" pads on 0.1" centers'. This would mean
  soldering to use it right?

* Jason's virtual peripheral/logic monitor (VPLM) concept negates the need for
  a lot of physical hardware onboard. It also eliminates the worry about
  running physical wires to components. I'm not quite sure how well we can
  virtualize analog hardware though. But the upshot is that only a limited
  amount of physical I/O is required.

* The primary socket in Alan's diagram needs to come filled with a 16F877A so
  that the box is ready to go from first turn on.

* We need high voltage for HVP somewhere.

* I'd personally be happy if there were at least a connector for an actual
  LCD display. I realize now that it can be virtualized, but it would still
  be nice to be able to connect a physical one to the board somehow.

Excellent job gentlemen! So what's next?

BAJ

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