> > See I'm trying to get this system for my students so that they can
> > load their programs to the system dozens, hundreds, or thousands of times.
> > And I need it to run from a Linux box.
>
> Thats where we differ then. I'm more interested in the electronics
> side and don't want the overhead of a complete development system
> tied to every PIC. (And I prefer programming in PIC assembly language
> which is completely portable.)

I haven't made myself completely clear. This system is for rapid
prototype development work. Right now while doing development there
are a few options each with their own "quirks".

1) 16C84 - Probably the best of the bunch. The EEPROM allows for in-circuit
programming and quick turnarounds. However the part is I/O and speed limited.
2) Simulator - The MPSIM software works pretty well but you're locked into
PC land to use it. I've effectively used it under the DOS emulator with Linux.
But it was a lot of additional setup.
3) ICE - Expensive. 'Nuff said.
4) EPROM based PICS - The windows parts are expensive and the programmers are
all PC based. The turnaround time is slow.
5) BASIC stamp - going in the right direction. However running from a serial
EEPROM slows everything down immensly. And development can only be done from
a PC based platform.
6) 17C42 - Fast, runs from external memory, sufficient I/O, built in UART. But
have you priced these puppies lately? Also for the external memory interface
you need 4 to 7 additional chips. Lastly the standard programmers don't do
the 17C42.

The ideal part would be a 16CXX or 17CXX part with a UART and 33 I/O pins
that runs at 20-25 Mhz and is EEPROM programmable in-circuit. But it doesn't
exist and probably will not ever. Discussions on the list from Microchip has
made it clear that their big customers need ultra cheap one time programmable
parts where each penny makes a big difference. They can afford PC based
environments and ICE for doing their work.

So for the rest of us, that is hobby and one-off folks, Our issues of easy
programmability, multi-platform development, and more I/O, and of course the
usual ones of more speed and less power and inconsistent with the goals
of the folks who pays Microchip's bills.

As for the assembly vs. high level language debate, I think the issues have
been re-hashed enough. Both require tools and as long as the tools are
available the choice shouldn't matter. My goal is to produce a high level
front end with multiple back-ends just like GCC. By having an assembly
back-end and a interpreter back-end I can develop with the interpreter and
once the code is working correctly then I can compile it into native code
and blow the part.

The way I see it I'd rather build one interpreter that I can blow into
a OTP then use that OTP interpreter for development in a HLL than to have to
pull a EPROM chip over and over and over for development in assembly.

I guess I need to explain where I've been in terms of SBC development. I
cut my teeth on motorola stuff starting with 6800 stuff and quickly moving
to 68K's. Through experience I found that the two most essential tools
for good development was a good compiler and a good on-board loader/monitor.
At the top of the heap (about 3 years ago) I had a 68340 with a self written
serial file system that was self hosting a C compiler, linker, and assembler.
Then I ran into PICs and all that changed.

I spent the first year trying the learn how to program the danged things. The
Microchip released the 16C84 and the programming specs for everything. In
addition their really cool seminars supplied PICSTARTS 16's for a reasonable
price. But I'm a Linux guy so their tools weren't real interesting to me until
one of my students ran some tests and figured out that everything ran under
the DOS emulator. That helped. Good thing it was serial based programmer.

But the process sucks. Pull the chip, program the chip, test the chip,
repeat. We broke at least one pin off 4 different 16C84's. You have to
be there to do development. With my 68K board hanging off a network I
could do development anywhere I could telnet from. And the kicker was the
16C84 project we were working on was serial based (and I got some good
serial tools from my student) so there was no need to hover over the board
except for the development process.

BTW I also have a special need. I have a class of twenty students that need
to program a board. I'm pretty sure that even in-circuit programming can
withstand that assult.

So as a first attempt I've built a board with a 17C42 with 64K of RAM. The
RAM is loaded using a 16C84 with my student's serial routines. It has some
glitches but is on the right track.

The other thing is the language issue. Consider this: if I have a high
level language I can run the same program on a PIC 16C84, a PIC 17C42,
and a motorola 68K. I can scale the I/O, memory, and speed to match the
particular application I need. Also if I interpret the HLL then once I
have the interpreter solid I can blow it into a OTP and be sure that
part is usable. I can test with interpretation and compile for production.
But if speed isn't the primary issue there's no reason to switch from the
interpreter once it works. This requires some semi-permanent storage.
Hence the serial EEPROM.

Now for development part. I want the following features:

- In-circuit
- Multiplatform
- fast loading and turnaround
- fast execution
- Circuit continues to function even when detached from development
  environment.
- Minimal additional circuitry

Note that many of these are at cross purposes. To support the first two
it requires more circuitry. For the circuit to continue to function
after programming you need EEPROM. for less circuitry you want serial
EEPROM. But that slows the execution.

So there's a bunch of tradoffs. But the one thing that's clear is that
the loader and the target need not be the same. The serial part and
the programmer can be on one board that stays attached to the PC or workstation
and the target can then be separated. Plus the "programmer" can be used
with different targets.

So the programmer would probably consist of a UART, a MAX232, and a programmed
16C84. A DB9 or 10 pin dual header would connect the target to the board.
The programmer's primary job is to program the serial EEPROM on the target.
The programmer holds the RESET/MCLR of the target in reset during programming.

The target's job is to interpret the code in the EEPROM. For speed a target
can transfer the code to a faster device (like a RAM) before executing. Targets
that can execute native code certainly can do so. Some possible targets:

1) A 16C84 and a serial EEPROM. Just like a stamp.
2) A 17C42 that's programmed with an interpreter and a EEPROM loader. It
can interpret in single chip mode or interpret or run native code that's
loaded into RAM.
3) 683XX products that can either interpret or run native code that's loaded
via the BDM port from the EEPROM using a PIC.

The list goes on and on...

I think it's a very powerful and flexible concept.

BTW the chicken and egg problem I'm working on too. How to program without
having a programmed chip. David Tait has given me some good ideas.

Comments?

BAJ