Searching \ for '[PIC] Comments on the EasyProg kit' 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=easyprog
Search entire site for: 'Comments on the EasyProg kit'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Comments on the EasyProg kit'
2005\10\08@175418 by John Nall

picon face
This is posted merely for the information of anyone, particularly
newbies, who might be thinking about building a PIC programmer from a
kit.  I have no ties of any sort with either Olin or Embed, Inc.

When I first started working with PIC's several years ago, I bought the
Wisp628 (already assembled) from Wouter.  However, I now needed a
programmer for the ds30F line, and the EasyProg promised to do that.  
(Wouter has promised also, but of course I have no way of knowing his
timeline. :-)

I bought the EasyProg kit with all the parts included -- I do not think
anyone would save money by buying the parts separately.  It comes with
no directions, but sufficient documentation can be downloaded from
Embedinc.com so that the parts list, together with the clearly-marked
circuit board, is enough for anyone who has built a few kits to easily
put it together.  (I would not recommend it for someone who has never
built a kit before, however -- some fairly precise soldering is required
and one has to spend a bit of time identifying some of the parts.  This
should not be your first kit, IMHO).

Once it was put together, which took an afternoon, it powered up with no
problem.  The checkout, as described in the downloaded documentation
went smoothly.  I don't think that the documentation is as complete as
the documentation that is available on the Wisp628, but that may be
because it is a much newer product.  The parts are good quality, the
circuit board is well-made and very well marked.

So those are my impression, for whatever value they may be.

John

2005\10\08@180722 by olin piclist

face picon face
John Nall wrote:
> I don't think that the documentation is as complete as
> the documentation that is available on the Wisp628,

What specifically did you feel was missing?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@182952 by John Nall

picon face
Olin Lathrop wrote:

> John Nall wrote:
>
>> I don't think that the documentation is as complete as
>> the documentation that is available on the Wisp628,
>
>
> What specifically did you feel was missing?

I certainly hope that my comments were not taken as being critical --
they were not intended that way.  I was referring primarily to little
things, such as, for example, in the "Operation" part of the EasyProg
User Guide, the user is told to use the command "doc pic_prog" to
display the documentation file for the PIC-PROG program.  This does not
work, at least not on Windows XP Home.  There is not documentation (as
far as I can tell, and I may have missed it) for using the EasyProg with
an in-circuit target (as opposed to the on-board ZIF socket), whereas
there are pictures and charts for showing how to do exactly that with
the Wisp628 for all the chips that it supports.  I can most likely
figure it out --a newbie might not be able to do so.

So it just depends on how much hand-holding you want the documentation
to do with inexperienced people who build the kit.  The documentation is
completely sufficient for experienced users -- that is beyond question.

And, again, no remarks were intended to be critical.  I like the
EasyProg, am glad that I bought it, and am looking forward to many years
of productive use.

John

2005\10\08@193244 by olin piclist

face picon face
John Nall wrote:
> I was referring primarily to little
> things, such as, for example, in the "Operation" part of the EasyProg
> User Guide, the user is told to use the command "doc pic_prog" to
> display the documentation file for the PIC-PROG program.  This does not
> work, at least not on Windows XP Home.

It should bring up a Notepad window displaying the documentation file.  What
does happen on your system?

> There is not documentation (as
> far as I can tell, and I may have missed it) for using the EasyProg with
> an in-circuit target (as opposed to the on-board ZIF socket),

Ah yes, that is missing.  I plan on a separate web page for that, since
there is a lot more to it than most people might think.  This is
particularly true for 30F targets.  Just connecting the various lines to a
bare chip at the other end of a standard cable won't work in most cases.
However none of this is unique to the EasyProg, which is probably why I
haven't gotten around to writing the ICSP web page yet.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\08@195358 by John Nall

picon face
Olin Lathrop wrote:

> John Nall wrote:
>
>> . . . the user is told to use the command "doc pic_prog" to
>> display the documentation file for the PIC-PROG program.  This does not
>> work, at least not on Windows XP Home.
>
>
> It should bring up a Notepad window displaying the documentation
> file.  What
> does happen on your system?

Well, that is a little bit strange, actually.  Going to the command
window and typing "doc" results in 10 error messages, each of which says
"copya is not recognized as an internal or external command, operable
program, or batch file."  Since this is not the usual behavior for
merely typing an incorrect command, I went to another computer and typed
"doc" and it just said (once) that "doc is not recognized . . .etc."  
From this, I surmise that perhaps install_picprg put a doc program on
my system, but that it perhaps has a problem.  Of course it is trivial
to get around, since all the .txt files are in c:\embed\doc, but
nevertheless . . .

{Quote hidden}

I do not doubt that, which does not make my comment any less true.  :-)  
If and when Wouter gets the new version of the Wispxxx out, his
documentation may have the same problem.  We shall see.

John


2005\10\08@205614 by Xiaofan Chen

face picon face
I think that the environmental variables are not set up properly in your system.

It is working as advertised in my system even though I never use the
doc command. It is easier to double click the txt file to bring up your
favorite editor like Notepad or Ultraedit.

%EMBEDINC% = c:\embedinc
%PATH% should contain C:\embedinc\com

There are some environmental variables not automatically set up
by the installation program. Please check out
C:\embedinc\doc\envvars.txt

Regards,
Xiaofan

On 10/9/05, John Nall <spam_OUTjwnallTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

2005\10\08@212404 by John Nall

picon face
Xiaofan Chen wrote:

>I think that the environmental variables are not set up properly in your system.  (etc etc).
>  
>
You are telling me how I can get around the problem.  I know several
ways to get around the problem. :-)   Olin asked me what deficiencies I
found in the documentation, and I told him.   Documentation should be
written assuming a user who does NOT know how to get around the
problem.  Or at least that is my view.  Others may differ.

John




2005\10\08@220050 by Xiaofan Chen

face picon face
Oh yes I agree with you here. The documentation is lacking
for Olin's development environment in general.

For EasyProg, I think there are several problems with the
website information and program documentations.

1) Troubleshooting guide if doc command or other commands
is not working (to set up the environmental variables right)
2) Discalimer that Window 98 is not supported by the batch files
3) Simple example on how to use pic_read and pic_prog
Eg.: pic_read -sio 2 -hex myreadout.hex
4) How to make the adapter for the 8/14/20 pin PICs? These PICs will
be more and more popular.
5) ICSP guide
6) ...

