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 | Re: PIC universal programmer - spec and design

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.

Re: PIC universal programmer - spec and design - mikerey35475 - Apr 9 15:31:00 2004

Igor,

I use a Tait classic programmer all the time. As I stated in my post
to ydexter, the only modification I have ever had to make was to add
a couple of 22 picofarad capacitors on the clock and data lines before
they went into to 7407. Well that is if you don't count adding
sockets for 8 pin and 40 pin chips.

Wouter,

I know that you xwisp programmer works, and is a great value, the
only negative that I see with it is having to use Python. That may
not be an issue for some people but what about PIC newbies ? They need
a programmer interface that is basically plug and play, no guessing
about command line parameters, etc. I also agree that $50 is really
too high, it should be do-able for less than $20.

Dave,

Personally if I were going to build a programmer for hobby use and my
computer had a parallel port, I would build a Tait classic
programmer. As I stated previously, that is what I currently use
along with IC-Prog and I am happy with it. I am only offering to help
ydexter to design a PIC programmer for his use. He seems to be
unsatisfied with the designs available on the web, although I don't
remember if he said anything about trying a parallel port based
programmer.

Everyone,

PC manufacturers are slowly eliminating the legacy ports that we use
to run or programmers (both serial and parallel). As Stef mentioned,
it is possible that the next PC you buy has only USB ports on it,
that isn't a big deal as there are currently devices available to
convert USB to serial, and there are adapters available to convert
USB to parallel, but I am not sure whether they will work with PIC
programmers.

Mike




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


RE: Re: PIC universal programmer - spec and design - Wouter van Ooijen - Apr 9 15:42:00 2004

> I know that you xwisp programmer works, and is a great value, the
> only negative that I see with it is having to use Python.

XWisp mis the PC software, not the programmer. A 'native' windows port
does exist (actually more than one). But if a PC user is incapable of
installing 3 softare packages (python, win32all, xwisp) I honestly think
he should not touch a PIC.

> that isn't a big deal as there are currently devices available to
> convert USB to serial, and there are adapters available to convert
> USB to parallel, but I am not sure whether they will work with PIC
> programmers.

They will most likely work perfectly with proggers that use the serial
port for communication. Vit-fiddeling proggers will probably run into
lots of (timing) problems.

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: Re: PIC universal programmer - spec and design - Matt Pobursky - Apr 9 15:53:00 2004

On Fri, 09 Apr 2004 20:31:15 -0000, mikerey35475 wrote:
> Everyone,
> 
> PC manufacturers are slowly eliminating the legacy ports that we use
> to run or programmers (both serial and parallel). As Stef mentioned,
> it is possible that the next PC you buy has only USB ports on it,
> that isn't a big deal as there are currently devices available to
> convert USB to serial, and there are adapters available to convert
> USB to parallel, but I am not sure whether they will work with PIC
> programmers.

This is true, but at least with a desktop PC you can add *real* serial
or parallel I/O cards. In fact, I did this recently to my software/lab
workstation so I could have several "legacy" devices connected and
operating concurrently. It also alleviates a lot of cable swapping
which is a bit inconvenient for me.

I currently have (4) COM ports and (2) LPT ports (serial
debug/programming cable for Rabbit 2000, PICstart Plus, RS232 terminal
cable and RS232 digital oscilloscope connected on COM ports, Parallel
Port programmer and JTAG debugger/programmer pod on LPT ports).  

I bought a lot of convenience for the $12 I paid for the dual
serial/parallel I/O card.

USB converter devices will always be problematic with our development
tools that "bit twiddle" timing and control signals due to the
latencies and timing delays they impose. Of course they usually work
fine for a device that simply is looking for higher level RS232 data
that isn't so timing sensitive (like Wouter's programmer, for instance
-- one of the advantages of his design).

Matt Pobursky
Maximum Performance Systems

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

RE: Re: PIC universal programmer - spec and design - Wouter van Ooijen - Apr 9 16:08:00 2004

