>The other class on the table is in the extended programmer
>vein. I think that Jason Harpers really cool depiction
>would be representative of that model.

I do not go along with having all the sockets he depicts.
I believe it should be restricted to 3 possibilities -:


1. Have a 16F877 as the on-board processor. This could be a DIP version in a
socket, or an SM version permanently soldered in, in which case a separate
40 pin socket for a DIP chip would be advisable.

2. Be able to have an 18Fxxx family as a second processor, programmed using
the 16F877 as a programmer. I would envisage this being able to be fitted in
the 40 pin socket mentioned above. If the only processor supplied with the
board is a 16F877 in a socket, then some way of programming to bootstrap
oneself up from a totally blank chip is needed.

3. be able to program through ICSP connection a 16F627/8, but I don't
envisage having a socket for this processor as a standard part of the board,
but am prepared to bend on this. Again the resident 16F877 acts as the
programmer.

I see no need to be able to handle absolutely every chip Microchip make. If
someone expects to need that, then they should be able to make a case for
getting a Picstart+.

This means that the programming side needs to be able to recognise 16F627/8
(2 chips) 16F87x (4 chips, 6 if 16F870/2 are included) and 18Fxxx (4 chips I
think) by the time 28 and 40 pin versions are considered.


>The hardware would provide a facility so that some subset of
>the PIC family could be programmed with it. Truth be told
>there's enough hardware there to program everything:
>A mini CUMP as it were.

Well I think we should not be doing the full range of PIC's, and certainly
should not be trying to do any other processor, which is why I have summed
up above the chips I see as being needed to be covered.

It may be as time passes that expansion is need to cover USB and/or CAN or
some other special interface versions of PIC's, but hopefully these could be
covered by software upgrades later.

These would probably also need extra tutorial material to give examples of
how the specific interfaces work, or it could be assumed that if someone is
leaping into those, they know what they are doing, and so should be getting
a PICStart+ and hence we should not be trying to support them with this
board. That however I see as a decision for later once the current spec
requirements are tied down. The ICSP I believe is flexible enough that there
should be no hardware changes (unless Microchip bring out devices with 3.3V
max supplies :)).

In thinking about what has been written above I get the feeling that there
will have to be two processors on the board, one to handle the programming
functions/ICD host, and the other to be the target. So I suppose one of them
has to be a 16F876 to handle this, with a 40 pin socket for 16F877/18F4xx
target device. I would expect anyone using this system as a development
board for a 28 pin version of the processor to use the 40 pin version within
this board, and then program their 28 pin in the target system by ICSP.

>> Have I managed to sum up the goals ?

>Couldn't have done it better myself. Seriously, I couldn't. Excellent job.

Well thank you kind Sir :))

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body