However Olin has put the disclaimer so all these may not be a real problem.
But I am not so sure if one put US$99+shipping for a EasyProg will feel it is
low price. This is especailly true after I compare the schematics of PICkit 2
and EasyProg. Of course PICkit 2 (US$35+shipment, shipment is not cheap
and I paid US$16 for the shipment to Singapore) has not reached its potential
yet and it does not support enough chips yet. Or at least this is just my view.
Others may differ.

>From EasyProg site:
"This product is not officially supported, which allows its price to be lower.
There is no support phone number or email address."

ProProg, on the other hand, may be a great deal if it can replace
Promate II/III in a production setup.

Regards,
Xiaofan

On 10/9/05, John Nall <.....jwnallKILLspamspam@spam@gmail.com> wrote:

> You are telling me how I can get around the problem.  I know several
> ways to get around the problem. :-)   Olin asked me what deficiencies I
> found in the documentation, and I told him.   Documentation should be
> written assuming a user who does NOT know how to get around the
> problem.  Or at least that is my view.  Others may differ.
>
> John
>

2005\10\09@041208 by Wouter van Ooijen

face picon face
> This is especailly true after I compare the
> schematics of PICkit 2
> and EasyProg. Of course PICkit 2 (US$35+shipment, shipment is
> not cheap
> and I paid US$16 for the shipment to Singapore) has not
> reached its potential
> yet and it does not support enough chips yet.

PICkit 2 is a problem for me as third-party programmer builder. The
hardware is very capable, as far as I can see it could replace the ICD2
and add off-line programming (it has the EEPROMs and the button). So if
and when Mirochip creates and releases the software that unlocks it full
potential the PICkit 2 can seriously change the market for lower-cost
($30 .. ) programmers. But as yet Microchip has not done this, so the
PICkit 2 is still a programmer that supports only a limited range of
PICs.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\09@065219 by Xiaofan Chen

face picon face
I guess that EasyProg (in its lower price format) and Wisp628 are
still competitve now. PICkit 2 will not support much chips until
the end of the year and it will not support dsPIC until next year
unless some people work on the firmware side and get ahead
of Microchip's schedule.

EasyProg supports dsPICs (its strong point and I will say it is the only
reason to buy assembled EasyProg to be frank) and support 2 pass verify
(not very useful for hobbyists IMHO).

Wisp628 supports large number of PIC16F/18F, especially after Rob
released version 1.10 of Wisp628 firmware and xwisp2 1.8.0. Wisp628 is
cross-platform and it is really very easy to be built especailly if one
buys the PCB from Wouter.

There will still be quite some programmer around after PICKit 2 and
it is always good to have more choices. JDM and Tait seem to be
alive forever. In the higher end, Kit 185 seems interesting. There
are also a lot of ICD2 and PS+ clones available from various sources.

Regards,
Xiaofan


**********************************************************
From: Rob Hamerling
Reply-To: gnupicspamKILLspamlinuxhacker.org
To: .....gnupicKILLspamspam.....linuxhacker.org
Date: Oct 9, 2005 6:12 PM
Subject: [gnupic] [AD]Xwisp2 1.8.0 released
Reply | Reply to all | Forward | Print | Add sender to Contacts list |
Trash this message | Report phishing | Show original | Message text
garbled?

Xwisp2 version 1.8.0 is released, see my site, URL below.

New in this version:
1. Support for PIC16F91x/946 and a large group of newer PIC18Fs, among
others those with USB support (see DS39622F).
2. For the newly supported PICS a new version of Wisp628 firmware is
required (and provided with the new Xwisp2). Firmware version 1.10 is a
modified version of 1.09 supplied by me, not by Wouter van Ooijen.  It
must be considered as a temporary solution!
3. Due to memory contraints of the 16F628(A) the support for Passthrough
had to be removed and the Pass command is not supported by Xwisp2 when
Wisp628 firmware version 1.10 is detected.
4. A number of corrections in Xwisp2.cfg.
5. Xwisp2.cfg contains now also the datasheet number of the programming
specifications for each PIC, just for reference.

Note: Xwisp2 1.8.0 still supports older Wisp628 firmware versions, but
the level of support for the newer PICs is very limited!

Regards, Rob.

2005\10\09@071252 by Rob Hamerling

flavicon
face


Xiaofan Chen wrote:

> Wisp628 supports large number of PIC16F/18F, especially after Rob
> released version 1.10 of Wisp628 firmware and xwisp2 1.8.0.  Wisp628 is
> cross-platform and it is really very easy to be built especailly if one
> buys the PCB from Wouter.

I just announced Xwisp2 1.8.0 (and wisp628 firmware 1.10) in the gnupic
and pickit lists. See there or on my site for more info.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\10\09@103248 by olin piclist

face picon face
John Nall wrote:
> Well, that is a little bit strange, actually.  Going to the command
> window and typing "doc" results in 10 error messages, each of which
> says "copya is not recognized as an internal or external command,
> operable program, or batch file."

That means you don't have the COPYA program.  This was a bug in the release
scripts and has now been fixed.  Download the latest from
http://www.embedinc.com/picprg/sw.htm and the DOC command should now work.

This release also fixes the problem reported by Jim yesterday where EEPROM
data was only written to even addresses in the HEX file.  This turned out to
be a bug in PIC_READ for the 18F2520 and the other 31 PICs with the same
programming algorithm.  Other 18F parts like the 18F252 and 18F6520 were
read correctly.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\09@105407 by olin piclist

face picon face
Xiaofan Chen wrote:
> 2) Discalimer that Window 98 is not supported by the batch files

Huh?  While most of the criticisms on this thread have been valid and
useful, I have to disagree with this one.

On the page where you download the software from
(http://www.embedinc.com/picprg/sw.htm) there it tells you near the top to
read the installation directions.  There is even an ominous note to catch
people who might be inclined to skip this: "This is particularly important
for Windows 9x users.  Failure to follow the directions may result in system
corruption and loss of data.".  When you follow the link to the directions
to http://www.embedinc.com/swdload.htm it lists the supported operating
systems as Windows NT 4, Windows 2000, and Windows XP.  Note that Windows 9x
is not listed.  To make this point even more clear, the section immediately
below that titled "Special note for Win9x Users" starts out "The Win9x
operating systems (Windows 95, 98, and ME) are obsolete relics of a bygone
era, and we have no intention of supporting them.".  The next paragraph
states in bold letters "None of the software found on this web site is
intended for, supported on, or recommended for any of the Windows 9x
operating system.".

Back at the downloads page for the development software release it says in a
paragraph all by itself "The build scripts do not work on Windows 9x
systems.".

> 4) How to make the adapter for the 8/14/20 pin PICs? These PICs will
> be more and more popular.
> 5) ICSP guide

