gnupic: DIY USB programmer ?
Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
7 Jan 2005 01:25:55 +0000
Message-Id: <20050107012552.GB15639@cleon.cc.gatech.edu>
On Thu, Jan 06, 2005 at 06:14:24PM +0100, Manuel Bessler wrote:
> Byron,
>
> On Thu, Jan 06, 2005 at 07:44:30AM -0500, Byron A Jeff wrote:
> > > Verify would in my case be an important 'feature'. Otherwise debugging
> > > is hard to do. It could be a misprogrammed PIC, a problem with the
> > > target circuitry,...
> >
> > Again keep it simple. You can put a function in the firmware to dump a
> > checksum of the program memory.
> >
> > The impression that I got from your original requirements is that this
> > code dumper would not be for development. just initial loads and updates.
> > With that being the case, the only thing required to check is for a
> > misprogrammed PIC. And you can simply implement a firmware function that
> > will give you a checksum of the program memory. If the checksum matches,
> > then you know the firmware is good. The PIC can send it via the serial
> > port.
>
> I need verify. While the main PIC in my project could do the reporting
> back the checksum via RS232, the other boards ("daughterboards") can't
> at the moment. There's no 'back' channel. It wasn't designed into the
> originals. I have realized that I could need it now, but I can't change
> it at this point. Maybe when I do an partial redesign of the
> motherboard/daughterboard comms. Right now all the daughterboards do is
> receive data and control some outputs according to the received data.
Are you planning on integrating the programmer into the main board, or
will it be a separate board? From your description I always thought that
the process of PIC programming would be a separate activity than using
the simulator. So the verify could be a part of the programming board.
Or even better you can have the programmed PIC do the verification.
I thought a minute or three today about doing dumb verification. The basic
idea would be to set up a second one shot, triggered by the clock's one shot.
The verify one shot is configured so that it gives different delays based on
the value of the PIC program data pin. The output of this one shot is then
connected to the receive pin of the USB/serial cable. The basic idea is that
for every trigger of the clock one shot, the data one shot goes off
transmitting back the value of the bit. If you set one delay for 2 or 3 bit
times and the other for 5-7 bit times, then you can simply read back the
characters coming back over the serial port to get the value of the data
pin. Since you can command the pic to read back its program memory, you
can verify it.
But I think that it still over-complicates the process. All you need to
be able to do is to dump some code in the PIC once. Once you can do that
you can put a bootloader on each of the PICs and have each program themselves
directly. Then you can have any number of sophisticated ways for the part
to interact with the host including verification.
Just keep saying to yourself that it's a dumb code dumper that will be used
once per PIC and you'll see why I keep urging you to keep it simple.
>
> And as I said, verify would be good since the users might have problems
> with their setup, and debugging via email/IM is not easy. I've done this
> and it ain't fun.
Understood. However you original objective was to have a programmer that
could program a PIC for someone who doesn't have, and other than this
project, doesn't need a PIC programmer. The best way to handle this is to
dump a bootloader onto the PIC. Then it becomes self programmable. This
philosophy is the core of my Trivial Programmer project.
The more complicated it is, the more likely your end user is going to
find a way to screw it up. You handcuffed the easiest solution which is
one of my Trivial Parallel port Programmers, which were designed for the
activity you want to do. But you required USB. So what I'm proposing is the
3 wire serial equivalent of that Trivial programmer so that it'll work with
any USB to serial cable (or FT232) without worrying about the timing
relationships of the modem control signals. You use the dumb programmer to
drop a bootloader onto the PIC. Now you have a smart PIC which can program
itself, verify itself, and possibly even program/verify other PICs.
BTW you never stated what parts you are using in your cockpit. Care to share?
>
> Implementing a verify function via a USB-to-RS232 converter might be
> hard to do... maybe using a USB-to-parallel might be helpful here.
No. USB to parallel isn't what you think it is. It's a USB to Centronics
Printer cable. There are no guarantees that you'll be able to manipulate
the data, status, and control lines on that cable like a standard parallel
port. You cannot be sure that you can bit twiddle. The only thing that you
can be sure of is that it'll present a standard Centronics Printer Interface
to the printer.
I'm well aware of the remote circuit debugging you are referring to. I find
The simpler you keep the programmer, the more success you'll have. So let the
dumb programmer dump the code, then let the PIC do the verification. The PIC
is much much smarter than the dumb programmer, so it'll be easier to get the
PIC to verify itself than getting the dumb programmer to do it.
BAJ
