PIC programmer

Started by Igor Janjatovic April 11, 2004
Hello,

I'm working on PIC programmer and I need advice.

After spending one day on Internet checking all of the existing solutions
both hardware and software, and one additional day to read all of those ICSP
Manuals from Microchip, and another day to evaluate signals from ICProg
using digital o'scope, I decided to use Tait classic programmer with ICProg.
I have a problem with SPI connection and you can see details if you download
PICLISTProg1/2.pdf files that I just uploaded to this group.

Link: http://groups.yahoo.com/group/piclist/files/

Question is: should I go with schematic 1 or 2? Any other suggestions? Sch2
looks more straight forward since jumper is used but Sch1 could work as far
as I know... am I right about Sch1? I want to avoid that jumper, obviously
:)

What I'm trying to do is to build simple, reliable and low cost (but not 'El
Cheapo') programmer that can deal with PIC ICSP in both normal (+13V) and
LVP (+5V) mode, I2C serial EEPROMs and SPI serial EEPROMs (or any other
serial device that can be connected to this programmer).

Regards,
Igor



OK, folks

I think I saw enough opinions about PIC programmer. I think you own
more experience than me, so I belive you. Until I will be able to get
a decent osciloscope and analize the signal I will use JDM to put the
software into PICs. I'm not able to imagine why is so hard to shape
some serial signals, but I will get this in future. I'm a little bit
dissapointed because the thread was moved in another direction ( see
USB versus RS232, PC future, and other things ), but I was curious
about what kind of signals you must provide to the PIC's pins to
respect the Microchip specifications. Maybe I will make you angry, but
I really don't see why so much trouble with reflections and signals
shape constructions. As a matter of fact, the comunication speed is
not so high. If one can post about this I will be very happy, because
Microchip doesn't talk much about those problems.

thanks for your posts



> I really don't see why so much trouble with reflections and signals
> shape constructions. As a matter of fact, the comunication speed is
> not so high.

Reflection, crosstalk etc. has nothing to do with communication speed,
only with signal rise time. You can get lots of bouncing when you send a
fast-rising 1 Hz square wave over a 1m cable to a high-impedance
receiver.

One of the toughest problems I evert hunted down (note: I am a computer
programmer, not a hardware guy!) was a bundel of some 32 address + 16
data wires running maybe 10 cm from a bus to a bunch of buffer chips (it
was a kind of bus riser). The bus was of course driven with a low
impedance (and the bus itself was properly terminated at the ends!), but
the receivers were high-impedance. When a certain combination of address
and data was presented on the lines the (edge-triggered) receiver would
consequently read a different value (this happened only on a few
address+data combinations!). A high-speed local analyser showed the
problem nicely. It disappeared totally when even a modest (10k) load was
placed on the lines near the receiver.

> If one can post about this I will be very happy, because
> Microchip doesn't talk much about those problems.

Because it is not a PIC issue, it is general electronics. Like they
don't explain Ohm's law.

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products



Microchip have a data sheet for programming their serially programmed
PICs. This is most of the range, but there are some that are not
covered by the data sheet. The data sheet is 260 pages so it's not
too easy to describe the programming method in one post. Here is my
attempt. Excuse me if I miss some details here and there.

4 things are needed for programming: Vdd, Vpp, clock and data
lines. Vdd, should be abe to be set between 2V and 6V. Vpp should
be 12V - 14V. The data and clock lines are TTL or CMOS levels.

The general idea is that the programmer sends a 6 bit instruction to
the PIC using the data and clock lines followed by a 15 bit data
word. This is normally an instruction to programme a memory
location. It has to be done several times and then read back until
the return data matches what has been written at a variety of Vdd
voltages. The data is then written to the location more times
accordig to the number taken to get valid data being read back. The
number of times data is written can be up to 100 for each location.
Then the memory location is incremented and the process is repeated.