I agree this is needed, and is something I'm working on.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\09@115130 by John Nall

picon face
Olin Lathrop wrote:

>> . . .  most of the criticisms on this thread have been valid and
>useful . . .
>  
>
I prefer to think of them as being constructive comments.  :-)

John


2005\10\09@221646 by Chen Xiao Fan

face
flavicon
face
Okay I agree with you that you have put enough disclaimers.

However I think pic_read and pic_prog are really working on
Windows 98SE as fas as I know (I tested some old versions
last time). The only not working part is the batch files
like doc.bat which is not strictly necessary. The only
extra work is a simple documentation/README file.

Yes I know Windows 98SE is old but people are still using it.
There are plenty old PCs which do not run XP very well.
There are plenty of people who do not want to upgrade their
OSes to Windows XP because it costs more than US$100.

My point is that EasyProg itself works with Windows98SE.
Simply unzip the installation package to C:\embedinc
will get the programmer part working. Only the batch
files are not working.

Regards,
Xiaofan

{Original Message removed}

2005\10\10@033640 by Robert A LaBudde

flavicon
face
I have just bought and built an EasyProg kit from EmbedInc.

It worked perfectly at start-up.

The software is a little cumbersome in Windows (I have Win2000 SP6), as it
is command lines only, with no user interface at all. Some means of setting
a default directory for hex files would be invaluable, as otherwise the
program expects the hex files to be near enough to the program binaries for
the user to type the full path onto the command line. Perhaps and
"EasyProg.INI" file?

The hardware documentation contains an error: The parts list calls out C16
as a 1 uF capacitor, but the silkscreen shows a much larger electrolytic.
The kit includes both a 1 uF capacitor and a surplus 1000 uF capacitor. C16
is the filter capacitor of the 7805 regulator fed by 15 VAC through a diode
bridge, so I installed the large capacitor instead of the 1 uF one called
out in the parts list and schematic. That left the 1 uF capacitor unused
and surplus.