> XWisp mis the PC software, not the programmer. A 'native' windows port
> port for communication. Vit-fiddeling proggers will probably run into

Sorry, *is* the PC software, and *Bit*-fiddeling. Typing while holding a
small baby is a bit error-prone.

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 universal programmer - spec and design - Dave Mucha - Apr 9 20:29:00 2004

--- In , "Wouter van Ooijen" <wouter@v...>
wrote:
> > XWisp mis the PC software, not the programmer. A 'native' windows
port
> > port for communication. Vit-fiddeling proggers will probably run
into
>
> Sorry, *is* the PC software, and *Bit*-fiddeling. Typing while
holding a
> small baby is a bit error-prone.

Wyatt James is 7 weeks on Monday, how old is yours ?






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

RE: Re: PIC universal programmer - spec and design - Wouter van Ooijen - Apr 10 0:14:00 2004

> Wyatt James is 7 weeks on Monday, how old is yours ?

14 days on monday

Wouter van Ooijen

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



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

Re: PIC universal programmer - spec and design - Scott Lee - Apr 10 0:53:00 2004

If you think it's hard to type while holding a 14 day old child wait
until they are about 7 or 8 months old -- they actively try to take
over the keyboard. My 8 month old son is actually harder to deal with
than my soon to be 4 year old daughter that just tries to kick me off
the computer so that she can use it. :)

Congratulations!

--- In , "Wouter van Ooijen" <wouter@v...> wrote:
> > Wyatt James is 7 weeks on Monday, how old is yours ?
>
> 14 days on monday
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

Re: PIC universal programmer - spec and design - Dave Mucha - Apr 10 8:43:00 2004

--- In , "Scott Lee" <midl_man@y...> wrote:
> If you think it's hard to type while holding a 14 day old child wait
> until they are about 7 or 8 months old -- they actively try to take
> over the keyboard. My 8 month old son is actually harder to deal
with
> than my soon to be 4 year old daughter that just tries to kick me
off
> the computer so that she can use it. :)
>
> Congratulations! Luckily, out 9 year old is on Mom's Mac, our 7 year old and her fight
over who gets to use it and neither uses their PC as the Mac is on
the net. As far as my PC, only my cat uses that and he just walks
on the keyboard......
Dave






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

Re: PIC universal programmer - spec and design - rj_satterlee - Apr 11 2:40:00 2004

All kidding aside (hello to the new fathers out there), I am finally
going to add my two cents worth to this thread (with some trepidation)
I might add.

I would like to bring some observations that I have to the subject.

1. I looked at a USB design for the PIC. I spent more than 10 hrs,
and less than 100 hours looking at the USB 1.0 specs (easier)
for low speed devices. I found that the packet was complex
enough with enough CRC checksums in them, both CRC5 and CRC16
to take up most of the PIC's time while processing a packet.
And the speeds were high enough to require an external shift
register to get the packet. The clock decode wasn't that bad,
but doing the CRC5 and switching to the command phase was going
to take awhile...... I think in the future, if I have to do
a USB design, I'll look more closely at the Delcom products

http://www.delcom-eng.com/products_USBIO.asp#USBIO

to assist my microcontroller.

2. There is significant software required for the USB driver. In
the delcom case, they supply some software for the interface.

Therefore, I stuck to RS232 communications. In fact, although some
machines might not have an RS232 port, you might consider buying
an interface card for it.

So, as mentioned, I stuck with RS232.

