Searching \ for 'Don McKenzie P16C84 programmer under NT4' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programmer
Search entire site for: 'Don McKenzie P16C84 programmer under NT4'.

Truncated match.
PICList Thread
'Don McKenzie P16C84 programmer under NT4'
1996\09\11@194001 by Adam Crow

flavicon
face
Okay folks, this programmer works well under DOS and Win95 etc. But can it work under Windows NT through the printer port? Methinks it might. Has anybody done this yet? NT 4 is excellent for software development, and I like the idea of using the programmer under NT at the same time as downloading PIC files off the net, and using my buggy Borland C++ 5.

1996\09\25@163931 by Alex I. Torres

flavicon
face
> Okay folks, this programmer works well under DOS and Win95
> etc. But can = it work under Windows NT through the printer
> port? Methinks it might. = Has anybody done this yet? NT 4
> is excellent for software development, = and I like the idea
> of using the programmer under NT at the same time as
> = downloading PIC files off the net, and using my buggy
> Borland C++ 5.


It's not possible to read/write hardware ports under NT directly!
The only way - to write special virtual driver.
If you have Microsoft Development Network (MSDN) Level 3 you can
see DDK and examples for writing drivers.
And the second big problem (problem under all multitasking
system) - how to do timedelays ? The best way is to have hardware
programmer (using its own CPU) attached to the COM port... :-)

---------------------------
  Best Wishes, Alex Torres.
  Kharkov, Ukraine, exUSSR.
  E-Mail To : spam_OUTaltorTakeThisOuTspamcook.kharkov.ua   via InterNet
              or 2:461/28             via FidoNet

----- GoldED 2.50.A0531+
* Semi-Production-Quality Programmer
* for 16Cxx,24xx,93xx - OK.
* 14000 - implemented but not tested.
* only $40 !
* no extranal power, MsDos & Windows Software.

1996\09\26@162224 by Lars Haven

flavicon
face
>
>  > Okay folks, this programmer works well under DOS and Win95
>  > etc. But can = it work under Windows NT through the printer
>  > port? Methinks it might. = Has anybody done this yet? NT 4
>  > is excellent for software development, = and I like the idea
>  > of using the programmer under NT at the same time as
>  > = downloading PIC files off the net, and using my buggy
>  > Borland C++ 5.
>
>
>  It's not possible to read/write hardware ports under NT directly!
>  The only way - to write special virtual driver.
>  If you have Microsoft Development Network (MSDN) Level 3 you can
> see DDK and examples for writing drivers.

It's not impossible. Check out the May 1996 issue of Dr.Dobb's Journal.
It has an article on how to perform direct port I/O with Windows NT.
The article describes a driver to allow user-level programs to access
selected ports. The sourcecode ought to be available at the DDJ ftp
site (ftp.mv.com, in /pub/ddj or http://www.ddj.com).

>  And the second big problem (problem under all multitasking
> system) - how to do timedelays ? The best way is to have hardware
> programmer (using its own CPU) attached to the COM port... :-)
>
It is true that timing may well be a problem, but I have seen a design
for a PIC programmer running on Linux, which also does multitasking.
That design was very much like other parallel port programmers, so it
might be worth a try.

The safe, but expensive bet is the serial programmer.

{Quote hidden}

--
Lars Haven  <lhavenspamKILLspammunin.ping.dk>
"You need tiny little eyes to read tiny litte print,
like you need tiny little hands for milking mice."


'Don McKenzie P16C84 programmer under NT4'
1996\10\06@002612 by Alex I. Torres
flavicon
face
>> And the second big problem (problem under all
>> multitasking system) - how to do timedelays ? The best way
>> is to have hardware programmer (using its own CPU)
>> attached to the COM port... :-)

>
> It is true that timing may well be a problem, but I have
> seen a design for a PIC programmer running on Linux, which
> also does multitasking. That design was very much like other
> parallel port programmers, so it might be worth a try.
>
> The safe, but expensive bet is the serial programmer.

Yes, and now I'm working with a new project: serial programmer
with PIC16C84 (54 ? :) on board, with LT3001 DC-DC converter (5->14)
that have only one 40-pin ZIF-socket and FULL PRODUCTION QUALITY
changing of Vdd and Vpp.
BTW, to my mind, chancging Vpp according Microchip's from 12 to
14v with 0.25v resolution is NOT nessesary!!! It seems to me than
set Vpp=13.5v is enough for all chips. And Vdd must variate from 2v
to 6v.
New project will work with all 2wire programmed PICs (including
PIC14000, PIC12C50x), all IIC (24Cxx) and Microwire (93Cxx) NVRAM.
Software for this design will be only for Windows, writen
in Borland Delphi 1.0.

  Best wishes, Alex Torres, .....altorKILLspamspam.....cook.kharkov.ua via Internet,
                            2:461/28 via FidoNet

1996\10\07@094715 by Martin J. Maney

flavicon
face
On Sat, 5 Oct 1996, Alex I. Torres wrote:

>  Yes, and now I'm working with a new project: serial programmer
> with PIC16C84 (54 ? :) on board, with LT3001 DC-DC converter (5->14)
> that have only one 40-pin ZIF-socket and FULL PRODUCTION QUALITY
> changing of Vdd and Vpp.
>  BTW, to my mind, chancging Vpp according Microchip's from 12 to
> 14v with 0.25v resolution is NOT nessesary!!! It seems to me than
> set Vpp=13.5v is enough for all chips. And Vdd must variate from 2v
> to 6v.

I've been puzzled by these recurring mentions about a need for varying
the Vpp, and your comments finally tipped the scales and caused me to go
over the programming specs in the 95/96 microcontroller data book.  I
found, as I had recalled, no mention of this silliness in the 16Cxx
section, which I was most familiar with; neither is there any mention
that I noticed in the 16C5x spec.  The 16C84 and 17Cxx specs have an
oddly worded "requirement" that the Vpp supply "have 0.25V resolution" in
their nearly identical paragraphs near the beginning, but the actual
programming specification clearly makes no demands on this
programmability of Vpp.  There are requirements on the actual voltage
level, both the familiar "12 to 14 volts" spec and one regarding the
minimum level Vpp must remain above Vdd in order to remain in programming
mode, but absolutely nothing about any need to vary this voltage during
programming.

Short form: in my considered opinion, as of the specs in the 95/96
databook, Microchip DOES NOT require any programmability for the Vpp
supply in the sense that Vdd needs to be programmable as part of the
specified program/verify procedure.

So why that weird spec?  Who knows!  I can see a couple of
possibilities.  Perhaps whoever was responsible for that wording
considers any voltage source that can be changed under the control of
some operator - in this case the programming program - as a "programmable
supply".  Call this the "PIC programmer as ATE" model, and assume the
0.25V requirement was just sloppily carried over to the Vpp supply in
that paragraph, even though there's no use for it.

Another possibility is more substantial: perhaps this is Microchip's way
of hinting that some future products may require more from Vpp than any
of the current (as of the 95/96 databook, at least) products.  This seems
pretty unlikely to me because that spec only calls for Vpp to be
"programmable" over the 12-14V range that matches the current spec.
Knowing at least enough about LSI design to hazard an occasional guess
like this <grin>, it seems unlikely that anything so different from
Microchip's current technologies as to need a more precise (and variable)
Vpp would nevertheless still use the same old 12-14V range.  Not
impossible, but I'd say it's at least a ten to one long shot.

There, that's my two cents of coffee-inspired thought.  :-)

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...