For some reason Olin made the sizes of all resistors and diodes 0.3"
instead of 0.4", so all leads had to be bend close to the bodies to fit the
holes. This made assembly slow, as each bend had to be made individually
with pliers instead of with a bending jig (which starts at 0.4" width).

The location of the parts on the board were in somewhat random order
instead of the usual numerical order, so stuffing had to proceed in
somewhat a "hunt-and-stuff" methodology.

The software operation was quite nice, and I appreciated the professional
touch of testing at the worst-case power values (2.0 V and 5.5 V for the
16F716 chip I programmed).
================================================================
Robert A. LaBudde, PhD, PAS, Dpl. ACAFS  e-mail: EraseMEralspam_OUTspamTakeThisOuTlcfltd.com
Least Cost Formulations, Ltd.            URL: http://lcfltd.com/
824 Timberlake Drive                     Tel: 757-467-0954
Virginia Beach, VA 23464-3239            Fax: 757-467-2947

"Vere scire est per causas scire"
================================================================

2005\10\10@035304 by Jim Robertson

flavicon
face

>The software operation was quite nice, and I appreciated the
>professional touch of testing at the worst-case power values (2.0 V
>and 5.5 V for the 16F716 chip I programmed).

This is not actually required as part of the programming
specification for this part. There is no distinction between
production and development programmer for this PIC as is indeed the
case for many Flash PICs.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS


_______________________________________
Home of the famous WARP-13 PIC programmer.
NEWFOUND ELECTRONICS P/L
http://www.newfoundelectronics.com
_______________________________________

2005\10\10@042436 by Wouter van Ooijen

face picon face
> This is not actually required as part of the programming
> specification for this part. There is no distinction between
> production and development programmer for this PIC as is indeed the
> case for many Flash PICs.

Is there a (Mircochip) reference for this?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@055040 by Jim Robertson

flavicon
face

>>
>>
>>This is not actually required as part of the programming
>> > specification for this part. There is no distinction between
>> > production and development programmer for this PIC as is indeed the
>> > case for many Flash PICs.
>
>
>
>Is there a (Mircochip) reference for this?
>
>Wouter van Ooijen

Ok, if you really need me to be more specific, it's call the "FLASH
Memory Programming Specification."

Regards,

Jim



2005\10\10@060441 by Lee Jones

flavicon
face
> bought and built an EasyProg kit from EmbedInc.
>
> The software is a little cumbersome in Windows (I have Win2000 SP6),
> as it is command lines only, with no user interface at all.

No user interface???  A command line interface (CLI) _is_ a user
interface.  It's not a graphic user interface (GUI) but some, such
as myself, actually prefer the command line.

                                               Lee Jones

2005\10\10@082714 by John Nall

picon face
Robert A LaBudde wrote:

>
> > The hardware documentation contains an error: The parts list calls
> out C16 as a 1 uF capacitor, but the silkscreen shows a much larger
> electrolytic. The kit includes both a 1 uF capacitor and a surplus
> 1000 uF capacitor. C16 is the filter capacitor of the 7805 regulator
> fed by 15 VAC through a diode bridge, so I installed the large
> capacitor instead of the 1 uF one called out in the parts list and
> schematic. That left the 1 uF capacitor unused and surplus.

Yeah, I thought about mentioning that in my little write-up, but decided
not to.  I had contacted Olin about it directly, and he explained that
they had by error put the 1 uf in there, and that rather than go in and
fish it out he just added the correct one without taking out the other
one.  The documentation clearly says 1000 uf (it actually says 1 mf, but
same difference) and the board, as you say, shows the large one.  So I
figured that it was not worth mentioning.  Just a judgment call.

>
>
> > For some reason Olin made the sizes of all resistors and diodes 0.3"
> instead of 0.4", so all leads had to be bend close to the bodies to
> fit the holes. This made assembly slow, as each bend had to be made
> individually with pliers instead of with a bending jig (which starts
> at 0.4" width).

Yeah, I agree.

>
> > The location of the parts on the board were in somewhat random order
> instead of the usual numerical order, so stuffing had to proceed in
> somewhat a "hunt-and-stuff" methodology.

I agree.  One thing you didn't mention, and I didn't either, is that
"Q4" looks very much like "Q1" on the board, and since they are not in
order I had to resort to the schematic to make sure on that one
(although "Q1" itself is very clear on the board, so it was just a
double-check to look at the schematic).

John

2005\10\10@083051 by John Nall

picon face
Lee Jones wrote:

>> No user interface???  A command line interface (CLI) _is_ a user
>interface.  It's not a graphic user interface (GUI) but some, such
>as myself, actually prefer the command line.
>  
>
Not just some -- a LOT of people actually prefer the command line
(IMHO).  :-)  Of course, that is probably because we grew up with it,
and future generations will look upon CLI as some sort of relic and
wonder why it is even there.

John

2005\10\10@094607 by olin piclist

face picon face
Robert A LaBudde wrote:
> The hardware documentation contains an error: The parts list calls out
> C16 as a 1 uF capacitor,

No, it calls for a 1mF capacitor.

> The kit includes both a 1 uF capacitor and a surplus 1000
> uF capacitor. C16 is the filter capacitor of the 7805 regulator fed by
> 15 VAC through a diode bridge, so I installed the large capacitor
> instead of the 1 uF one called out in the parts list and schematic.

I just checked the schematic, and it shows the value as 1mF also, so I'm not
sure where you're getting this from.  Did you download the latest version
(although I don't remember a version that had that error)?

In any case, you did the right thing.  The folks putting the kit together
screwed up and included the wrong capacitor for C16.  To fix this they added
the correct capacitor.  It would have cost more to fish out the wrong one
than just leave it in there.

> For some reason Olin made the sizes of all resistors and diodes 0.3"
> instead of 0.4", so all leads had to be bend close to the bodies to fit
> the holes. This made assembly slow, as each bend had to be made
> individually with pliers instead of with a bending jig (which starts at
> 0.4" width).

I always use .3" for these since it takes up less space.  I just bend each
lead right at the end of the part with my fingers.  I've always found that
easy, and it comes out really close to .3".

> The location of the parts on the board were in somewhat random order
> instead of the usual numerical order, so stuffing had to proceed in
> somewhat a "hunt-and-stuff" methodology.

The parts are numbered in schematic order, which is more customary than
board order.  However that's why I included the part index.  It gives the
schematic and board location of every part.  The board drawing has a
coordinate grid that matches the coordinates used in the part index.

All in all it sounds like there should be an assembly tips document.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@095512 by olin piclist

face picon face
Jim Robertson wrote:
> Ok, if you really need me to be more specific, it's call the "FLASH
> Memory Programming Specification."

But I know I've seen the description of "prototype" versus "production"
programmer in some F series programming specifications.  This is what
prompted me to design my programmers with variable Vdd and the software to
do two verification passes in the first place.  Maybe this is not needed for
newer F PICs, but there are apparently some F parts out there where this
matters.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@100405 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> Robert A LaBudde wrote:
> > The hardware documentation contains an error: The parts
> > list calls out C16 as a 1 uF capacitor,
>
> No, it calls for a 1mF capacitor.
>
> The folks putting the kit together screwed up and
> included the wrong capacitor for C16...

And *why* did they do that ?
Could it be becuse very few calls a 1000 uF cap "1mF" ??
A quite understandable "screw up", IMHO.

> I always use .3" for these since it takes up less space.

Do you use that "design rule" on *any* product ?

> I just bend each lead right at the end of the part with my fingers.

So do I, but even then, I have to press them in place.
And, normaly you should leave a small clearance between
the epoxy coating and the "bend" so you don't get cracks
in the coating. That design wouldn't be OK in e.g. telecom
equipment (my background). Now, I guess it's OK on
*this* board. :-)

Jan-Erik.



2005\10\10@100914 by olin piclist

face picon face
John Nall wrote:
> Not just some -- a LOT of people actually prefer the command line
> (IMHO).  :-)  Of course, that is probably because we grew up with it,
> and future generations will look upon CLI as some sort of relic and
> wonder why it is even there.

Two other advantages of command line user interfaces:

1 - They are a *lot* easier to write.

2 - They are scriptable.  For example when developing a PIC project I often
have a BAT file that builds the project and programs the PIC automatically
if the build succeeded.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@101220 by olin piclist

face picon face
John Nall wrote:
> I agree.  One thing you didn't mention, and I didn't either, is that
> "Q4" looks very much like "Q1" on the board, and since they are not in
> order I had to resort to the schematic to make sure on that one
> (although "Q1" itself is very clear on the board, so it was just a
> double-check to look at the schematic).

That was a screwup on my part.  The 4 ended up with a via under it.
Normally I go thru the silkscreen carefully after routing and move things
around so the text doesn't get chopped up by vias.  I have no explanation
why that and a few others got missed.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@102921 by Dave Tweed

face
flavicon
face
Robert A LaBudde <ralspamspam_OUTlcfltd.com> wrote:
> The software is a little cumbersome in Windows (I have Win2000 SP6), as
> it is command lines only, with no user interface at all. Some means of
> setting a default directory for hex files would be invaluable, as
> otherwise the program expects the hex files to be near enough to the
> program binaries for the user to type the full path onto the command
> line. Perhaps and "EasyProg.INI" file?

And you call yourself a programmer??? (only half :-)

The beauty of a command-line user interface (not NO user interface) is
that it is by far the easiest to extend. Depending on what kind of shell
you use, you can write a script or batch file to add whatever bells and
whistles you like. You can add a path in front of the hex file name, and
this can be hard-coded, pulled out of an environment variable, or even
read from an .INI file.

-- Dave Tweed

2005\10\10@103540 by Xiaofan Chen

face picon face
I think console program is okay as long asat least one of the
following options ( --help or -help or /h or /help) is provided.

I guess a newbie will be very scared after he issues the following
command. He will be even scared after issuing "doc pic_read"
does not tell him to use "pic_read -sio 2 -hex myhex.hex".

Hope this is considered as constructive criticisms. To be
honest, the programs are quite robust but it is not really
very user friendly.

Regards,
Xiaofan

C:\embedinc\com>pic_read
No response was received from the programmer.  The programmer may be powered
off or not connected to COM1.
Error occurred on attempt to open a new use of the PICPRG library.
*** Program aborted on error. ***

C:\embedinc\com>pic_read --help
Unrecognized command line option "--help" encountered.
*** Program aborted on error. ***

C:\embedinc\com>pic_read -h
Unrecognized command line option "-h" encountered.
*** Program aborted on error. ***

C:\embedinc\com>pic_read/h
No response was received from the programmer.  The programmer may be powered
off or not connected to COM1.
Error occurred on attempt to open a new use of the PICPRG library.
*** Program aborted on error. ***

On 10/10/05, Olin Lathrop <@spam@olin_piclistKILLspamspamembedinc.com> wrote:
>
> Two other advantages of command line user interfaces:
>
> 1 - They are a *lot* easier to write.
>
> 2 - They are scriptable.  For example when developing a PIC project I often
> have a BAT file that builds the project and programs the PIC automatically
> if the build succeeded.

2005\10\10@103732 by Wouter van Ooijen

face picon face
> Two other advantages of command line user interfaces:
> 1 - They are a *lot* easier to write.

and to document!

> 2 - They are scriptable.

When I have the choice between only a GUI and only a CLI my choice is
clear. I want to be able to script my work, even if that means a little
more work upfront.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@103741 by Wouter van Ooijen

face picon face
> > For some reason Olin made the sizes of all resistors and diodes 0.3"
> > instead of 0.4", so all leads had to be bend close to the
> bodies to fit
> > the holes. This made assembly slow, as each bend had to be made
> > individually with pliers instead of with a bending jig
> (which starts at
> > 0.4" width).
>
> I always use .3" for these since it takes up less space.

Note that the Wisp628 PCB does the same. To save PCB area, and also
because most kit builders are more likely to have the resistor and their
fingers available than a bending jig.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@104901 by Xiaofan Chen

face picon face
Yes command line user interface is good to power users.

However for average Joe users under Windows, a GUI
seems to be a better option. The new generation
does not go through the days of the DOS or other
terminal sessions.

Regards,
Xiaofan

On 10/10/05, Wouter van Ooijen <KILLspamwouterKILLspamspamvoti.nl> wrote:
{Quote hidden}

2005\10\10@105545 by John Nall

picon face
Xiaofan Chen wrote:

>I think console program is okay as long asat least one of the
>following options ( --help or -help or /h or /help) is provided.
>
>I guess a newbie will be very scared after he issues the following
>command. He will be even scared after issuing "doc pic_read"
>does not tell him to use "pic_read -sio 2 -hex myhex.hex".
>  
>
That would seem to me to depend on what level of skill you assume your
user has.  (The issue of what a manual should be, falls into the same
category).  To me, someone who is going to get into PIC programming (in
both senses of the word "program") can rightfully be expected to have a
skill level quite a bit above the average computer user.   If they
don't, then they have interesting times ahead, IMHO.  :-)   There will
be exceptions to that, but documentation should be written for the
expected user, not for the exceptions.

John

2005\10\10@105752 by John Nall

picon face
Xiaofan Chen wrote:

>> However for average Joe users under Windows, a GUI
>seems to be a better option. The new generation
>does not go through the days of the DOS or other
>terminal sessions.
>  
>
I disagree.  It might be an easier option, but  that does not make it a
better option.

John

2005\10\10@111711 by Jim Robertson

flavicon
face

>>Ok, if you really need me to be more specific, it's call the "FLASH
>>Memory Programming Specification."
>
>But I know I've seen the description of "prototype" versus "production"
>programmer in some F series programming specifications.  This is what
>prompted me to design my programmers with variable Vdd and the software to
>do two verification passes in the first place.  Maybe this is not needed for
>newer F PICs, but there are apparently some F parts out there where this
>matters.

Sure. The 16F62x[A], 16F83,84, 16F72,73,74,76,77, 16F7x7, 16F87x
all specify the requirement for programmable Vdd AND Vpp.
(While this looks a long list it actually leaves many Flash PICs out
of the programmable Vdd specification.)

But anyway, up front I am not, was not, trying to refute any of your
claims of production standard. Yes they are mostly valid in the
context of what microchip specify on some programming specifications.
(Not withstanding the lack of variable Vpp on your proggers, it doesn't
have any practical value as far as what "production standard" is/was
understood to mean.)

The case I was replying to related to the 16F716 and the programming
specification for this PIC does not mention production verses development
standard or specify two verify passes.

My post was a "FYI" for the OP only.

The discussion on production standard, its value and what chips it applies
too is a long discussion and I'm not about to start it, not today anyway. The
information supplied by microchip is just too confused and confusing.

Regards,

Jim

2005\10\10@113931 by Alan B. Pearce

face picon face
>>I guess a newbie will be very scared after he issues
>>the following command. He will be even scared after
>>issuing "doc pic_read" does not tell him to use
>>"pic_read -sio 2 -hex myhex.hex".
> >
>>
>That would seem to me to depend on what level of skill
>you assume your user has.  (The issue of what a manual
>should be, falls into the same category).  To me,
>someone who is going to get into PIC programming (in
>both senses of the word "program") can rightfully be
>expected to have a skill level quite a bit above the
>average computer user.   If they don't, then they have
>interesting times ahead, IMHO.  :-)   There will be
>exceptions to that, but documentation should be written
>for the expected user, not for the exceptions.

And for my money, the expected user is someone who may spend a month or
three doing useful work with the thing, and then leave it alone long enough
to forget all the cryptic Unix style command line switches.

Having a command line interface is all well and good, but having a GUI front
end that then drives the command line unit - MPLAB style - where there are
check boxes, radio buttons and input fields for setting options for
occasional users is a "good way to go" and gives the best of both worlds.
Sure it is possible to have batch files that do essentially the same thing,
but one may still need to go back to the manual to get a verbose explanation
(depending how good the help is) but it is a lot easier for a low end user
to see the verbose description on a GUI.

Don't get me wrong, I'm not suggesting Olin has to provide a GUI. I am sure
that someone will set to with some VB, Delphi, .net, or even (perish the
thought) QBasic* to come up with one at some stage to make it easier to
use - from their perspective, and in the process learn a lot about
programming something other than a micro.

* - yeah I know QBasic isn't technically going to provide a GUI, but it may
well provide an interface that some may find easier to use than a command
line with lots of switches whose syntax you can never remember (now does
this program use -, --, /, \, or something else as the switch - what are the
mutually exclusive items, which order do they have to be in, where is that
*&^%$£" manual?).

2005\10\10@115811 by Wouter van Ooijen

face picon face
> Yes command line user interface is good to power users.
>
> However for average Joe users under Windows, a GUI
> seems to be a better option. The new generation
> does not go through the days of the DOS or other
> terminal sessions.

probably. but I am not sure it is smart to target a product at Joe
users, they are the crowd that accounts for 90% of the questions asked
:(

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@121129 by Mark Rages

face picon face
On 10/10/05, Dave Tweed <RemoveMEpicTakeThisOuTspamdtweed.com> wrote:
> Robert A LaBudde <spamBeGoneralspamBeGonespamlcfltd.com> wrote:
> > The software is a little cumbersome in Windows (I have Win2000 SP6), as
> > it is command lines only, with no user interface at all. Some means of
> > setting a default directory for hex files would be invaluable, as
> > otherwise the program expects the hex files to be near enough to the
> > program binaries for the user to type the full path onto the command
> > line. Perhaps and "EasyProg.INI" file?
>
> And you call yourself a programmer??? (only half :-)
>
> The beauty of a command-line user interface (not NO user interface) is
> that it is by far the easiest to extend. Depending on what kind of shell
> you use, you can write a script or batch file to add whatever bells and
> whistles you like. You can add a path in front of the hex file name, and
> this can be hard-coded, pulled out of an environment variable, or even
> read from an .INI file.
>
> -- Dave Tweed

I always hated the command-line until I saw it done right, in a Unix system.

The windows command-line shell is really weak, but MS is supposed to
upgrade this in Vista.  If they don't toss it like all the other
features Vista was supposed to have.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\10\10@122623 by Josh Koffman

face picon face
Actually, I thought it had already been tossed? I believe the new
shell is called Monad.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On 10/10/05, Mark Rages <TakeThisOuTmarkragesEraseMEspamspam_OUTgmail.com> wrote:
> I always hated the command-line until I saw it done right, in a Unix system.
>
> The windows command-line shell is really weak, but MS is supposed to
> upgrade this in Vista.  If they don't toss it like all the other
> features Vista was supposed to have.

2005\10\10@132149 by Wouter van Ooijen

face picon face
> I always hated the command-line until I saw it done right, in
> a Unix system.

I think it is VMS that did the command-line interface right. After a
5-year break from VMS my fingers still remembered all command
variations.

What Unix did right was IO redirection and the pipe. Doing that was a
pain on VMS.

Note that on DOS or Windows/Cmd you (as program author) are in no way
restricted to the Microsoft command-line style (wich seems to be a
clever mix of the few things that were bad in VMS/CLI, with a large but
inconsisted influx from unix).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@135754 by William Chops Westfield

face picon face
On Oct 10, 2005, at 9:11 AM, Mark Rages wrote:
>
> I always hated the command-line until I saw it done right,
> in a Unix system.
>
Surely you're kidding?  There may be some unix programs with reasonable
commands lines, but the average "I ran out of letters that made sense,
so I started using random uppercase letters instead" application is
really awful.  For a more useful CLI, try VMS, or tops20, or even
cisco's IOS cli.  Context sensitive help is a good idea!

BillW

2005\10\10@141028 by Mark Rages

face picon face
On 10/10/05, William Chops Westfield <RemoveMEwestfwspamTakeThisOuTmac.com> wrote:
> On Oct 10, 2005, at 9:11 AM, Mark Rages wrote:
> >
> > I always hated the command-line until I saw it done right,
> > in a Unix system.
> >
> Surely you're kidding?  There may be some unix programs with reasonable
> commands lines, but the average "I ran out of letters that made sense,
> so I started using random uppercase letters instead" application is
> really awful.  For a more useful CLI, try VMS, or tops20, or even
> cisco's IOS cli.  Context sensitive help is a good idea!
>
> BillW

Actually, I like the GNU tools command line system.  Proprietary Unix
tools are not as user-friendly, it's true.

But I was also referring to pipes and redirection, and a shell
powerful enough to write programs in.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\10\10@141524 by Jan-Erik Soderholm

face picon face
Mark Rages wrote :

> But I was also referring to pipes and redirection, and a shell
> powerful enough to write programs in.

So you *are* talking about VMS then.
Fine.

Jan-Erik.



2005\10\10@164328 by olin piclist

face picon face
Xiaofan Chen wrote:
> He will be even scared after issuing "doc pic_read"
> does not tell him to use "pic_read -sio 2 -hex myhex.hex".

How doesn't it?  The -SIO and -HEX command line options are documented in
addition to -PIC.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@173508 by Peter

picon face


On Mon, 10 Oct 2005, Wouter van Ooijen wrote:

>> Two other advantages of command line user interfaces:
>> 1 - They are a *lot* easier to write.
>
> and to document!

Deja vu: *nix commands with 3 or 4 letters and 300+page manuals.

>> 2 - They are scriptable.
>
> When I have the choice between only a GUI and only a CLI my choice is
> clear. I want to be able to script my work, even if that means a little
> more work upfront.

Agree but eventually it has to be easy to use. Whether by templates
provided or by simple gui that drives the scripts (tcl/tk is excellent
for this and almost always my choice).

Peter

2005\10\10@175757 by Wouter van Ooijen

face picon face
> Agree but eventually it has to be easy to use. Whether by templates
> provided or by simple gui that drives the scripts (tcl/tk is
> excellent
> for this and almost always my choice).

Easy to use for me means that I can tweak what I want to happpen, and I
can combine that with other things that must be done. For instance, when
I generate my website:
- cvs checkout
- compile
- zip
- installation .exe generation
- etc etc
- finally ftp

I can't use enything here that has no command line.

I don't want to be involved in running this, except the first time. I
don't care how it is started, double-click on a .bat file is GUI enough
for me.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\10\10@183119 by Robert A LaBudde
flavicon
face
At 06:12 AM 10/10/2005, Lee wrote:
> > bought and built an EasyProg kit from EmbedInc.
> >
> > The software is a little cumbersome in Windows (I have Win2000 SP6),
> > as it is command lines only, with no user interface at all.
>
>No user interface???  A command line interface (CLI) _is_ a user
>interface.  It's not a graphic user interface (GUI) but some, such
>as myself, actually prefer the command line.

Technically it is an "interface", as some information is passed, albeit
one-time-only and "fire and forget it".

I should have said "interactive user interface" to satisfy the punctilious.

Even console programs can have interaction via prompts or menus.

================================================================
Robert A. LaBudde, PhD, PAS, Dpl. ACAFS  e-mail: ralEraseMEspam.....lcfltd.com
Least Cost Formulations, Ltd.            URL: http://lcfltd.com/
824 Timberlake Drive                     Tel: 757-467-0954
Virginia Beach, VA 23464-3239            Fax: 757-467-2947

"Vere scire est per causas scire"
================================================================

2005\10\10@184911 by Robert A LaBudde

flavicon
face
At 08:27 AM 10/10/2005, John wrote:
>> > The hardware documentation contains an error: The parts list calls out
>> C16 as a 1 uF capacitor, but the silkscreen shows a much larger
>Yeah, I thought about mentioning that in my little write-up, but decided
>not to.  I had contacted Olin about it directly, and he explained that
>they had by error put the 1 uf in there, and that rather than go in and
>fish it out he just added the correct one without taking out the other
>one.  The documentation clearly says 1000 uf (it actually says 1 mf, but
>same difference) and the board, as you say, shows the large one.  So I
>figured that it was not worth mentioning.  Just a judgment call.

I didn't notice the "1 mF", just read it as "1 uF". In the USA, "mF" and
"nF" are not commonly used.

>> > The location of the parts on the board were in somewhat random order
>> instead of the usual numerical order, so stuffing had to proceed in
>> somewhat a "hunt-and-stuff" methodology.
>
>I agree.  One thing you didn't mention, and I didn't either, is that "Q4"
>looks very much like "Q1" on the board, and since they are not in order I
>had to resort to the schematic to make sure on that one (although "Q1"
>itself is very clear on the board, so it was just a double-check to look
>at the schematic).

I was too embarrassed to do so: I first stuffed a 2N4403 into what I
thought was the Q1 holes next to Q2. Instead it was Q4. I found the error
later via the "hunt-and-stuff" methodology, where I ran across the Q1
position. A magnifying glass confirmed the error and the transistor was moved.

My eyes aren't want they used to be. I checked each resistor with an
ohmmeter. I read each capacitor and transistor with a magnifier. I don't
solder any of a type of component until all are stuffed, so I don't run
across a more permanent problem of the type above.

Thanks, John, for the comments as a fellow veteran of the assembly "trenches".

As for the command-line-only non-interactive interface, I have tested and
found that the EasyProg software will work fine in other folders, so long
as the EasyProg "com" folder is included in the path. This allows local use
so the program hex file does not need to be relocated, or the complete path
given. It also means a GUI interface manager could be written in VB6, say,
(or QBASIC for those of you who love the days of yesteryears), which could
keep track of previous choices of programs and devices and then invoke the
EasyProg software. This would be livable.

================================================================
Robert A. LaBudde, PhD, PAS, Dpl. ACAFS  e-mail: EraseMEralspamlcfltd.com
Least Cost Formulations, Ltd.            URL: http://lcfltd.com/
824 Timberlake Drive                     Tel: 757-467-0954
Virginia Beach, VA 23464-3239            Fax: 757-467-2947

"Vere scire est per causas scire"
================================================================

2005\10\10@200138 by Chen Xiao Fan

face
flavicon
face
However the average Joe users make Microsoft a very rich
and powerful company.

If you do not want to support the Joe users and thus do not
want to earn money from them, that is perfect okay. ;-)
They are the one who want to pay for assembled PIC programmers
(or other product) for the sake of convenience. The power
users (who knows more) will often compare the price/performance
and often too picky to buy anything. ;-) And the very
powerful users will think all PIC programmers are overrated. ;-)
*hardware PIC programmers*, of course.