I am building a design for the 28 pin ATMEL +5V EEPROM programmers.
Now don't get excited. I've got the major functional blocks up and
running, but there are a couple of things that I have to do. I will
release it to the group when I've finished the enhancements and
generate a EULA for it (I spent many many hours to make it and if
you want to make money on it, I'd like a cut).

This is an RS232 device that uses the common terminal programs
available on Windoze and Linux (hyperterminal and minicom). And,
I'm sure that there is a comparable application for the Mac World
as well.

I started off with a Perl script for the requirement and found that
with just a little more effort I could move all the smarts to the
PIC. I'm currently using a 16F77 for the project, but almost
any PIC could be used for the PIC programmer. The 40 pin 'F77 was
nice, there was enough I/O so all the outputs went to the EEPROM
socket. I found that I could reliably transfer data from the PC
to the PIC programmer at 19.2K baud by passing the hex format files
directly to the PIC. This works out to about 1000 bytes of
information being passed and indeed programming my 8kBytes of EEPROM
takes 12-15 seconds. Not too bad. I'm pretty sure that the baud
rate can be increased and I plan to up it to about 57Kbaud. In
any event, reliable programming was accomplished. I did over 1500
programming burns of the EEPROM without error while it was in the
perl phase.

In essance, the programmer receives one hex record, programs it
into the EEPROM then verifies the data. It then gets another
record from the PC and processes that. This continues until and
end record is received. I use XON/XOFF protocol between the PC
and PIC for flow control. Works out quite well with both minicom
and hyperterminal. Data can be read back by "logging" the data
coming from the PIC back to the PC. I found that verify commands
work best by retransmitting the intel hex file back to the
programmer for it to read. This way, there is no "skiping" around
requirements for the PC if the record addresses of the hex file
are out of order.

The upshot of this is that reliable RS232 communications passing
straight intel hex records is quite feasiable. For my little
programmer, there is just the PIC chip, the programming socket,
and a couple of 2N2222 transistors for the "rs232" communication.
Oh, and a couple of LEDs and a PNP transistor to supply voltage
to the EEPROM socket (but that's pretty much it).

NOW, on the downside, for the PIC programmer, there are an awfull
lot of different variations put out by microchip and there are
a variety of different times that have to be set up. That might
make the "standalone" programmer a little difficult.

Wouter might shed some light on this area. I looked at the open
source code from pp06 for my evaluation. Seems like there might
be a lot of table information that has to be sorted out.

Finally, there is the question of the chicken and the egg. I assume
that we are creating a PIC programmer for the newcomer. How is
he/she going to do the initial loading of the pic that goes in
the programmer? Or are we going to offer that service? Say like
a 16F648 preprogrammed for say $8-$10? Would we have to set
up an organization to do that or use something like DIY electronics
to front end this. And what about maintenace of the software when
Microchip comes up with a new flavor of PIC? All items we should
consider when starting up this effort.

One final note, if you would like, I could volunteer some of the
communication code that I've whomped up along with the hex record
processing for this effort. I'm sure that it will reduce the
required coding on the process.

Well, this is certianly more than two cents worth. I should have
shut up long ago.

I'm not trying to fan any flames, and I'm sorry if I bored you
or upset you with my thoughts.

Cheers,

Rich S. p.s. I am not affiliated with Delcom, Microchip, Intel, Microsoft
or any other company that was mentioned above. --- In , "Dave Mucha" <davemucha@j...> wrote:
> --- In , "Scott Lee" <midl_man@y...> wrote:
> > If you think it's hard to type while holding a 14 day old child
wait
> > until they are about 7 or 8 months old -- they actively try to
take
> > over the keyboard. My 8 month old son is actually harder to deal
> with
> > than my soon to be 4 year old daughter that just tries to kick me
> off
> > the computer so that she can use it. :)
> >
> > Congratulations! > Luckily, out 9 year old is on Mom's Mac, our 7 year old and her
fight
> over who gets to use it and neither uses their PC as the Mac is on
> the net. As far as my PC, only my cat uses that and he just walks
> on the keyboard...... >
> Dave




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

Re: PIC universal programmer - spec and design - end in sight ? - Dave Mucha - Apr 11 11:07:00 2004

--- In , "rj_satterlee" <rj_satterlee@y...>
wrote:
> All kidding aside (hello to the new fathers out there), I am finally
> going to add my two cents worth to this thread (with some
trepidation)
> I might add.
>
> I would like to bring some observations that I have to the subject.
>
> 1. I looked at a USB design for the PIC. I spent more than 10 hrs,
> and less than 100 hours looking at the USB 1.0 specs (easier)
> for low speed devices. I found that the packet was complex
> enough with enough CRC checksums in them, both CRC5 and CRC16
> to take up most of the PIC's time while processing a packet.
> And the speeds were high enough to require an external shift
> register to get the packet. The clock decode wasn't that bad,
> but doing the CRC5 and switching to the command phase was going
> to take awhile...... I think in the future, if I have to do
> a USB design, I'll look more closely at the Delcom products
>
> http://www.delcom-eng.com/products_USBIO.asp#USBIO
>
> to assist my microcontroller.
>
> 2. There is significant software required for the USB driver. In
> the delcom case, they supply some software for the interface.
>
> Therefore, I stuck to RS232 communications. In fact, although some
> machines might not have an RS232 port, you might consider buying
> an interface card for it.
>
> So, as mentioned, I stuck with RS232.
>
> I am building a design for the 28 pin ATMEL +5V EEPROM programmers.
> Now don't get excited. I've got the major functional blocks up and
> running, but there are a couple of things that I have to do. I will
> release it to the group when I've finished the enhancements and
> generate a EULA for it (I spent many many hours to make it and if
> you want to make money on it, I'd like a cut).
>
> This is an RS232 device that uses the common terminal programs
> available on Windoze and Linux (hyperterminal and minicom). And,
> I'm sure that there is a comparable application for the Mac World
> as well.
>
> I started off with a Perl script for the requirement and found that
> with just a little more effort I could move all the smarts to the
> PIC. I'm currently using a 16F77 for the project, but almost
> any PIC could be used for the PIC programmer. The 40 pin 'F77 was
> nice, there was enough I/O so all the outputs went to the EEPROM
> socket. I found that I could reliably transfer data from the PC
> to the PIC programmer at 19.2K baud by passing the hex format files
> directly to the PIC. This works out to about 1000 bytes of
> information being passed and indeed programming my 8kBytes of EEPROM
> takes 12-15 seconds. Not too bad. I'm pretty sure that the baud
> rate can be increased and I plan to up it to about 57Kbaud. In
> any event, reliable programming was accomplished. I did over 1500
> programming burns of the EEPROM without error while it was in the
> perl phase. > Finally, there is the question of the chicken and the egg. I assume
> that we are creating a PIC programmer for the newcomer. How is
> he/she going to do the initial loading of the pic that goes in
> the programmer? Or are we going to offer that service? Say like
> a 16F648 preprogrammed for say $8-$10? Would we have to set
> up an organization to do that or use something like DIY electronics
> to front end this. And what about maintenace of the software when
> Microchip comes up with a new flavor of PIC? All items we should
> consider when starting up this effort.
>
> One final note, if you would like, I could volunteer some of the
> communication code that I've whomped up along with the hex record
> processing for this effort. I'm sure that it will reduce the
> required coding on the process.
>
> Well, this is certianly more than two cents worth. I should have
> shut up long ago.
>
> I'm not trying to fan any flames, and I'm sorry if I bored you
> or upset you with my thoughts.
>
> Cheers,
>
> Rich S.

Hi Chris, this is very timely !

We have been discussing the idea of putting time into a project or if
in fact all the existing units are not useable.

I have this nagging doubt if the multitude of programmers are not
usable. I think many work fine for their intended purpose. But I do
understand that that ones like the jdr need to be specifically laid
our for one unit or one small family and a second for another unit or
small family. This is die to the fact that MicroChip does have
enough difference between products to make the be-all programmer a
pretty sophistocated project. (where is the yahoo spell checker?)

To that end, there is no reason that the newbie cannot make a 'chip
specific' jdr to program the 16F648 in your project. It could be a
one shot programmer on a breadboard or a built up unit.

Since I am gearing up to supply small kits, I am interested in your
EULA and I would considder selling both boards in the kit. Let them
cut their teeth on the simple kit before doing the more complex.

Dave


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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