Subject:
Re: DIY USB programmer ?
From:
Byron A Jeff ####@####.####
Date:
8 Jan 2005 03:06:02 +0000
Message-Id: <20050108030559.GA3771@cleon.cc.gatech.edu>
Manuel et. al.
I have a new point to make at the bottom of this post, so keep reading...
On Fri, Jan 07, 2005 at 05:45:56PM +0100, Manuel Bessler wrote:
> On Thu, Jan 06, 2005 at 04:44:27PM -0500, Byron A Jeff wrote:
> > > Thats why I said that I already have that. Olimex has a schematic after
> > > which I did the layout. And I checked if those pin assignments are
> > > half-way sane, and I believe they are (maybe not for a production
> > > programmer, but ok for a prototype programmer).
> >
> > You missed my point. Your user will still have to solder the sockets. ICSP
> > keeps it simple.
>
> Soldering is no problem. My users are "Home Cockpit *Builders*'... they
> like to build. Some don't even fly as they have so much fun building :)
>
> And as I said before, not all my boards have ICSP capability. (I didn't
> want to figure out all the issues with isolating the ICSP pins from the
> rest of the circuit.
>
> An idea would be to build a purely ICSP programmer, and then offer a
> small pcb layout for IC sockets. This socket-board could then just
> plug into the ICSP header on the programmer.
I heard you the first time. The programmer isn't really an integral part
of the setup. It should be standalone or maybe a part of the mainboard.
I'm not proposing putting the header on the daughterboard targets. You
pull the chip, program it, then plug it back into the daughterboard.
>
> > > So, what about requiring a 9..15V power supply, a 555 charge pump for
> > > upping the power to 15V, then a 7812 and 7805. That makes sure that
> > > sufficient power is available.
> >
> > Better to just require a 12-20V supply and regulate it down.
>
> That'd be fine too.
Keep it simple.
>
> > I see I'm going to have to keep you on point. It's only going to be used
>
> Yes I know. I keep "straying" from my original ideas.
Glad that you see it.
>
> While I need a simple programmer for my users, a more complete programmer
> for frequent use (for me and advanced users) is something that I'd
> personally
> like to have for my own development work.
Then there are a number of steller programmers such a the Wisp628 and
EasyProg for the job. You can even build an ICD for the purpose.
> Like a half-intelligent USB 18F2550 based one proposed here.
But again if you're going to build these for yourself, you'll still need
a bootstrap programmer to program the intelligent chip.
There's no reason to reinvent that wheel.
>
> Maybe we should split the ideas into
> 1. USB, cheap, simple, non-intelligent, few compontents ICSP programmer
> and
A bootstrap programmer. That's what the Trivial programmers are.
> 2. USB, still cheap, (half-)intelligent, PIC-based development programmer
> (maybe even with more than one voltage, isn't that what makes a
> programmer a 'production programmer' ?)
Right. Once you have a programmed PIC, there's no reason for it not to
be full blown intelligent.
>
>
> > a handful of times. Keep it as simple as possible. A 12V wall wart will work
> > for any flash PIC. Don't complicate it. 7805 and the 12V zener should be
> > fine.
>
>
> > > Another homecockpit interface solution (not opensource, and
> > > Win+MS FlightSim only) uses something like that. See here:
> > > http://fsbus.de/img/FSCOM.GIF
> > > This solution has the advantage that the PIC burning is built-in.
> > > The user just has to jumper the to-be-burned board to 'program mode'.
> > > Of course he has to write the programming algorithms into his flightsim
> > > interface software. The hexfiles are also compiled into that program.
> >
> > However his solution uses the modem control signals. I think you may find
> > failures using a USB to serial cable depending on the USB chipset.
>
> Well, maybe, I don't have experience with these cables.
Neither do I. But after reading the discussion about FTDI chips, on which
many of these cables are based, I'd be leery about a guarantee about the
modem control bits relative to TX or to each other.
>
>
> Manuel
> PS: Keep those ideas coming. This topic seems to be something that a lot
> of folks are interested in.
Now to the new stuff.
In my original 555 design made a goof. While the circuit which uses a
transistor to make the 555 non retriggerable should work, it doesn't
satify our needs. A brief review:
1. We use TX only for both clock and data to the PIC.
2. The TX line is tied directly to the PIC program data line.
3. The TX line is also tied to a non retriggered 555 which is triggered
by the start bit edge. On the falling edge of the 555 output the PIC
data is clocked in because the output of the 555 is tied to the PIC
program clock line.
Here's what I missed. Even with the non retrigger circuit, the 555 is game
to be triggered again after its timeout. So if the TX line is set for the
PIC to clock in a high bit, just as soon as the 555 times out, it'll
retrigger. OOPS!!!
The solution isn't too difficult but unfortunately complicates the board
a bit. The solution is a second 555 one shot with a longer duration. Or of
course you can use a 556 and get two times. Here's how it works:
1. Everything for the clock 555 is almost the same as before. Same delay,
same input, and same output. The only difference is that the transistor
emitter is tied to the output of the second 555, which I'll call the char
timeout delay.
2. The char timeout 555 is configured to give a delay that is almost the
width of the character being transmitted. Its purpose is to prevent any
retriggering for the entire time the character is being sent. Presuming
the typical N-8-1 transmission which is 10 bit cells, this time is configured
to time out after 8 cells, while the clock 555 is configured to clock after
4-5 cells. BTW both 555s are triggered by the same transistor circuit so that
they trigger together. However since the char timeout 555 is holding up the
retrigger and it's longer than the clock 555, then the clock 555 will time
out and give a falling edge for the PIC clock, clocking in the data.
In this new configuration, TX can wiggle during the entire character, and
the data is latched in on the falling edge of the clock 555, which will
remain no retriggered until the next character.
How of course we've simply transferred the issue as the longer 555 can be
accidentally be retriggered by TX when it times out. So we simply use some
software to solve the issue. By issuing the characters 0x07 and oxff we
can effectively shorten the cell width from 10 bit cells (N-8-1) to 7
bit cells (N-5-4). So TX can be guaranteed to be idle when the character
delay 555 times out after 8 bit cells.
Calibration should be easy. For each of the 555s tie the output back to the
RX of the PC. Then send a the 0xff character which will guarantee to
idle TX by the time either 555 times out. Then read back the character sent.
For the clock 555 tune the resistor until you get back characters
0xf8 or 0xf0 consistently which is 3-4 bit cells delay. Tune the character
delay 555 so that you're getting back either 0x80 or 0xc0 which is 7-8
bit cell delays.
Once that's done the hardware should be ready to roll. When you send a 0x07
down the pipe the clock 555 will clock in a 1 into the PIC after 3-4 bit
cells and TX will return to idle after 6 cells, well before the 7-8 timeout
of the character delay 555. On the other hand sending a 0xff will cause a
0 to be clocked in for the data and of course it'll idle right after the
start bit.
So it adds one for 555 monostable to the circuit.
I went to the Radio Shack today and found all the parts. I'm planning on
using a 4800 BPS clock rate with the clock 555 at about 1ms and the character
delay at a bit over 2ms.
I'll post results of my testing when I get it done.
BAJ