Regards,
Xiaofan

{Original Message removed}

2005\10\10@200505 by Chen Xiao Fan

face
flavicon
face
I have the luck of using MicroVAX with VMS and a VAX running Ultrix
in the early 90s. I think Digital Ultrix is much better than VMS.
Then I used Open VMS and Sun Solaris in 1997 and again I think
Solaris (Sun's Unix) is much better than open VMS.

Regards,
Xiaofan


{Original Message removed}

2005\10\10@200828 by Chen Xiao Fan

face
flavicon
face
Yes this the problem with the pic_read and pic_prog.
Simplicity is good but over-simplicity is bad design.
At least some simple help screen should be provided.
xwisp2 for Wisp628 is much better in this aspect.

Regards,
Xiaofan

{Original Message removed}

2005\10\10@201836 by Chen Xiao Fan

face
flavicon
face
Yes but one extra line will not boost the software package
by 100Meg. Look at the Unix man page, lots of them are
quite terse but at least they provide an example. In the
case of pic_read it is still okay. In the case of
pic_prog, it is really much better to put some
help screen and some examples. I am not a usability
expert but I think this is common sense or at least
common expectation.

Anyway this is a minor problem. The problem it that no
help screen is provided. Why not put an --help
option which tell the Joe user to use -sio and -hex
and other options?

Regards,
Xiaofan

Example:

C:\>copy /?
Copies one or more files to another location.

COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B]
    [+ source [/A | /B] [+ ...]] [destination [/A | /B]]

 source       Specifies the file or files to be copied.
 /A           Indicates an ASCII text file.
 /B           Indicates a binary file.
 /D           Allow the destination file to be created decrypted
 destination  Specifies the directory and/or filename for the new file(s).
 /V           Verifies that new files are written correctly.
 /N           Uses short filename, if available, when copying a file with a
              non-8dot3 name.
 /Y           Suppresses prompting to confirm you want to overwrite an
              existing destination file.
 /-Y          Causes prompting to confirm you want to overwrite an
              existing destination file.
 /Z           Copies networked files in restartable mode.

