gnupic: DIY USB programmer ?
Subject:
Re: DIY USB programmer ?
From:
Manuel Bessler ####@####.####
Date:
7 Jan 2005 17:09:10 +0000
Message-Id: <20050107181020.C1120@betazed3.varxec.de>
On Thu, Jan 06, 2005 at 08:25:52PM -0500, Byron A Jeff wrote:
> > 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.
Right now I don't plan to integrate anything on the boards. So a
standalone programmer.
> 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.
Maybe I should explain a bit about the topology of my project. Right now
its a "motherboard" which has a serial port with which it talks to the
host PC. This motherboard has a 18F452 on it. The PIC has a serial
bootloader, so this one is easy. Programming once out of circuit and you
are set.
Now, the daughterboards connect via 4-wires: +5V, GND,
SerialData,SerialClock.
The serial line is syncronous (data bit gets clocked in at rising edge
of SerialClock on the daugherboards). SerialData and SerialClock are
unidirectional (motherboard -> daughterboards).
Its a multi-drop bus.
Daughterboards also use PICs, right now the 28pin 18Fseries PICs like
18F242,252,2220,...
Every daugtherboard PIC listens on the serialclock/data lines.
A simple addressing scheme is used to select the daugherboard. All
receive it, but if they don't see their own address, the data is
discarded.
here is the URL to my project:
http://cockpit.varxec.net/electronics/PHCC.html
> BTW you never stated what parts you are using in your cockpit. Care to share?
Sorry. See above.
BTW: I've been using your THVP for the whole project. Recently I tried a
JDM type programmer, but I'm still having issues with it.
Serial port is a bit less picky about the length of the cable connecting
the PC with the programmer. Thats why I wanted to try the JDM.
Manuel
--
Opensource/Free Software: No Gates, No Windows