The basic problems in the simplest programmers are: Vdd should be a
variable voltage at up to 100mA. Vpp should be a variable voltage
also up to 100mA. Most cheap programmers don't provide 2 x 100mA
power to the chip and nor do they offer variable voltages. The data
and clock lines from a serial port programmer are RS232 compliant (1
is -3 to -12V, 0 is +3 t +12V) the levels have to be converted to 0V
and 5V. The timing between the clock and data lines is critical.

Now, the average serial port will provide up to about 25mA of current
on each of the lines. It will take up to 8 lines to provide 200mA of
current that the programmer should be able to provide, so the power
supply is compromised.

Cheap and simple programmers don't allow variable voltages. While it
is possible to do without them, the programming is not as stable as
with a production programmer.

RS232 ports are difficult to control through Windows when the timing
is critical between the clock and data lines. It is quite an
achievement to do this under Windows bearing in mind the operating
system gets in the way and the port was never designed to be driven
this way. Timing can be compromised because of the poor real time
response of Windows (and other operating systems).

The programmig is very interactive. Some of the cheaper programmers
don't provide a return data path, so the programming is carried out
according to a best guess rather than writing followed by testing for
each byte. Data stablity can be poor and erasing can be difficult in
the future as a result.

All of these compromises can be accepted individuallly by most PIC
devices. Add several of them together and one can see why some
programmers work for some chips and not others, work on some PCs and
not others and work for one length of lead ad not another. Add
the 'in circuit programming' capability to a cheap programmer where
the target system has a huge effect on the programmig parameters and
it almost becomes surprising that the cheap programmers work at all.

Let me state very clearly here: I am not criticising any of the
cheap self build programmers. They all have a purpose and they
provide an effective low cost entry to PIC programming. My concern
about them isn't the designers' abilities, it is more about the
variables that a programer will meet in the real world.

Remember that I have written in a few paragraphs some of the
requirements that Micropchip set out in 260 pages. The detail of
programming each device is far more complex than I suggest with a
quick gloss over of the procedure and there are excpetions to almost
every programming parameter that I have mentioned. To the
programming purists - my apologies for missing important chunks of
the procedures. And to those who have a mind to build their own from
my description: There is still 206 pages to be read before you even
think about starting.

While I am writing, Dave Mucha in other posts has requested
information regarding programmers in the database he has set up. I
am currently working with dave and two others looking at the
feasability of designing a reliable unviersal programmer for self
build. It will help greatly if you can enter the details of any
third party programmer that you have used. the More we know about
what exists, the better we can assess the needs for a new design.
Thanks to all who can make the contributions

Peter

--- In , "ydexter" <ydexter@y...> wrote:
> OK, folks
>
> I think I saw enough opinions about PIC programmer. I think you own
> more experience than me, so I belive you. Until I will be able to
get
> a decent osciloscope and analize the signal I will use JDM to put
the
> software into PICs. I'm not able to imagine why is so hard to shape
> some serial signals, but I will get this in future. I'm a little bit
> dissapointed because the thread was moved in another direction ( see
> USB versus RS232, PC future, and other things ), but I was curious
> about what kind of signals you must provide to the PIC's pins to
> respect the Microchip specifications. Maybe I will make you angry,
but
> I really don't see why so much trouble with reflections and signals
> shape constructions. As a matter of fact, the comunication speed is
> not so high. If one can post about this I will be very happy,
because
> Microchip doesn't talk much about those problems.
>
> thanks for your posts




>> I really don't see why so much trouble with reflections and signals
>> shape constructions. As a matter of fact, the comunication speed is
>> not so high.

Correct. Many people, some of whom do not really understand transmission
line effects, make mountains out of molehills when it comes to this
subject. There is much folklore in this area of electronics.

>Reflection, crosstalk etc. has nothing to do with communication speed,
>only with signal rise time. You can get lots of bouncing when you send a
>fast-rising 1 Hz square wave over a 1m cable to a high-impedance
>receiver.