The switch /Y may be preset in the COPYCMD environment variable.
This may be overridden with /-Y on the command line.  Default is
to prompt on overwrites unless COPY command is being executed from
within a batch script.

To append files, specify a single file for destination, but multiple files
for source (using wildcards or file1+file2+file3 format).

-----Original Message-----
From: RemoveMEolin_piclistEraseMEspamEraseMEembedinc.com
Sent: Tuesday, October 11, 2005 4:43 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Comments on the EasyProg kit

> He will be even scared after issuing "doc pic_read"
> does not tell him to use "pic_read -sio 2 -hex myhex.hex".

How doesn't it?  The -SIO and -HEX command line options are
documented in addition to -PIC.

2005\10\10@204815 by olin piclist

face picon face
Robert A LaBudde wrote:
> As for the command-line-only non-interactive interface, I have tested
> and found that the EasyProg software will work fine in other folders,
> so long as the EasyProg "com" folder is included in the path.

Which the installer automatically ensures.  Did this not happen on your
system?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@205745 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Why not put an --help
> option which tell the Joe user to use -sio and -hex
> and other options?

I suppose it could bring up the documentation file for the program, but then
again you can do that with the DOC command or just open the TXT file in the
DOC directory directly.  In other words, --help (actually I really hate
command line options with double dashes) wouldn't do anything you can't
already do several other ways.  I don't see how "pic_prog --help" is any
better than "doc pic_prog".

