Sign in

username:

password:



Not a member?

Search piclist



Search tips

Subscribe to piclist



piclist by Keywords

12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | Piclist | PIC programmer

A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.

PIC programmer - ydexter - Apr 30 8:23:00 2003

What is the difference between a serial port based PIC programmer and
a parallel one?





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )


RE: PIC programmer - Wouter van Ooijen - Apr 30 11:20:00 2003

> What is the difference between a serial port based PIC programmer and
> a parallel one?

They use different ports :)

To say more you should ask the difference between specific programmers,
especially serial port programmer vary from DIY almost-no-components to
professional ones with professional prices.

Wouter van Ooijen

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


______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

PIC programmer - Matti Laevaert - Dec 14 13:44:00 2003

Hello,

Has anyone experience with the design of a hardware pic-programmer
(pic16f877) and the design of compatible programming software (in
Visual Basic for example))? Or some information about how to do it,
something more practical than Microchips's information? :-)

Thanks in advance,
Matti Laevaert,
student in electronics, Belgium





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

RE: PIC programmer - Wouter van Ooijen - Dec 14 15:44:00 2003

> Has anyone experience with the design of a hardware pic-programmer
> (pic16f877) and the design of compatible programming software (in
> Visual Basic for example))? Or some information about how to do it,
> something more practical than Microchips's information? :-)

Yep.

http://www.voti.nl/wisp
http://www.voti.nl/wisptool
http://www.voti.nl/wisp628
http://www.voti.nl/xwisp

Everything is available to study.

Wouter van Ooijen

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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer - burt0072003 - Jan 25 13:35:00 2004

--- In , "Wouter van Ooijen" <wouter@v...>
wrote:
> > visit www.picallw.com Has anyone experience with the design of a hardware pic-programmer
> > (pic16f877) and the design of compatible programming software (in
> > Visual Basic for example))? Or some information about how to do
it,
> > something more practical than Microchips's information? :-)
>
> Yep.
>
> http://www.voti.nl/wisp
> http://www.voti.nl/wisptool
> http://www.voti.nl/wisp628
> http://www.voti.nl/xwisp
>
> Everything is available to study.
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products


______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

PIC programmer - Igor Janjatovic - Apr 11 14:12:00 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

PIC programmer - ydexter - Apr 13 9:22:00 2004

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



______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

RE: PIC programmer - Wouter van Ooijen - Apr 13 9:36:00 2004

> 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer to ydexter - Dave Mucha - Apr 13 12:42:00 2004

This thread has taken some turns as you mentioned and some of us are
interested in getting a better programmer.

Can you help us a little and search for programmers and add them to
the database on the piclist pages ?

Since you will be one of the people who get the most from this
project, is it fair to ask you to help us in some small way.

One of the software packages available for many different programmers
is www.ic-prog.com and they also offer links to different schematics
for some popular units.

Dave --- 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer - peterhawken - Apr 13 18:43:00 2004

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




(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

RE: PIC programmer - Phil Seakins - Apr 13 21:22:00 2004

>> 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.





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer - Vasile Surducan - Apr 14 1:47:00 2004

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 need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

RE: PIC programmer - Wouter van Ooijen - Apr 14 2:04:00 2004

>> 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


______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

RE: PIC programmer - Wouter van Ooijen - Apr 14 2:07:00 2004

> 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer - Dave Mucha - Apr 14 9:53:00 2004

> 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer - ydexter - Apr 14 12:57:00 2004

--- In , "Wouter van Ooijen" <wouter@v...> wrote:
> > 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.

I got that, I read some papers and they count very much on rise and
falling time, measured in V/micros. I know what you said.



______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer to ydexter - ydexter - Apr 14 12:58:00 2004

I'm not the kind of person you can trust, believe me or not.

--- In , "Dave Mucha" <davemucha@j...> wrote:
> This thread has taken some turns as you mentioned and some of us are
> interested in getting a better programmer.
>
> Can you help us a little and search for programmers and add them to
> the database on the piclist pages ?
>
> Since you will be one of the people who get the most from this
> project, is it fair to ask you to help us in some small way.
>
> One of the software packages available for many different programmers
> is www.ic-prog.com and they also offer links to different schematics
> for some popular units.
>
> Dave > --- 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





(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: PIC programmer to ydexter - Dave Mucha - Apr 14 14:28:00 2004

--- In , "ydexter" <ydexter@y...> wrote:

> I'm not the kind of person you can trust, believe me or not. This answer surpizes me.

I assume that you have looked at the stuff that is already freely
available and that your posts on the subject were after you found
units that did not meet your needs.

To that end, I assume you at least looked at more than one device and
that you would have some record of what you liked or did not like,
even if it was just memory.

I was not asking for a professional review, just a listing and the
name and the url for it.

And, that is not very much to ask if you will be get biggest reward
from having some very expeianced engineers take their time to design
a device that does not meet your needs.

Since one of your first posts listed that you did not want to pay
$20.00 for a device that only has $10.00 in parts, I assume that you
would be willing to keep the project cost low. The current PIC unit
we have a general layout for is close to $20.00 in parts, not
including shipping.

As I had mentioned in a very early post, if it takes one person one
day to read the 200 plus pages, one day to design and layout a board,
one day to build it, and one day to fix any errors, then one day to
create a very detailed website so a novice can follow the directions,
you can easily see that there is no possible profit for someone who
then sells 10 units a year.

And, yes, it may take slightly more than a day to read the documents.

Dave




(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )