I'm jumping in to this late, so please pardon me  if I ask something obvious.

> > What sort of serial protocol is used ? Is it sustainable with common
> > Unix serial drivers, or do you have to do some clever stuff with the
> > handshake lines ?

What programmer is this?  I've had a few ideas in my head for awhile for a
device such as this.  It sounds like this might be specific to a certain
small part of the PIC family.  What I have in mind would be a lot more
general purpose.

>
> The source for the 16C7X chip in the programmer is also on the BBS.
> From what I have been able to understand from the source, the protocol
> is pretty asynchronous (read: hideous amounts of time spent sending
> handshake characters in lockstep back and forth instead of using flow
> control) and can be implemented with really easy blocking I/O so the
> code should be trivial to port. If I have to do funky serial setup
> using termios or something, then one camp (BSD or SysV) will be
> unhappy.

Of course, the way to deal with this is to write two object modules (
one for BSD, one for SYSV) which abstract serial IO to the appropriate level,
and then link in the one that you need.  The rest of the code doesn't have
to know about the differences then.

>
> > A generic serial connection to the programmer sounds a nicer solution
> > than porting the parallel-port programmer, since it would be usable with
> > all Unixes rather than being Linux-specific. A special device driver
> > that only works on PC-Linux seems barely better than a DOS-only utility
> > to me.

True.  In fact, hey, just write another serial object module for DOS.

>
> If I had the choice again, I'd be inclined to get some commercial
> serial-based product since kits are annoying. Good thing I got my
> brother to put this one together. :-)

Well, I must be wierd then.  I like building kits.  The ones from Micromint
are a dream, BTW.  Of course, they should offer you the choice of buying
an assembled and tested unit if you want to.

> The one good thing about this kit is that it does verify at min and
> max voltage levels. A definite drawback is that this thing only does the
> 16C5X series chips.

Aha, as I figured.  If I ever get around to designing my programmer, it will
have a variety of Vcc and Vpp and programming algorithms.  I will probably
base it on an 8051 due to external memory addressing issues and the presence of
a real UART onboard.  Oh, and I already have a programmer for 8751s.
Programming will be via the serial port, with a choice of XON/XOFF or hardware
handshaking, and the protocol will be open.  Normal asyncronous serial support
is necessary for platform independence.  Once that is done, parallel port
support is just another access method.  A major goal of this is to be
able to program not only the entire PIC family, but also other microcontrollers,
EPROMS, and EEPROMS.

Is somebody already doing this?  Is anyone interested in banging out the details
and the hardware with me?  Would the world be terribly mad at me if I wrote
the host side software in C++ instead of C?

> When I get around to porting the serial routines, it won't be very
> Linux specific. I just won't promise it will work on platform XX unless
> someone gives a nice XX system. :-)

Reasonable.


> Personally, it would be nice to have a unified set of unix tools with
> a back end for each product but that's probably wishful thinking.

Oh yes.  And no fancy GUI stuff.  I want to be able to use the tools from a
makefile.  If someone else wants to write a fancy front end for the tools,
they can, but the command functionality must be there.

Right now, I'm working on an
assembler which will be flexible enough to work on all of the PIC family just
by loading up a different table of opcode descriptions.   A feature of this
assembler will be strong typing and promotion such that:

clr     label

translates to

clrf    6

if label is register file 6 and

clr     label

translates to

cbf     6,0

if label is register file, bit 0.

I already have that functionality, but I am redesigning the assembler to make
expression parsing work correctly with parentheses, and make it more flexible.