I think having --help dump a brief list of options to standard output is
also a bad idea.  Now there is a chance that the --help documentation and
the help file get out of sync.  I'd rather have all documentation in one
reliable place than scattered copies that can't be trusted.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\10@223723 by Chen Xiao Fan

face
flavicon
face
Actually I think the doc batch file is not necessary and
confusing (it is a batch file and sometimes not working
if the path is not right). Why not let pic_prog /? to
bring up the pic_prog.txt? If you hate "--" you can
use "-h" or "/h" or "/?".

Or at least a prompt like :
"Please refer to the embedinc\doc\pic_prog.txt for the usage."

Regards,
Xiaofan

{Original Message removed}

2005\10\11@024620 by Robert A LaBudde

flavicon
face
At 08:48 PM 10/10/2005, Olin wrote:
>Robert A LaBudde wrote:
> > As for the command-line-only non-interactive interface, I have tested
> > and found that the EasyProg software will work fine in other folders,
> > so long as the EasyProg "com" folder is included in the path.
>
>Which the installer automatically ensures.  Did this not happen on your
>system?

Ah! It added to the path at the beginning, not the end, so I didn't notice
it. I re-added at the end, which was unnecessary.

Thanks.

================================================================
Robert A. LaBudde, PhD, PAS, Dpl. ACAFS  e-mail: RemoveMEralspam_OUTspamKILLspamlcfltd.com
Least Cost Formulations, Ltd.            URL: http://lcfltd.com/
824 Timberlake Drive                     Tel: 757-467-0954
Virginia Beach, VA 23464-3239            Fax: 757-467-2947

