On Mon, Mar 08, 2010 at 09:41:00AM -0500, yorkwils wrote:
> 
> I've binned the idea of 16c71 as I now realise it is OTP.

Good call.

> I guess I can still use Gpasm but need to build a new programmer for 16f876
> (or above) and find software to load it.

Since you are willing to build, I will happily tell you about some DIY
options.

> I'm using Linux (Ubuntu, Gutsy Gibbon 7.10 - I don't think this can access
> the repository any more).

Definitely need to update. At least 8.10 is an LTR.

> Can anyone give me a quick way to get going? What programmer design and
> software would be simple and  best (I can do the electronics but I'm pretty
> dumb when it comes to loading software in Linux).

Since the purchase route has been discussed already, I'm going strictly DIY
here. Fortunately it isn't too terribly difficult.

Piklab may or may not be a viable option. One problem that I find is that
it can be difficult to track down the ton of libraries that large systems
require to build. It's one reason I prefer small modular systems.

So let's start with the hardware. If you have access to a parallel port,
the unfortunate dying breed that it has become, then my Trivia PIC
programmer series is still workable. You can find it here:

http://www.finitesite.com/d3jsys

Both low voltage and high voltage versions are there along with Brian
Lane's picprg programming software. The 3.01 version update I have on the
page will program the 16F876 with no problem.

The one caveat that remains is the connecting cable. Keep it short to limit
problems. Two cabling systems that always have worked for me are the old
parallel port ribbon cables from the even older IDE multifunction cards.
You can see a sample on the left side of this picture:

http://www.finitesite.com/d3jsys/picdesigner/cables.html

The other, which functions to a bit longer length, is to solder ethernet
twisted pairs onto a DB25 header. This works well when building the
programmer onto a breadboard.

In any case don't spend a lot of time on it. At this point in time I don't
even consider these to be programmers any more. Their sole function in life
is to serve as a one time code dumper. You can even spend a 1/2 hour wiring
one up on a breadboard, use it, then dismantle.

The reason is that I firmly believe that the most productive way to develop
is to use a bootloader. Since chips like the 16F876 are self programmable,
it only make sense to put code onto them so that they can program
themselves.

There are numerous bootloading systems out there. While some use the
onboard USART:

Tiny PIC bootloader: http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm

There piklab support for this bootloader along with this tool here:

http://sourceforge.net/projects/tinybldlin/

For programming it in Linux. The Tiny page also has pointers to a host of other
bootloaders.

Personally I'm partial to bootloaders that bit bang their interface. It
gives the advantage of being able to select what I/O to use to interface to
the host. That means that out of the way pins (such as MCLR when usable as
a selectable input pin) make an excellent choice because it costs virtually
no real estate on your target. Some examples are Wouter's WLoader:

http://www.voti.nl/wloader/index_1.html

Wouter's ZPL:

http://www.circuitcellar.com/flash2002/Honorable/M285-abstract.htm

Interesting because it actually programs the PIC by selectively resetting
it.

And finally the one that I'm using now, a slightly modified version of
Frank Sergeant's Pikme bootloader:

http://pygmy.utoh.org/pikme/index.html

Which I updated to work with a 16F88. Both Wouter and Frank have written
software in Python using the pyserial module to interface to their loaders.
Both have also used very uncomplicated interfaces to the serial port to
connect. Frank's is little more than a couple of resistors. Wouter's
El-Cheapo interface uses a handful of resistors, zeners, and transistors to
interface.

It creates a usable development environment without having to spend a ton
of cash or interface to a lot of complicated software. Plus the serial
interfaces on the bootloaders give an instant serial debugging port to work
from. 

The only real problems are the fact that bitbanged bootloaders are a bit
slow and that of course they suck up some memory from the application.
Frank's pikme doesn't run reliably using the 16F88 internal oscillator at
9600 BPS. I had to slow it down to 4800 BPS to get it to work.

And work it does. I'm using it right now to develop my self hosted forth
for the 16F family. run gpasm, use Frank's python tool to dump (I updated
it so that it runs with USB serial ports now), then run minicom to connect
to the project and run the application. No programmer in sight (I think the
TLVP is still sitting in a box in my car) and I have all the 16F88 tools
available for my use.

So that's my two cents. Hope it's worth something to you.

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist