usbpicprog-technical

[Usbpicprog-technical] Proposed schematic for future compat with 2.5V devices

[Francesco M. <f18...@ya...>]

Hi,
    as written in upp website (http://usbpicprog.org/?page_id=5) currently the 
UPP cannot be used with PIC24 and PIC33 series because of the TTL output levels.

I attach a sligthly modified version of the UPP schematic: here the PGD and PGC 
lines are attached instead to two PMOS instead of directly to the ICSP connector.
Through a simple jumper, the user of UPP can select whether to send 0-5V or 
0-2.5V to the PIC being programmed.

The 2.5V reference could be generated using a common LM317 or any other linear 
regulator.

Pull-down resistors on the drain pins of the two new PMOS may be necessary to 
ensure a good zero voltage level.

This should allow to use UPP to program also 2.5V devices, isn't it?
Do I miss something?

What about dynamic characteristics? I don't know which data rate should the 
clock and data line be able to handle...

THanks,
Francesco


PS: it would be nice to have an SVG version of the schematic in the website HW 
page, instead of the current medium-resolution PNG.

-- 

Re: [Usbpicprog-technical] Proposed schematic for future compat with 2.5V devices

[Francesco M. <f18...@ya...>]

Hi,

Frans Schreuder ha scritto:
>     Pull-down resistors on the drain pins of the two new PMOS may be
>     necessary to ensure a good zero voltage level.
> 
>     This should allow to use UPP to program also 2.5V devices, isn't it?
>     Do I miss something?
> 
> 
> Thanks for thinking with me about the hardware, but I can't agree with 
> your version of the circuit for a couple of reasons:
> 
>     * With these mosfets you have made an open-drain circuit which can
>       pull the data / clock line towards 5V / 2.5V. What about if you
>       want to send a "0"?
right; I thought that pull-down resistors could be used for that.

>     * I don't like the size of the circuit you have added. usbpicprog
>       must be kept as simple as possible in terms of hardware. The L317
>       and all the jumpers and stuff make the circuit too complex to control
>     * You are losing the pin-direction of the data line, with a mosfet
>       you can "write" to the data line, but how will you read the level?
indeed. This is the killer reason for the proposed schematic.
Actually I "forgot" about the fact that the PGD dataline must be bidirectional 
:/ Sorry!!

>     * I have already been thinking about a revision with just a
>       resistive voltage divider, this way you achieve the same with just
>       2 additional resistors connected to 2 other pins of the PIC. (You
>       don't need all this additional stuff :P )
The problem of a resistive divider is that if the current drawn from the "middle 
node" (the node connecting the two resistors) is comparable with the current 
that the UPP is sourcing, then it ceases to be a simple resistive divider and 
the voltage at the middle node drops.
A solution with the resistive divider may be the attached one: if the jumper is 
present, then the two resistors attached to the UPP's PIC divide by two the 
voltage; the buffer is used to avoid problems if the PIC-to-program draws too 
current.
Since a buffer is used, using an IC which packages four opamps, another opamp 
may be used as a non-inverting amplifier with gain = 2; this way when you're 
programming a 2.5V PIC, the UPP-PIC gets back TTL levels, instead of 0/2.5V levels.
The nice thing is that since the op-amps are always powered with 0/+5V, the 
UPP-PIC always get back 0/5V TTL levels from the PIC-to-program, without the 
need of a further jumper.
I hope I was clear :)

Something similar (not shown in the attached schematic) may be done for PGC 
clock line (using a single opamp since that's not a bidirectional line, AFAIK).

How does it look?


>     What about dynamic characteristics? I don't know which data rate
>     should the clock and data line be able to handle...
> 
> If you use long wires ( > 40cm or something), the wires become the 
> limiting factor. Else, it's the clock frequency of usbpicprog but since 
> it's an synchrounous system, the software determines wether it wants to 
> use higher or lower data rates. I am also testing this while writing the 
> software.
ok; btw using op-amps as suggested above the data rates shouldn't be a problem 
(op-amps up to 20Mhz are very cheap).

THanks,
Francesco


-- 

Re: [Usbpicprog-technical] Proposed schematic for future compat with 2.5V devices

[Frans S. <fra...@gm...>]

2008/10/9 Francesco Montorsi <f18...@ya...>

> Hi,
>
> Frans Schreuder ha scritto:
>
>>    Pull-down resistors on the drain pins of the two new PMOS may be
>>    necessary to ensure a good zero voltage level.
>>
>>    This should allow to use UPP to program also 2.5V devices, isn't it?
>>    Do I miss something?
>>
>>
>> Thanks for thinking with me about the hardware, but I can't agree with
>> your version of the circuit for a couple of reasons:
>>
>>    * With these mosfets you have made an open-drain circuit which can
>>      pull the data / clock line towards 5V / 2.5V. What about if you
>>      want to send a "0"?
>>
> right; I thought that pull-down resistors could be used for that.
>
>     * I don't like the size of the circuit you have added. usbpicprog
>>      must be kept as simple as possible in terms of hardware. The L317
>>      and all the jumpers and stuff make the circuit too complex to control
>>    * You are losing the pin-direction of the data line, with a mosfet
>>      you can "write" to the data line, but how will you read the level?
>>
> indeed. This is the killer reason for the proposed schematic.
> Actually I "forgot" about the fact that the PGD dataline must be
> bidirectional :/ Sorry!!
>
>     * I have already been thinking about a revision with just a
>>      resistive voltage divider, this way you achieve the same with just
>>      2 additional resistors connected to 2 other pins of the PIC. (You
>>      don't need all this additional stuff :P )
>>
> The problem of a resistive divider is that if the current drawn from the
> "middle node" (the node connecting the two resistors) is comparable with the
> current that the UPP is sourcing, then it ceases to be a simple resistive
> divider and the voltage at the middle node drops.
> A solution with the resistive divider may be the attached one: if the
> jumper is present, then the two resistors attached to the UPP's PIC divide
> by two the voltage; the buffer is used to avoid problems if the
> PIC-to-program draws too current.
> Since a buffer is used, using an IC which packages four opamps, another
> opamp may be used as a non-inverting amplifier with gain = 2; this way when
> you're programming a 2.5V PIC, the UPP-PIC gets back TTL levels, instead of
> 0/2.5V levels.
> The nice thing is that since the op-amps are always powered with 0/+5V, the
> UPP-PIC always get back 0/5V TTL levels from the PIC-to-program, without the
> need of a further jumper.
> I hope I was clear :)
>
> Something similar (not shown in the attached schematic) may be done for PGC
> clock line (using a single opamp since that's not a bidirectional line,
> AFAIK).
>
> How does it look?
>
1: I am not going to change the hardware that much right now, let's first
investigate the resistive divider thing
2: the pins don't draw current, so we CAN use resistive dividers
3: stop doing so difficult, I don't want to use more components and
certainly no opamps / voltage regulators and all that stuff


>
>
>     What about dynamic characteristics? I don't know which data rate
>>    should the clock and data line be able to handle...
>>
>> If you use long wires ( > 40cm or something), the wires become the
>> limiting factor. Else, it's the clock frequency of usbpicprog but since it's
>> an synchrounous system, the software determines wether it wants to use
>> higher or lower data rates. I am also testing this while writing the
>> software.
>>
> ok; btw using op-amps as suggested above the data rates shouldn't be a
> problem (op-amps up to 20Mhz are very cheap).
>
> THanks,
> Francesco
>
>
> --
>
>
>
>
>
>

Re: [Usbpicprog-technical] Proposed schematic for future compat with 2.5V devices

[Francesco M. <f18...@ya...>]

Hi,
>     A solution with the resistive divider may be the attached one: if
>     the jumper is present, then the two resistors attached to the UPP's
>     PIC divide by two the voltage; the buffer is used to avoid problems
>     if the PIC-to-program draws too current.
>     Since a buffer is used, using an IC which packages four opamps,
>     another opamp may be used as a non-inverting amplifier with gain =
>     2; this way when you're programming a 2.5V PIC, the UPP-PIC gets
>     back TTL levels, instead of 0/2.5V levels.
>     The nice thing is that since the op-amps are always powered with
>     0/+5V, the UPP-PIC always get back 0/5V TTL levels from the
>     PIC-to-program, without the need of a further jumper.
>     I hope I was clear :)
> 
>     Something similar (not shown in the attached schematic) may be done
>     for PGC clock line (using a single opamp since that's not a
>     bidirectional line, AFAIK).
> 
>     How does it look?
> 
> 1: I am not going to change the hardware that much right now, let's 
> first investigate the resistive divider thing
> 2: the pins don't draw current, so we CAN use resistive dividers
> 3: stop doing so difficult, I don't want to use more components and 
> certainly no opamps / voltage regulators and all that stuff
ok ok; it's just that I have all hardware components at hand for building the 
UPP but since I have to use (in near future) a PIC24, I'd like to directly build 
an hardware version which can handle them.

So let me ask you 1 last thing; then I won't bug you anymore :)
when do you expect to be able to test/release the new schematic with the 
resistive divider?

Thanks,
Francesco

-- 

Re: [Usbpicprog-technical] Proposed schematic for future compat with 2.5V devices

[Frans S. <fra...@gm...>]

> So let me ask you 1 last thing; then I won't bug you anymore :)
> when do you expect to be able to test/release the new schematic with the
> resistive divider?

The software needs to support it as well, but I think I will start with it
within the next 1 or 2 months if I have time.
But I can't guarantee anything about when it will be finished, for now if
you want to use PIC24, you better use a commercial programmer.

Cheers,

Frans