"Vere scire est per causas scire"
================================================================

2005\10\12@095134 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> I don't see how "pic_prog --help" is any better than "doc pic_prog".

The latter is completely non-standard, even by Microsoft standards.

Most people looking for a quick reminder on the syntax of a command line
will try things like:

   <command> -?
   <command> -h
   <command> --help
   man <command>
   info <command>

If you try any of these with Embed, Inc. commands, you get no hint
whatsoever that the documentation can be found with

   doc <command>

> I think having --help dump a brief list of options to standard output is
> also a bad idea. Now there is a chance that the --help documentation and
> the help file get out of sync. I'd rather have all documentation in one
> reliable place than scattered copies that can't be trusted.

That's a problem for *you* to solve, not the end user. There's no technical
reason that

   <command> -?
   <command> -h
   <command> --help

couldn't bring up the same text (or a subset of it) from the same source as

   doc <command>

-- Dave Tweed

2005\10\12@104445 by Wouter van Ooijen

face picon face
> Most people looking for a quick reminder on the syntax of a
> command line
> will try things like:
>
>     <command> -?
>     <command> -h
>     <command> --help
>     man <command>
>     info <command>

add:

<command>
<command> help
<command> /help
<command> /h
<command> /?
<command> ?
help <command>

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\10\12@110218 by Michael Rigby-Jones

picon face


{Quote hidden}

IME Native DOS stuff tends to use the forward slash, Unix/Linux almost exclusively uses the hyphen.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\10\12@110231 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> add:
>
> <command>

This one is the most important one !

It should give program version and *at least* the
syntax of the "help-command" (and maybe a brief
descriptin of the options/switches if they are just a few).

The well known pkzip/pkunzip are good examples
of this...

Jan-Erik.



2005\10\12@121559 by Marcel Duchamp

picon face
Michael Rigby-Jones wrote:
{Quote hidden}

Another thought is to add only one special case for help.  That case is
when your command interpreter sees *anything* other than a correct
command.

Let's say you are already parsing the input line for, say, 10 different
commands.  Execute one if you see it; if anything else appears there,
then print the help screen.  This takes in all possible versions listed
above without needing to actually code the parser to look for each one.

For an example of this, open a dos box and and type "netstat ?" w/o the
quotes.  Try various combinations - it seems to work well.

2005\10\12@134155 by Dwayne Reid

flavicon
face
At 08:42 AM 10/12/2005, Wouter van Ooijen wrote:
> > Most people looking for a quick reminder on the syntax of a
> > command line
> > will try things like:
> >
> >     <command> -?
> >     <command> -h
> >     <command> --help
> >     man <command>
> >     info <command>
>
>add:
>
><command>
><command> help
><command> /help
><command> /h
><command> /?
><command> ?
>help <command>

As a person who grew up using DOS, my immediate thought when looking
for command-line help is:

program_name /?

However, a more prudent approach is to simply dump the help text to
the screen when an invalid command parameter is entered.  That covers
pretty much any attempt at requesting help.

And - keeping the help screen(s) within the application should not be
all that much effort for Olin - he regularly creates script files for
most of his programming activities.  Transporting / synchronizing the
help text between the program source and program documentation files
should be something that can be done with an appropriate script or batch.

The real question is: is it worth his time and effort to put that
effort into something that does not generate income for him.  It may
not be - and that is his call.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\10\13@042747 by Alan B. Pearce

face picon face
>And - keeping the help screen(s) within the application
>should not be all that much effort for Olin - he regularly
>creates script files for most of his programming activities.


But it is so much easier than that - the help request should shell out to
whatever command he already expects people to use. Then there is only one
place to keep the help file updated - not inside the program.

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