This would be true only if the components were incorrectly matched. You
should not get any bouncing. Whether it is a high-impedance or
low-impedance receiver is irrelevant. What matters is that the transmitter,
transmission line and receiver should all be of the same impedance, be that
high, medium or low. However, a correctly designed low speed communication
line should never be presented with a fast rise time signal. Such signal
components should be filtered out.

>One of the toughest problems I evert hunted down (note: I am a computer
>programmer, not a hardware guy!) was a bundel of some 32 address + 16
>data wires running maybe 10 cm from a bus to a bunch of buffer chips (it
>was a kind of bus riser). The bus was of course driven with a low
>impedance (and the bus itself was properly terminated at the ends!), but
>the receivers were high-impedance. When a certain combination of address
>and data was presented on the lines the (edge-triggered) receiver would
>consequently read a different value (this happened only on a few
>address+data combinations!). A high-speed local analyser showed the
>problem nicely. It disappeared totally when even a modest (10k) load was
>placed on the lines near the receiver.

The fact that you needed extra loading indicates that the bus was not
correctly terminated as you claim. The receivers themselves ARE the
terminators. If they were high impedance and the bus was low impedance then
they might require shunts to prevent reflections. Doing so however, totally
defeats the whole concept of impedance matching. It's purpose is to ensure
the most efficient transfer of energy from the source to the load. As a
bonus, reflections are eliminated. BTW, it is bundle not bundel.



On Tue, 13 Apr 2004, ydexter wrote:

> OK, folks
>
> I think I saw enough opinions about PIC programmer. I think you own
> more experience than me, so I belive you. Until I will be able to get
> a decent osciloscope and analize the signal I will use JDM to put the
> software into PICs. I'm not able to imagine why is so hard to shape
> some serial signals, but I will get this in future. I'm a little bit
> dissapointed because the thread was moved in another direction ( see
> USB versus RS232, PC future, and other things ), but I was curious
> about what kind of signals you must provide to the PIC's pins to
> respect the Microchip specifications. Maybe I will make you angry, but
> I really don't see why so much trouble with reflections and signals
> shape constructions.


Use the Jdm for example with an ICSP and a cable of 80cm long. Tell me
whe you have programmed ok an A device. Then you will understand all the
folks have pointed here.

Thank you,
Vasile



>> You can get lots of bouncing when you send a
>> fast-rising 1 Hz square wave over a 1m cable to a high-impedance
>> receiver.
>
> This would be true only if the components were incorrectly
> matched.

Bright guy. I take it you use either high-impdance wires, or the
impedance of your special high-impedance receivers matches that of a
wire (30..300 ohm area)?

> However, a correctly designed low speed communication
> line should never be presented with a fast rise time signal.

Now we are talking buisiness. What do think the rise time is of a PIC
output, a parallel port output, or a TLL (for instance HC, HCT) output?
Note: I do not mention the serial port, those outputs are deliberately
slowed.

> The fact that you needed extra loading indicates that the bus was not
> correctly terminated as you claim.

No. It indicates that the 10 cm stub was long compared to the rise time.
BTW the bus itself was build on a multi-layer PCB, in which the
transmission wires sandwiches coax-like between earth layers and wires.
The (high impdance!) recievers on the other cards were sufficiently
close to the transmission wires. This was a space project, it had all
been simulated and analysed to death, except for the riser card, which
was a debugging aid which would never go to space, and hence was not
simulated, analysed and tested to the same standards.

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products


> Use the Jdm for example with an ICSP and a cable of 80cm
> long. Tell me
> whe you have programmed ok an A device. Then you will
> understand all the
> folks have pointed here.

But the worst of all is that you might actually succeed using PC 1, only
to discover that it fails using PC 2. Designing something to work on
your desktop is not exactly the same as designing somethig that must
fork for lots of other people.

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products



> If one can post about this I will be very happy, because
> Microchip doesn't talk much about those problems.

Are you talking about Microchip, company that makes PIC MCUs?
If yes, then try with www.microchip.com
It might help :)

