Searching \ for '[PIC] Myke Predko's book errors' 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/devices.htm?key=pic
Search entire site for: 'Myke Predko's book errors'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Myke Predko's book errors'
2005\05\25@134657 by Bob Liesenfeld

flavicon
face
Hi gang,
 New poster here.  I have a copy of "Programming and Customizing
PICmicro Microcontrollers" 2nd edition.  There seem to be significant
grammatical and typographical errors in this otherwise great text.  I
have searched the Web for an errata but none found.  Anyone know of a
solution?
Thank you!

Bob Liesenfeld

2005\05\25@160707 by Dwayne Reid

flavicon
face
At 11:45 AM 5/24/2005, Bob Liesenfeld wrote:
>Hi gang,
>   New poster here.  I have a copy of "Programming and Customizing
>PICmicro Microcontrollers" 2nd edition.  There seem to be significant
>grammatical and typographical errors in this otherwise great text.  I
>have searched the Web for an errata but none found.  Anyone know of a
>solution?
>Thank you!

15 seconds with Google led me to <http://www.myke.com/pic-book.htm>

dwayne

--
Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.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\05\25@162539 by Lindy Mayfield

flavicon
face
Can you please point out some of the grammatical errors you mentioned?  I have his book right here, and I'd like to have a look.

{Original Message removed}

2005\05\25@173639 by Bob Liesenfeld

flavicon
face


Dwayne Reid wrote:

>
>
> 15 seconds with Google led me to <http://www.myke.com/pic-book.htm>