Here's a list of few documents that cover programming issues:

- Complete Mid-Range Reference Manual
- Complete PIC18C Reference Manual
- A PC-Based Development Programmer for the PIC16C84
- In-Circuit Serial Programming of Calibration Parameters Using a PICmicro
Microcontroller
- PICmicro Device Programming: What You Always Wanted to Know (But Didn't
Know Who to Ask)
- How to Implement ICSP Using PIC16CXXX OTP MCUs
- How to Implement ICSP Using PIC17CXXX OTP MCUs
- How to Implement ICSP Using PIC16F8X FLASH MCUs
- How to Implement ICSP Using PIC12C5XX OTP MCUs
- Downloading HEX Files to External FLASH Memory Using PIC17CXXX PICmicro
Microcontrollers
- Downloading HEX Files to PIC16F87X PICmicro Microcontrollers
- PIC12F508/509 Memory Programming Specification
- PIC16F505 Memory Programming Specification
- PIC16F54 Memory Programming Specification
- PIC16F57 Memory Programming Specification
- PIC16F627A/628A/648A EEPROM Memory Programming Specification
- PIC16F630/676 EEPROM Memory Programming Specification
- PIC16F7X7 FLASH Memory Programming Specification
- PIC16F818/819 FLASH Memory Programming Specification
- PIC16F87/88 FLASH Memory Programming Specification
- Programming Specifications for PIC18FX410/X490 Flash MCUs
- Programming Specifications for PIC18FXX39 FLASH MCUs
- PIC16F87XA FLASH Memory Programming Specification (DS39589A)
- PIC16F72 FLASH Memory Programming Specification (DS39588A)
- In-Circuit Serial ProgrammingT (ICSPT) Guide
- FLASH Memory Programming Specification for the PIC16F716
- In-Circuit Serial ProgrammingT for PIC16C433 OTP MCUs
- PIC12F6XX/16F6XX Memory Programming Specification
- PIC18F2331/2431/4331/4431 FLASH MCU Programming Spec
- PIC18F6X2X/8X2X FLASH Microcontroller Programming Specification
- PIC18FX5X5/X6X0 Flash Microcontroller Programming Specification
- PIC18FXX80/XX85 FLASH MCU Programming Specifications
- In-Circuit Serial ProgrammingT for PIC16C715 OTP MCUs
- MCP2505X In-Circuit Serial Programming Specifications
- On-Chip Debugger Specification
- PIC12C5XX/PIC12C5XXA/PIC12CE5XX Memory Programming Specification
- PIC12C67X/PIC12CE67X Memory Programming Specification
- PIC12F629-675 EEPROM Memory Programming Spec in Development Tools
Programming Specifications
- PIC14000 Memory Programming Specification
- PIC16C50X Memory Programming Specification
- PIC16C55X Memory Programming Specification
- PIC16C5XX Memory Programming Specification
- PIC16C64X/66X Memory Programming Specification
- PIC16C6XX/7XX/9XX Memory Programming Specification
- PIC16C7XX Memory Programming Specification
- PIC16F62X Memory Programming Specification
- PIC16F7X FLASH Memory Programming
- PIC16F87X Memory Programming Specification
- PIC16F8X EEPROM Memory Programming Specification
- PIC16HV54X Memory Programming Specification
- PIC17C7XX Memory Programming Specification
- PIC17CXX Memory Programming Specification
- PIC18CXXX Memory Programming Specification
- PIC18FXX2/XX8 Programming Specification
- PIC18FXX20 FLASH MCU Programming Specifications

> thanks for your posts

No problem. Copy/Paste.

Regards,
Igor




> Designing something to work on
> your desktop is not exactly the
> same as designing somethig that must
> fork for lots of other people.


If it forks for everybody, then we have a
LOT of new babies and a LOT of new Dad's
typing with a baby in one arm! Maybe we need a 'babies' folder in the
photos secion. Dave