Yup, I found that as well and although there is a section entitled "Errata
and Updates:" I can't find any corrections on this site.  I did find a few
corrections under "PICmicro Software" on this site (http://www.robh.nl/)
as well as a brief mention of early printings of this edition being a
"disaster", but nothing approaching the errors in mine.

Bob

2005\05\25@201801 by Tom Smith

flavicon
face
I remember Rob Hammerling's comment from March:

Thanks, I've added this error to my 'private' list of errata for the
abominable edition of this book I ever received (Second edition).
 (http://www.robh.nl/picsoft.html#predko)

Regards, Rob.


{Original Message removed}

2005\05\26@010112 by Dwayne Reid

flavicon
face
At 03:35 PM 5/24/2005, Bob Liesenfeld wrote:
> >
> > 15 seconds with Google led me to <http://www.myke.com/pic-book.htm>
>
>Yup, I found that as well and although there is a section entitled "Errata
>and Updates:" I can't find any corrections on this site.  I did find a few
>corrections under "PICmicro Software" on this site (http://www.robh.nl/)
>as well as a brief mention of early printings of this edition being a
>"disaster", but nothing approaching the errors in mine.

Why not drop Myke a note via the email address on the web-site?  He may
have the errata hidden away somewhere - or be prompted to in fact publish
the errata.

I agree with you - I was disappointed with the number of errors in that
book.  I bought the first edition for the guys here at my shop - and was
unhappy enough not to purchase the second edition.  Looks as if that may
have been the right choice.

dwayne

--
Dwayne Reid   <.....dwaynerKILLspamspam@spam@planet.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\05\26@015323 by Bob Liesenfeld

flavicon
face


> At 03:35 PM 5/24/2005, Bob Liesenfeld wrote:
>
>
> Why not drop Myke a note via the email address on the web-site?

 Unfortunatly, the email address on that site bounces.  :(

> I agree with you - I was disappointed with the number of errors in that
> book.  I bought the first edition for the guys here at my shop - and was
> unhappy enough not to purchase the second edition.  Looks as if that may
> have been the right choice.
>

 Yes, it is a shame, and I can only presume that the problem occured in the
printing process and was not Myke's doing.  In any event, thanks for the post.
Perhaps something will turn up.

Bob

2005\05\26@034539 by ath Ekanayake

flavicon
face
I am also trying to get Bill gate to complain about so many bugs in the windows Xp

JC

Dr. Jagath C. Ekanayake
BSc (Eng Hon), PhD MIPENZ, ASCE
Reg. Engineer
Scientist, Landcare Research
P.Box 69, Gerald street
Lincoln , 8152
New zealand
Ph +64 3 325 6701 Ext 2210
Fx+64 3 325 2418
>>> dwaynerspamKILLspamplanet.eon.net 05/26/05 5:01 PM >>>
At 03:35 PM 5/24/2005, Bob Liesenfeld wrote:
> >
> > 15 seconds with Google led me to <http://www.myke.com/pic-book.htm>
>
>Yup, I found that as well and although there is a section entitled "Errata
>and Updates:" I can't find any corrections on this site.  I did find a few
>corrections under "PICmicro Software" on this site (http://www.robh.nl/)
>as well as a brief mention of early printings of this edition being a
>"disaster", but nothing approaching the errors in mine.

Why not drop Myke a note via the email address on the web-site?  He may
have the errata hidden away somewhere - or be prompted to in fact publish
the errata.

I agree with you - I was disappointed with the number of errors in that
book.  I bought the first edition for the guys here at my shop - and was
unhappy enough not to purchase the second edition.  Looks as if that may
have been the right choice.

dwayne

--
Dwayne Reid   <.....dwaynerKILLspamspam.....planet.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\05\26@091306 by John Ferrell

face picon face
I have learned a lot from that book and I expect I will learn more...
I have come to believe there is no such thing as "error free" in this
world.

John Ferrell
http://DixieNC.US

{Quote hidden}

> --

2005\05\26@144539 by Peter

picon face


On Thu, 26 May 2005, John Ferrell wrote:

{Quote hidden}

According to the article about the Shuttle software posted on this list
earlier (and also according to figures from books) the expected error
rate for software is about 1% (reported to the number of lines of code).
This is not the number of typos, it is the number of logic errors. I
tend to agree with this number. It follows that if the book shows 1000
lines of code and 1000 clauses (say, logical statements about bit
functions and so on) it should have about 10 errors in each group (and
the errors in the clauses are harder to catch because there is no easy
way to compile the clauses).

Peter

2005\05\26@153604 by Don Taylor

flavicon
face

On Thu, 26 May 2005, Peter wrote:
{Quote hidden}

Having spent the better part of a decade working for an instrumentation
company, designing and releasing a new generation of an instrument line,
there are relatively modest things that can be done on a team to set the
culture and which can result in an order of magnitude, or even two,
lower error rates than similar teams working on similar projects in the
same building at the same time.

When we were done a dozen software people had produced half a million
bytes of embedded firmware that had to deal with a vast list of
interconnected hardware constraints.  Our error rate was one customer
out of 2000 using the instruments would find one bug each year.  That
translates into you and two dozen of your friends all using this full
time year round for fifty years and still having a 90% chance that not
a one of you would ever have seen a single bug, no matter how small.

Among other things, we included lots of sanity checks internally so that
any inconsistency found, no matter how small, would lock the instrument
up and display an error code with a message to call me and tell me
exactly what this said, that I could trace this to a specific line of
code. Those mostly served to show us the mistakes before we ever shipped
the first instrument.  But they also allowed me to precisely diagnose
and correct an error found by a customer thousands of miles away.

The other projects didn't worry about small errors, they were too busy
just trying to keep their box from crashing in the customer's hands.

Now we have two decades of experience with Windows, nobody seems to care
whether anything works or not, you just press the reset button or you
ignore the problem or you buy a new version every six months and find
different errors.  Being able to pump out new versions with lots of
new features, who cares if it works, we don't have time for that, that
is what matters now, mostly.  Our box, the one with almost no errors,
was cancelled a couple of years after introduction.  The other boxes,
the ones with a nighmare of software problems but who accidentally
happened to have different marketing features, they went on to be a
success that needed many times our design time just to patch their
bugs and keep them going.

Someone should have slapped me up against the wall, told me this, and
repeated this until I understood, early in my career.  It would have
saved me a lot of grief and the company a lot of money.

(Just spent two days trying to figure out why voice input to a Windows
system, that had been working fine, now doesn't work any more.  Made
no changes.  No diagnostics can point me at what the problem is.  And
the more things I change trying to discover the source of the problem
the more I expect I'm just making it worse)

2005\05\26@165135 by Wouter van Ooijen

face picon face
> Among other things, we included lots of sanity checks
> internally so that
> any inconsistency found, no matter how small, would lock the
> instrument
> up and display an error code with a message to call me and tell me
> exactly what this said, that I could trace this to a specific line of
> code. Those mostly served to show us the mistakes before we
> ever shipped
> the first instrument.  But they also allowed me to precisely diagnose
> and correct an error found by a customer thousands of miles away.

Good practice indeed, but how do you apply that to a space shuttle in
descent? For one thing, AFAIK a cell phone does not work at the critical
moments :(

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\05\26@193750 by Don Taylor

flavicon
face

On Thu, 26 May 2005, Wouter van Ooijen wrote:
>> Among other things, we included lots of sanity checks internally so
>> that any inconsistency found, no matter how small, would lock the
>> instrument up and display an error code with a message to call me and
>> tell me exactly what this said, that I could trace this to a specific
>> line of code. Those mostly served to show us the mistakes before we
>> ever shipped the first instrument.  But they also allowed me to
>> precisely diagnose and correct an error found by a customer thousands
>> of miles away.
>
> Good practice indeed, but how do you apply that to a space shuttle in
> descent? For one thing, AFAIK a cell phone does not work at the critical
> moments :(

I certainly wouldn't claim that what we did solved every problem.
But most of the things we did appeared to limit putting in errors
in the first place and in making them very visible during development,
so that they caught and fixed before being delivered to the field.

I had even more extreme ideas on paper. One simple one was that
most programming languages don't really provide an environment where
dimensions and units of measure are supported.  I had described a
language where that might have caught the errors that resulted in
the failures of the european satellite launch and the mars lander.

I thought it was fortunate that we had nothing to do with medical
or life sustaining equipment or weapons systems or industrial systems
that presented the opportunities for disasters on a really grand scale.

I was later interviewed for a job by a company working on drug
infusion equipment.  When I asked them how they ensured that their
product would have no failures they proudly announced that they
used fault trees.  I then asked if they had seen the recent local
presentation by a very qualified individual flown over from England
to show that fault trees don't appear to be the answer. He explained
that every major disaster, Three Mile, Brown's Ferry, the Apollo
fire, Bo Pol, Chernobyl, etc.  all had had a careful analysis and
complete fault tree constructed, that all the fault trees seemed
to guarantee was that the failure would be outside what you had
thought of.  They said they hadn't attended that.  We discussed
what I had helped do to drive down error rates.  They decided I
wasn't the person for their job.

2005\05\27@023015 by Wouter van Ooijen

face picon face
> I had even more extreme ideas on paper. One simple one was that
> most programming languages don't really provide an environment where
> dimensions and units of measure are supported.  I had described a
> language where that might have caught the errors that resulted in
> the failures of the european satellite launch and the mars lander.

Did you lateron ever find a language that does support this? (I mean at
compile time, whith zero run-time overhead, and without having to
declare all the intermediate types and their operators explicitly.)

> When I asked them how they ensured that their
> product would have no failures they proudly announced that they
> used fault trees.

Not a bad approach, but only for problems that are somehow 'visible' in
the design.

> He explained
> that every major disaster, Three Mile, Brown's Ferry, the Apollo
> fire, Bo Pol, Chernobyl, etc.  all had had a careful analysis and
> complete fault tree constructed, that all the fault trees seemed
> to guarantee was that the failure would be outside what you had
> thought of.

These kind of analysis never (at least to my knowledge) take human
(mis)behaviour into account. Humans have a bad tendency to concentrate
their errors on the timescale, which circumvents checks, redundancy,
etc. They also tend to use override functions to compensate for lack of
maintenance, lack of knowledge etc.

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\05\27@032925 by Don Taylor

flavicon
face

On Fri, 27 May 2005, Wouter van Ooijen wrote:
>> I had even more extreme ideas on paper. One simple one was that
>> most programming languages don't really provide an environment where
>> dimensions and units of measure are supported.  I had described a
>> language where that might have caught the errors that resulted in
>> the failures of the european satellite launch and the mars lander.
>
> Did you lateron ever find a language that does support this? (I mean at
> compile time, whith zero run-time overhead, and without having to
> declare all the intermediate types and their operators explicitly.)

In the mid-80's there was some discussion in some of the journals and
among compiler writers.  I ended up being too busy to produce a prototype
of the language.  And it has been too long for me to remember names of
some of the people involved in this.  You might look through SIGPLAN
Notices or do other searches of journals between perhaps '84 and '90 to
see what you can find.  It didn't appear to be a particularly difficult
problem to build a language that would meet your conditions.  I always
wanted to see how the language would turn out.

Actually the author of TK! Solver had a firm position on correctness and
his software automatically handled units.  We flew a group of them in to
discuss embedding something like their product into the instrument as a
user level programming language.  But by that point other things were
falling apart and I never was able to get that work finished.

There were a lot of other features I had on the list for a language like
this but I believe my notes are gone now.

Creating a culture where compact and understandable, and usually
compile-time checkable, assertions were written before the code was
written was one idea.  Our sanity checks were a small subset of that.
But to really do all of that well was a substantial challenge.

Again and again we found we needed to make a change in code but when we
looked at it we saw a sequence of statements.  But there was no easy way
to determine whether that sequencing was absolutely essential or
completely arbitrary, or some mixture.  So I was toying with the idea of
[[ statements... ]] and the order of the statements inside those brackets
was arbitrary.  If the order had mattered you wouldn't have used that
notation, and thus I was trying to let the programmer easily show when
order mattered and when it didn't.  And in the environment we were working
in we had lots of examples with "do these" followed by "do these" and the
order within each of those "these" were arbitrary.

I was trying to put together a notation that made clear what was essential
in a program and what was arbitrary but just needed to get done.

{Quote hidden}

You are correct in that some of the major disasters were the result of the
operators intentionally shutting off safety measures, often for testing,
or intentionally carrying out some action outside the approved mode of
operation. Bo Pol and Chernobyl were both examples of that.  Some fault
analyses try to take these sort of behaviors into account.  But, again,
fault trees only seem to list off all the things that won't ever go wrong
and don't really do a lot to avoid the serious mistakes that will happen.

> 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\05\27@075116 by John Ferrell

face picon face
The "perfect product" will be a lot more expensive than a "satisfactory
product".

Economics drive a lot of decisions.

John Ferrell
http://DixieNC.US

{Original Message removed}

2005\05\27@090619 by Howard Winter

face
flavicon
picon face
John,

On Fri, 27 May 2005 07:53:26 -0400, John Ferrell wrote:

> The "perfect product" will be a lot more expensive than a "satisfactory product".
>
> Economics drive a lot of decisions.

Indeed, but I've found timescales do so even more.  

"I don't want it good, I want it Tuesday" is a joke that has a lot of reality behind it!

Cheers,



Howard Winter
St.Albans, England


2005\05\27@090655 by Peter

picon face

On Thu, 26 May 2005, Wouter van Ooijen wrote:

>> Among other things, we included lots of sanity checks
>> internally so that
>> any inconsistency found, no matter how small, would lock the
>> instrument
>> up and display an error code with a message to call me and tell me
>> exactly what this said, that I could trace this to a specific line of
>> code. Those mostly served to show us the mistakes before we
>> ever shipped
>> the first instrument.  But they also allowed me to precisely diagnose
>> and correct an error found by a customer thousands of miles away.
>
> Good practice indeed, but how do you apply that to a space shuttle in
> descent? For one thing, AFAIK a cell phone does not work at the critical
> moments :(

Build less than 2000 Shuttles and fly significantly less then 2000
missions ? Murphy never sleeps anyway. He is going to get you
eventually. This is the one guy who will never be downsized.

Peter

2005\05\27@091633 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> I had even more extreme ideas on paper. One simple one was that most
>> programming languages don't really provide an environment where
>> dimensions and units of measure are supported.  

> Did you lateron ever find a language that does support this? (I mean at
> compile time, whith zero run-time overhead, and without having to
> declare all the intermediate types and their operators explicitly.)

Doesn't really count for a "language" in some senses of the word, but
MathCAD (and probably all the other better math packages) handle units.

Gerhard

2005\05\27@092250 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> Among other things, we included lots of sanity checks internally so that
>> any inconsistency found, no matter how small, would lock the instrument
>> up and display an error code with a message to call me and tell me
>> exactly what this said, that I could trace this to a specific line of
>> code. Those mostly served to show us the mistakes before we ever
>> shipped the first instrument.  But they also allowed me to precisely
>> diagnose and correct an error found by a customer thousands of miles
>> away.
>
> Good practice indeed, but how do you apply that to a space shuttle in
> descent? For one thing, AFAIK a cell phone does not work at the critical
> moments :(

I think the point of this technique is to avoid (or disable) all sorts of
"defensive" programming techniques during debugging and testing. Many
programmers start out writing code that handles "odd" situations
"gracefully" -- without thinking that during debugging and testing, any
such odd situation should not be handled "gracefully" but rather be at
least logged as error, or stop the whole thing (safely) right there and
"request" to be fixed.

Of course, once you ship this for real use, these "odd" things should
actually be handled "gracefully" (at least safely). It would still be good
to log them, but in embedded systems that's often quite limited :)

Gerhard

2005\05\27@094352 by Wouter van Ooijen

face picon face
> Doesn't really count for a "language" in some senses of the word, but
> MathCAD (and probably all the other better math packages)
> handle units.

I does count as a language, but AFAIK it is interpreted, which removes
most of the implementation challenges.

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\05\27@124809 by Peter

picon face

On Fri, 27 May 2005, Howard Winter wrote:

>> The "perfect product" will be a lot more expensive than a "satisfactory product".
>>
>> Economics drive a lot of decisions.
>
> Indeed, but I've found timescales do so even more.
>
> "I don't want it good, I want it Tuesday" is a joke that has a lot of reality behind it!

I heard about the one 'I want it good, I want it now, and we'll pay you
later'. Also 'you must achieve 100% yield' (over tens of items), said by
an engineer (I haven't seen his credentials though). Not funny.

Peter

2005\05\28@081443 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> Doesn't really count for a "language" in some senses of the word, but
>> MathCAD (and probably all the other better math packages) handle units.
>
> I does count as a language, but AFAIK it is interpreted, which removes
> most of the implementation challenges.

Why is that? Isn't an interpreter more challenging than a compiler, in the
sense that the interpreter can do everything the compiler can, but not vice
versa? Or is it the optimization of this that is the challenge?

Gerhard

2005\05\28@102540 by Wouter van Ooijen

face picon face
> > I does count as a language, but AFAIK it is interpreted,
> which removes
> > most of the implementation challenges.
>
> Why is that? Isn't an interpreter more challenging than a
> compiler, in the
> sense that the interpreter can do everything the compiler
> can, but not vice
> versa? Or is it the optimization of this that is the challenge?

For the aspect that was discussed (unit-safeness) the challenge is not
(so much) to detect unit errors at run time, but to detect all unit
errors at compile time, and get the compiled program as effective (size
and speed) as the equivalent unit-unaware program.

Wouter van Ooijen

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


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