Searching \ for '[PIC:] Process' 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: 'Process'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Process'
2004\01\29@075027 by Dave VanHorn

flavicon
face
Ok, this isn't really a PIC question, as many of you know, I'm a charter
member of the dark side, programming in assembler, on AVRs.

However, this question is processor irrelevant, and I think PIC will reach
the most people.

So here goes.

I spend too much time debugging.
Why?
I know, at the bottom, it's sloppy technique.
Let's face it, almost every time the code doesn't do what it's supposed to
to, it's because we did something stupid.

The question is, how can I improve?
I know there are books out there, but they all seem geared twoard large
teams in high level languages, and I basically never go there.
I normally work on 1-3 person teams, in assembler.
This means that I am locked out of a lot of tools in the first place,
because they are C-centric.
It's no use arguing high level languages at me, I am frequently scraping
the last cycle in processor bound routines, and I simply can't pay that
penalty.

So, what is there, for guys like me?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@082011 by John J. McDonough

flavicon
face
Well, you said it in the title ... it's not the tools, it's the process.

Us tech types often get so enamoured of the latest and greatest tools that
we forget what it is we're trying to use the tools for.  The problem is that
you need to have the process down before you can even know what tools will
be helpful.  And I would suggest that, in general, fancy tools aren't all
that much help in a 1-3 person team anyway.  The place they can make a huge
difference is on large teams where you are constantly tripping over
yourself.

But with a small team, it's hard to get your head around the idea of
process.  The small team tends to deny that any sort of process discipline
is helpful.  But the software development process isn't much different
whether its VB or assembler.  A little bit of process discipline goes a long
way to making us a lot more effective.

I don't know your team and it's particular issues, but I know where most
teams get into trouble.  The first stumbling point is requirements.  Often
we don't get a detailed enough set of requirements.  This is the most costly
place we trip up, because a slight misunderstanding causes a large amount of
work later on.

One way to improve the requirements is to describe the tests before you move
on and consider the requirements "done".  Being able to describe how you are
going to test a requirement is a huge help to making sure the requirement is
specific enough.  It also describes the requirement in a slightly different
way which gives your customer an opportunity to see whether you heard what
he thought he said.

The other issue with requirements is believing that they are "done".  The
trouble with requirements is that, as you move through the design process,
you learn more and you get more insight into the requirements.  This often
means they change.  Unless you have a process in place to recognize those
changes and account for them throughout the project, you tend to shrug them
off until they come back to bite you later, when they are a lot harder to
fix.

The other thing we want to blow by in small teams is going through the
discipline of a somewhat formal design and making sure that the design
artifacts are all traceable back to the requirements, and all the
requirements are implemented in the design. What I don't think smaller teams
"get" is that all these design documents aren't nearly as important as the
process of writing them in the first place.  With our tool bent we spend
more time worrying about formats and appearance, when the important thing is
the thought process.

If we have a sufficiently detailed design and good traceability, almost any
monkey off the street can grok out the code.  And in this case, debugging,
although it will continue to exist, will be a tiny part of the effort,
should be well under 5%.  Of course, there is a huge side effect to this.
If debugging is tiny, your ability to estimate accurately will be greatly
improved.

I'm sure this doesn't make much sense.  However, there is plenty of data,
from SEI, Boehm and others, that the more time you spend up front on
requirements and design, the less time you spend on the total project.  I've
seen this myself, although in the large team context.  It does, however,
eventually kill the whole macho programmer thing that small shops often
thrive on.  Once your projects are predictable, so are your manpower needs.
The ultimate outcome is that programmers can work 8 hour days, which does
tarnish a lot of the mystique of being a programmer.

--McD

{Original Message removed}

2004\01\29@083500 by Wouter van Ooijen

face picon face
> It's no use arguing high level languages at me, I am
> frequently scraping
> the last cycle in processor bound routines, and I simply
> can't pay that penalty.

I don't see why you can't use C for 90% of your code and assembler for
the 10% that is time-critical?

The best route to quality is (guess where the idea comes from):
1- be consistent
2- know, identify, quantify and attribute (find the root cause of) your
problems
3- improve by creating mechanisms that eliminate root causes

Remember me ranting about duplicate PIC chip ID's? I sell (among other
things) pre-programmed PICs. When someone wants one, I put it in my
programmer and press the button to load the code. After accidentally
shipping the wrong chip I made sure that the button verifies that the
correct chip is in the programmer. One more root cause eliminated.

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@083501 by Wouter van Ooijen

face picon face
> that the more time you spend up front on
> requirements and design, the less time you spend on the total
> project.  I've
> seen this myself, although in the large team context.  It
> does, however,
> eventually kill the whole macho programmer thing that small
> shops often
> thrive on.

The best macho programmers are the ones who follow the same route (do a
lot of thinking up front).

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@084536 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen"
Subject: Re: [PIC:] Process


> Remember me ranting about duplicate PIC chip ID's? I sell (among other
> things) pre-programmed PICs. When someone wants one, I put it in my
> programmer and press the button to load the code. After accidentally
> shipping the wrong chip I made sure that the button verifies that the
> correct chip is in the programmer. One more root cause eliminated.

In a never ending quest for obfuscation, management types call this
poka-yoke.  Certainly this exemplifies the whole concept of thinking about
what you're doing.  Unfortunately, us tech types often shoot first and take
aim later.

--McD

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@085612 by Wouter van Ooijen

face picon face
> In a never ending quest for obfuscation, management types call this
> poka-yoke.

Exactly which step is called so?

BTW no need to CC to my private email, I am subscribed to the list!

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@085613 by Olin Lathrop

face picon face
Dave VanHorn wrote:
> I spend too much time debugging.
> Why?
> I know, at the bottom, it's sloppy technique.
> Let's face it, almost every time the code doesn't do what it's
> supposed to to, it's because we did something stupid.

Yup.  Every once in a while the tools or even the processor are at fault,
but it's usually a mistake on the programmer's part.  "Good technique" is
really a bunch of methods that make it less likely to make human mistakes,
and to make them easier to spot when they do occur.

{Quote hidden}

I don't think this is something you learn from books, and most people aren't
open to others telling them how to code anyway.  Part of the answer is that
certain people should never write code in the first place.  People who pride
themselves on "multitasking", for example, are invariably bad coders, and
there is probably no way to fix that.  It seems good coders have a very
structured thinking process and don't tolerate unexplained phenomena very
well (that may be more related to good debugging skills).  This is
especially important when writing low level assembly code.  High level
languages and libraries (like Java, MFC, etc) can cover up a lot of bad
habits that suddenly surface when writing low level assembly code.

Unfortunately, in my experience people can't be taught the careful
meticulous approach to programming.  It either comes from within or it
doesn't come at all.  All I can do is weed out the sloppy thinkers before
hiring.  It's amazing how this trait is obvious in about the first 30
seconds of an interview, whether talking about computers or not.

This isn't what you wanted to hear, but frankly, if you've been coding for a
while and you haven't already developed your own idea of how to do it
carefully and right you never will.  This isn't meant as an insult, just a
true belief on my part.  I'm going to catch a lot of heat for this, but my
advice is to find something else to do that you are truly good at.

For what little it's worth, my idea of a better environment and methodology
for writing PIC assembler code is at http://www.embedinc.com/pic.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@090445 by Wouter van Ooijen

face picon face
> This isn't what you wanted to hear, but frankly, if you've
> been coding for a
> while and you haven't already developed your own idea of how to do it
> carefully and right you never will.

I think I am with Olin on this. Coding is an art, not a science
(computer science does exist, but is something different). An art has to
be learned. If you are open to suggestions from others there is plenty
to read. Don't toss a book away because it focusses on C, most
principles are not langauge (or even HLL-) dependent. If you are not
open to others you'd better be open to your own critique. Observe
yourself and learn. Not much different from the way an artist or an
author learns and improves.

And coding requires a certain mindset to begin with. The types that
always blame someone else for what is going wrong in their lives are not
likely to be good coders. You must be precise and methodical.

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts41-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam_OUT20040130063354.BPYY29681.tomts41-srv.bellnexxia.netTakeThisOuTspammitvma.mit.edu>>          for <.....piclist_errorsKILLspamspam@spam@SYMPATICO.CA>;
         Fri, 30 Jan 2004 01:33:54 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8212 ; Fri, 30 Jan 2004 01:33:51 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 7545; Fri, 30 Jan 2004 01:33:52 -0500
Date:         Fri, 30 Jan 2004 01:33:52 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <LISTSERVspamKILLspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from MAIL.MAILBOX.RO
To:           .....listsjoshKILLspamspam.....3MTMP.COM,
             "For EraseMEBlackholeeclipsespam_OUTspamTakeThisOuTEarthlink.Net" <piclist_errorsspamspam_OUTSYMPATICO.CA>
Message-ID:   <LISTSERV%@spam@2004013001335175KILLspamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'KILLspamowner-piclistKILLspamspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7543; Fri, 30 Jan 2004 01:33:52 -0500
Received: from mail.mailbox.ro [193.226.118.6] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 01:33:51 EST
X-Comment: mitvma.mit.edu: Mail was sent by mail.mailbox.ro
Received: (qmail 1962 invoked for bounce); 30 Jan 2004 13:34:41 -0000
Date: 30 Jan 2004 13:34:41 -0000
From: RemoveMEMAILER-DAEMONTakeThisOuTspammail.mailbox.ro
To: spamBeGoneowner-piclistspamBeGonespamMITVMA.MIT.EDU
Subject: failure notice

Hi. This is the qmail-send program at mail.mailbox.ro.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<TakeThisOuTleoEraseMEspamspam_OUTnullsoft.com>:
64.236.62.131 failed after I sent the message.
Remote host said: 550 Error: Too many virus notifications.  Bye.

--- Below this line is a copy of the message.

Return-Path: <RemoveMEowner-piclistspamTakeThisOuTMITVMA.MIT.EDU>
Received: (qmail 1957 invoked by uid 3750); 30 Jan 2004 13:34:41 -0000
Received: from owner-piclistEraseMEspam.....MITVMA.MIT.EDU by mail.mailbox.ro by uid 501 with qmail-scanner-1.20st
(clamuko: 0.65. spamassassin: 2.61.  Clear:RC:0(209.119.0.109):SA:0(-4.8/5.0):.
Processed in 0.912215 secs); 30 Jan 2004 13:34:41 -0000
X-Spam-Status: No, hits=-4.8 required=5.0
Received: from cherry.ease.lsoft.com (209.119.0.109)
 by mail.mailbox.ro with SMTP; 30 Jan 2004 13:34:40 -0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <EraseME2.00CC4410spamcherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:33:42 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1037 for RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:33:36 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7307; Fri, 30 Jan 2004 01:32:12 -0500
Received: from sj-iport-5.cisco.com [171.68.10.87] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 01:32:11 EST
X-Comment: mitvma.mit.edu: Mail was sent by sj-iport-5.cisco.com
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com
         with ESMTP; 29 Jan 2004 22:32:31 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by
         sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0U6WCNv012845 for
         <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:12 -0800 (PST)
Received: from mac.com (sjc-vpn1-253.cisco.com [10.21.96.253]) by cisco.com
         (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA15063 for
         <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:11 -0800 (PST)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Message-ID:  <EraseMEC832CE19-52E1-11D8-9E8E-000A95E5DF26spamspamspamBeGonemac.com>> Date:         Thu, 29 Jan 2004 21:04:28 -0800
Reply-To:     pic microcontroller discussion list <
RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU>
From:         William Chops Westfield <spamBeGonewestfwSTOPspamspamEraseMEMAC.COM>
Subject: Re: [PIC:] Process
To:           KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU
In-Reply-To:  <000101c3e670$915d6ad0$0b00a8c0@PAARD>
Precedence: list

On Thursday, Jan 29, 2004, at 06:02 US/Pacific, Wouter van Ooijen wrote:

>> This isn't what you wanted to hear, but frankly, if you've
>> been coding for a
>> while and you haven't already developed your own idea of how to do it
>> carefully and right you never will.

I think I disagree.  there are, unfortunately, plenty of environments
where you can code for years and years, and not learn those habits
that lead to "quality" software.  Schools are one - computer science
departments are infamous for grad students and profs who have plenty
of grand ideas, but "can't program their way out of a paper bag."
I suspect large companies are another (lots of shelter) and small
young companies ("get it done NOW, we'll fix it later!) a third.
Sadly, "open source" might be bad places; too many people to pick
up your pieces...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
.

2004\01\29@092520 by Alan B. Pearce

face picon face
> The question is, how can I improve?
> I know there are books out there, but they all seem geared twoard
> large teams in high level languages, and I basically never go there.
> I normally work on 1-3 person teams, in assembler.
> This means that I am locked out of a lot of tools in the first place,
> because they are C-centric.
> It's no use arguing high level languages at me, I am frequently
> scraping the last cycle in processor bound routines, and I simply
> can't pay that penalty.
>
> So, what is there, for guys like me?

Olin replied

>For what little it's worth, my idea of a better environment
>and methodology for writing PIC assembler code is at
http://www.embedinc.com/pic.

And I agree. One of the reasons is one of the things Olin is always banging
on about - relocatable code.

Relocatable code allows you to think in modular software terms. It keeps all
the details about one portion of the code all together in one place. It
helps prevent unwanted interaction with other code in other modules because
local variables are effectively private to that module - unless you do some
other monumental stuff up. It forces you to think about how this module is
going to interact with the other modules.

Relocatable code also allows you to (with conditions) forget about the
paging and banking issues of the PIC. By thinking about how the variables
are stored the banks need to be changed minimally. In Olin's development
environment there are conditional macros that keep track of assembly time
variables that can minimise the creation of extra code for bank switching,
when you put a macro in where it is not actually needed. However having the
macro there documents where the bank should be pointing, and IF NECESSARY
generates the code to do so. There are some gotchas to this approach that
need to be kept track of, especially in loops, but it can be done.

Relocatable code is not really the big deal that many people make it out to
be. You do still have the necessary control over where code and variables
go - if you really need it -  and it does not have to inflate the code size.
The biggest hurdle seems to be the understanding of how the linker works.
Check out the example projects that Olin has at the same web site for
complete projects that help to explain all this.

Then at the end of the project you potentially have some modules for uart
handling, timer handling, I2C, or any other particular part that is
re-usable in another project with minimal changes, without having to copy
and paste from the original source, and then pondering what dependencies
there were in the original when it suddenly does not work.

also in Olin's code there are a very useful collection of macros that make a
number of items easier. Check out the FIFO handling, conditional branching,
the pre-processor functions for setting up I/O pins, the push and pop
macros, and they are all set up to work across the range of PICs that Olin
has used, 14 and 16 bit cores (cannot remember if there are any 12 bit ones
in there)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@093734 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen"
Sent: Thursday, January 29, 2004 8:54 AM
Subject: Re: [PIC:] Process


> > In a never ending quest for obfuscation, management types call this
> > poka-yoke.
>
> Exactly which step is called so?

It's a Japanses term for changing the process so you can't do it wrong.

Of course, as someone said, the trouble with trying to make something
foolproof is that it's easy to underestimate the ingenuity of fools.

--McD

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@100720 by John J. McDonough

flavicon
face
----- Original Message -----
From: "John J. McDonough" <@spam@wb8rcr@spam@spamspam_OUTARRL.NET>
Subject: Re: [PIC:] Process


> It's a Japanses term

and it wouldn't hurt to poka-yoke this keyboard!

--McD

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@102555 by James Caska

flavicon
face
Hmmm.. You say no high level languages but do you know how to use high
level languages? ie not necessarily to write your code but use them to
write code to debug your code?

Specifically..

Do you know how to use high level languages to build formal contracts
over your assembler code?

Do you know how to build state models which represent your application
model so that any out of model change can be detected between
instruction clock cycles?

But realisitically..

Are you open to using assembler where assembler is needed and high level
language for the rest?

Have you got a complete toolbox? Or is your (no high level language)
thinking determining your productivity?

Are you absoltely sure you cannot high level language 80% of your code
and assembler code the other 20% of it?

I know I know.. You said no high level language arguments but really..
They were invented for a reason :-)

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\01\29@104014 by Wouter van Ooijen

face picon face
> Have you got a complete toolbox? Or is your (no high level language)
> thinking determining your productivity?

And don't think HLL or assembler are the only ways to go. Some time ago
I wrote a Python application that transforms a magic sine wave
specification into a PIC assembler source file. (IIRC the Python
application also called the assembler and the programmer software, in
order to automate making efficiency measurments using different sinewave
approximations)

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@104222 by Peter Moreton

flavicon
face
Olin,

> This isn't what you wanted to hear, but frankly, if you've been coding
for > a while and you haven't already developed your own idea of how to
do it
> carefully and right you never will

I don't entirely agree; anyone who can code, can learn to code better,
especially if they happen to be receptive to new ideas, techniques etc,
as the originator of this thread obviously is. I hear what you are
saying about the obvious no-hopers, the ones who blame the hardware for
there own coding errors, but I don't see any evidence that this chap
falls into the 'no-hoper' category!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@105438 by Wouter van Ooijen

face picon face
> I hear what you are
> saying about the obvious no-hopers, the ones who blame the
> hardware for
> there own coding errors, but I don't see any evidence that this chap
> falls into the 'no-hoper' category!

See it as a hint from Olin for the OP to start some introspection. Learn
from others, but do observe what you are doing wrong, and take steps to
prevent that. Whatever steps. Some errors are very personal, so you will
have to find out and cure them yourself. A lot of errors are common to
most humans, so you can learn from books, the internet etc.

Note that often someone notes a personal error, invents a cure, and
promotes this to a standard. This often pisses my off, because I never
fell victim to that specific error. An example is 'don't use C macros'
or 'macro names must be all capitals'. Both hinder me in my work, for no
benefit. But they probably benfit orthers.

Wouter van Ooijen

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@111514 by Tom

flavicon
face
At 07:44 AM 1/29/2004 -0500, Dave wrote:
>I spend too much time debugging.
>Why?
>I know, at the bottom, it's sloppy technique.
>The question is, how can I improve?
>So, what is there, for guys like me?

Dave,

Excellent topic!  And from the spectrum of replies, it hits a nerve in lots
of folks out there.  But don't let the negative ones discourage you.  From
your CV, you earn your daily bread doing this work and my guess is that by
the time you have debugged and shipped, your products work fine.  It's the
extra time getting to the shipping dock that is your concern; not that you
cannot do it.

Not speaking for any other person on this list now, I can tell you I make
the most stupid errors and bugs when I'm just plowing in and have not
thought out the problem or the solution carefully.  When I start a new
project I try to clearly define:
       the nature of the problem
       the exact solution to the problem
       where the hard parts are
       where the easy parts are

Take nothing for granted.  Comment your code.  Write slower and *think*
about what you are doing.

Identify your weakness: keep a "blunder list".  Make it a text file on your
computer easily reached. Make a note of errors you make.  After a project,
review it.  See what same old errors you are making and next time before a
project look at it again.  This might help you see around the blank spot in
your mind that keeps you from not making these errors.

The real positive thing here is that you want to improve.   Despite the
naysayers out there, this is a 100% bonafide GRAY area.  It's not black and
white.  Improvement IS possible.  A small few are born coders who seldom
make mistakes - the rest of us just have to work harder to get there.

Good luck
Tom

ps. It has nothing to do with using high level vs assembly, absolute mode
vs relocatable, or anything else.  *All* procedural methods are subject to
bugs.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@112138 by Ken Pergola

flavicon
face
Dave VanHorn wrote:

> The question is, how can I improve?


Hi Dave,

The fact that you are asking this question about improving one's process is
good, so you should pat yourself on the back.

> I know, at the bottom, it's sloppy technique.

Well, if it's a bad behavior of yours that you want to change, you can
definitely change it if you want to. I believe *everyone* can improve their
coding skills if they really want to. Force yourself to write better code.
For starters, go over to http://www.embedded.com and read Jack Ganssle's work (in
his archives). Visit his web site (http://www.ganssle.com/) -- he's one of
my heroes. If some of his ideas make sense to you and your team, enforce
the use of those ideas in your team development. He has a lot of
information on writing better code and on the "process". Subscribe to his
Embedded Muse newsletter.

> ...because we did something stupid.

Have you tried peer reviews and code walk-throughs?
Even something as simple as a 'Process Checklist', 'Firmware Release
Checklist' and 'Don't repeat these stupid mistakes' checklist can reap
tremendous benefits. Have your team follow the checklist(s) and update it
regularly for everyone's benefit. Keep the communication between team
members high.

Perhaps even some techniques from the TDD (test-driven development)
methodology could help your team as well.

If you do find yourself writing AVR code in C, by all means invest in
PC-lint (http://www.gimpel.com). I've extolled the virtues of this program in the
past on the PICLIST.

Event though the book 'Code Complete' by Steve McConnell is not geared to
embedded systems, it has a lot of good information.

Always strive for self-improvement.


Best wishes and take care Dave,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@114154 by Ken Pergola

flavicon
face
Specifically check out the 'Special Reports' section on Jack's web site:

Special Reports

http://www.ganssle.com/

Regards,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@114925 by Alan B. Pearce

face picon face
>> ...because we did something stupid.
>
>Have you tried peer reviews and code walk-throughs?
>Even something as simple as a 'Process Checklist', 'Firmware Release
>Checklist' and 'Don't repeat these stupid mistakes' checklist can reap
>tremendous benefits. Have your team follow the checklist(s) and update it
>regularly for everyone's benefit. Keep the communication between team
>members high.

While dealing with this side of things go over to http://debuggingrules.com/
and but the book. Print the poster out on a good colour printer, and follow
the rules on the poster and in the book. Read the examples in the book, and
the additional ones on the web site about how thinking was turned around to
solve a problem. While there, look at the links to other sites which seek to
guide along similar lines.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@125029 by Dave VanHorn

flavicon
face
>
> >
> > So, what is there, for guys like me?
>
>I don't think this is something you learn from books, and most people aren't
>open to others telling them how to code anyway.  Part of the answer is that
>certain people should never write code in the first place.  People who pride
>themselves on "multitasking", for example, are invariably bad coders, and
>there is probably no way to fix that.

I don't see how you could be.. Some things I've looked at, it takes
literally hours to get your head into it, and any distraction is fatal.

>  It seems good coders have a very
>structured thinking process and don't tolerate unexplained phenomena very
>well (that may be more related to good debugging skills).  This is
>especially important when writing low level assembly code.

I agree entirely. I don't like seeing anything I didn't expect, and I can
be pretty ruthless about hunting it down when it happens.
The "yeah that glitches once in a while" approach, I don't buy.


>This isn't what you wanted to hear, but frankly, if you've been coding for a
>while and you haven't already developed your own idea of how to do it
>carefully and right you never will.  This isn't meant as an insult, just a
>true belief on my part.  I'm going to catch a lot of heat for this, but my
>advice is to find something else to do that you are truly good at.

Hmm.. It sounds like you're saying that one can't improve, and I have to
reject that.
I can always get better..

>For what little it's worth, my idea of a better environment and methodology
>for writing PIC assembler code is at http://www.embedinc.com/pic.

Digesting.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@125030 by Dave VanHorn

flavicon
face
>
>I don't entirely agree; anyone who can code, can learn to code better,
>especially if they happen to be receptive to new ideas, techniques etc,
>as the originator of this thread obviously is. I hear what you are
>saying about the obvious no-hopers, the ones who blame the hardware for
>there own coding errors, but I don't see any evidence that this chap
>falls into the 'no-hoper' category!

:) So I may in fact be salvageable?  VBG

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@130106 by Dave VanHorn

flavicon
face
>
>Excellent topic!  And from the spectrum of replies, it hits a nerve in lots
>of folks out there.

I suspected it would. It's probably the topic that I hear discussed the least.


>But don't let the negative ones discourage you.  From
>your CV, you earn your daily bread doing this work and my guess is that by
>the time you have debugged and shipped, your products work fine.  It's the
>extra time getting to the shipping dock that is your concern; not that you
>cannot do it.

Bingo. I just look at my debug time, and the mistakes that I find (all
patented HomerCode(TM)) and I think there has to be a better way.


>Not speaking for any other person on this list now, I can tell you I make
>the most stupid errors and bugs when I'm just plowing in and have not
>thought out the problem or the solution carefully.  When I start a new
>project I try to clearly define:
>         the nature of the problem
>         the exact solution to the problem
>         where the hard parts are
>         where the easy parts are


What about those parts where you entered thinking it should work this way,
then you find out that doesn't work, try another, and after a while it gets
to be a bit of a mess?  It would be nice to always start with a full spec,
but often you can't get that information, it's proprietary or something,
and the first couple of obvious solutions, re also wrong solutions..


>ps. It has nothing to do with using high level vs assembly, absolute mode
>vs relocatable, or anything else.  *All* procedural methods are subject to
>bugs.

I'd just like to see less of them.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@130106 by Dave VanHorn

flavicon
face
>
>For starters, go over to http://www.embedded.com and read Jack Ganssle's work (in
>his archives). Visit his web site (http://www.ganssle.com/) -- he's one of
>my heroes. If some of his ideas make sense to you and your team, enforce
>the use of those ideas in your team development. He has a lot of
>information on writing better code and on the "process". Subscribe to his
>Embedded Muse newsletter.

I already do, and have for a long time.


>Have you tried peer reviews and code walk-throughs?

Not yet.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@131519 by Olin Lathrop

face picon face
Dave VanHorn wrote:
>> This isn't what you wanted to hear, but frankly, if you've been
>> coding for a while and you haven't already developed your own idea
>> of how to do it carefully and right you never will.  This isn't
>> meant as an insult, just a true belief on my part.  I'm going to
>> catch a lot of heat for this, but my advice is to find something
>> else to do that you are truly good at.
>
> Hmm.. It sounds like you're saying that one can't improve, and I have
> to reject that.
> I can always get better..

I didn't say people can't improve.  Bad experienced coders can get better,
but never good in my opinion.  That's because the root cause is how their
mental processes work and how they think about the world.  I don't think
that can be changed.

Please understand that I'm not saying one type of thought process is
inherently better, just suited to different tasks.  The opposite capability
is to react quickly and well most of the time to unexpected events.  This is
useful for some tasks where the deliberate make sure you understand it and
think it all thru method doesn't work.  If you're the former type person
then you'll never be really good at software, and you should find something
to do where your thought patterns are an asset instead of a liability.

Just like lots of people may enjoy a casual game of shooting hoops, the vast
majority of people aren't suited to be NBA players and would be better off
trying to be something else.  I think there are more potential good coders
out there than potential NBA players, but for some reason people have more
of a problem with this concept when applied to mental capabilities instead
of physical.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@131729 by Anthony Toft

flavicon
face
> >Have you tried peer reviews and code walk-throughs?
>
> Not yet.

Peer reviews are an _essential_ part of the development process, but don't
limit them to the "formal" review, informal reviews ie one-on-one or three
people are also very useful!

A word of advice though, if you set up a formal review, it is essential you
have a moderator to prevent bashing and to prevent digression and a scribe
to capture that what comes out. The company I work for also suggests that
these people are separate and niether of them wrote the code. Also that
there is _NO_ management in the review, to facilitate free speech, and all
distractions are left out of the meeting.

Peer reviews are extremely informative to both the author and the reviewers
(in a "why did you do it this way?" kindof way)

If you want any info on how to set this thing up, let me know off list...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@131935 by Hopkins

flavicon
face
I usually follow this process

1. Write up specification for program & Testing procedures to prove code
meets specification.
2. Flow chart using Excel
3. Print of flow chart - sit down and go over and correct as required
(several times)
4. Not until I am happy with my flow chart do I start programming.
5. Program following the logical sequence in the flow chart.
6. Test, correct both code and flow chart as required.
7. Enable watchdog, brown out as required, add ID number and code
protection.
8 Print both final code & flow chart for later reference, save both in
separate completed directory.
9 Save a backup copy on CD.

*************************************************

Roy Hopkins

spamBeGonerdhopkinsspamKILLspamihug.co.nz

*************************************************




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@134016 by John Plocher

picon face
Wouter van Ooijen wrote:

> I think I am with Olin on this. Coding is an art, not a science
>
> And coding requires a certain mindset to begin with.

You might want to check out the "XP - Extreme Programming"
series of books on the topic of development processes.

small teams, up front tests written to capture requirements,
regression test suites, pair programming (1 person codes, other
watches, asking questions, reminding...), "done is better
than perfect" attitude that stresses KISS over "generalized"
solutions...

  -John

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@135927 by Bruce Partridge

flavicon
face
> [.....PICLISTspam_OUTspamMITVMA.MIT.EDU]On Behalf Of Dave VanHorn
>
> Bingo. I just look at my debug time, and the mistakes that I find (all
> patented HomerCode(TM)) and I think there has to be a better way.
>
> >Not speaking for any other person on this list now, I can tell you I make
> >the most stupid errors and bugs when I'm just plowing in and have not
> >thought out the problem or the solution carefully.  When I start a new
> >project I try to clearly define:
> >         the nature of the problem
> >         the exact solution to the problem
> >         where the hard parts are
> >         where the easy parts are
>

I have just completed a project where I had only the result as a
specification.  I had no idea how to do it.  I had to change processors
twice, change the supporting electronics once, and completely rewrite once
more for task scheduling.  I certainly had no plans to write pre-emptive
multitasking code for myself, but I ended up doing it.  Thank God I could
make it work with only three threads.

My project is done.  It works acording to spec ;-)  And it only took me 10
months.

If I had to say one thing about how I did it, it would be to never ignore an
anomaly.  If there is anything that doesn't work EXACTLY as you were
expecting, you must spend as much time as it takes to completely understand
what is going on until the function changes or your expectations change.
Otherwise you end up building on sand.

I won't say it worked the first time when I plugged it in - but it was
close.  So far I have only found one problem and it is immediately obvious
which module it is in.

This is nothing original, but I will repeat it:

-Build your code in modules.
-Be positive the module is actually working.
-Build the next module.

I'm not at all sure that my overall debugging time is lower than normal.
But the problems were always in a very small box.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 1/27/2004

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts34-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <TakeThisOuT20040128001409.QNQ23141.tomts34-srv.bellnexxia.net.....spamTakeThisOuTmitvma.mit.edu>>          for <TakeThisOuTpiclist_errorsKILLspamspamspamSYMPATICO.CA>;
         Tue, 27 Jan 2004 19:14:09 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6080 ; Tue, 27 Jan 2004 19:14:05 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 1102; Tue, 27 Jan 2004 19:14:05 -0500
Date:         Tue, 27 Jan 2004 19:14:05 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <.....LISTSERVspamRemoveMEMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           RemoveMElistsjoshspamspamBeGone3MTMP.COM,
             spamBeGonepiclist_errors@spam@spamspam_OUTSYMPATICO.CA
Message-ID:   <LISTSERV%TakeThisOuT2004012719140518spamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'owner-piclistEraseMEspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 1093; Tue, 27 Jan 2004 19:14:04 -0500
Received: from mta269.mail.scd.yahoo.com [66.218.86.186] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 19:14:03 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta269.mail.scd.yahoo.com
From: RemoveMEMAILER-DAEMONEraseMEspamspam_OUTyahoo.com
To: @spam@owner-piclistRemoveMEspamEraseMEmitvma.mit.edu
X-Loop: EraseMEMAILER-DAEMONspam@spam@yahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<@spam@hbarregrdspam_OUTspam.....yahoo.com>:
Sorry, your message to spamBeGonehbarregrdEraseMEspamyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistspamBeGonespammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta269.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 13:56:41 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <RemoveME4.00CBF837@spam@spamspamBeGonecherry.ease.lsoft.com>; Tue, 27 Jan 2004 14:22:38 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1029 for .....PICLIST@spam@spamEraseMEMITVMA.MIT.EDU; Tue, 27 Jan 2004
         14:22:32 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 2144; Tue, 27 Jan 2004 14:21:44 -0500
Received: from mta05-svc.ntlworld.com [62.253.162.45] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 14:21:44 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta05-svc.ntlworld.com
Received: from unknown ([80.1.136.189]) by mta05-svc.ntlworld.com (InterMail
         vM.4.01.03.37 201-229-121-137-20020806) with SMTP id
         <20040127192004.QQTP12068.mta05-svc.ntlworld.com@unknown> for
         <.....PICLISTRemoveMEspamMITVMA.MIT.EDU>; Tue, 27 Jan 2004 19:20:04 +0000
References: <.....F7BD8A8C746E094FA316CDA960BD61DF30CAAFSTOPspamspam@spam@ukxxlon01is0002.tmp.com>> X-Mailer: Forte Agent 1.9/32.560
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID:  <
44ed10d1s1rf8rgpddkuh879459pila09hEraseMEspam@spam@4ax.com>> Date:         Tue, 27 Jan 2004 19:15:28 +0000
Reply-To:     pic microcontroller discussion list <
RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spamBeGonePICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
From:         Mike Harrison <mikespam_OUTspam@spam@WHITEWING.CO.UK>
Organization: White Wing Logic
Subject: Re: [BUY:] smt resistors help please!
To:           spamBeGonePICLIST@spam@spamMITVMA.MIT.EDU
In-Reply-To:  <RemoveMEF7BD8A8C746E094FA316CDA960BD61DF30CAAFEraseMEspamKILLspamukxxlon01is0002.tmp.com>> Precedence: list

On Tue, 27 Jan 2004 19:02:25 -0000, you wrote:

>Hi All,
>
>I'm trying to repair an amplifier which has blown all four N-Channel =
power
>mosfets in the power supply stage. Whilst i'm having no trouble finding
>suitable alternatives for these, the small fire that the most
>catastrophically failed mosfet created seems to have destroyed a single =
SMT
>resistor.
>
>So, to complete the repair, i need a single 10 ohm, ideally 0805 sized =
(but
>a 0603 would do) resistor. I haven't found anywhere that will sell me =
less
>than a reel's worth, which is a bit ott.
>
>So, does anyone have a spare that they could pop in an envelope? I would=
be
>happy to send on postage costs and a beer token...
>
>Thanks in advance,
>
>Jon
>
>PS. I'm in the UK
In the UK, Farnell, RS, CPC and Rapid will all sell SMs in 50 or 100x =
quantities.

I can send you a 10R in 0805 if you email me your address

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.

2004\01\29@140548 by Harold Hallikainen

face picon face
Interesting discussion. I'm not that formal in my work. Since the company
is small, there is no one to do peer review. Years and years ago I went to
a seminar put on by Forth, Inc. Though I never did much with Forth, I have
adopted one of their ideas, and I use it in both hardware and software.
That is, get the small parts working, then connect them together (bottom
up coding). I first get code that talks to the hardware working. Next
comes code that calls that code. Next is code that calls that code, etc.
You do this in Forth by defining new "words" based on words that are
already in the Forth dictionary. As you define each new word, you test it.
Then you move on. Eventually, you have a Forth word that is the complete
application.

Of course, I have an idea of what the final application needs to do, the
user interface, etc. I'm just starting at the bottom and heading in that
direction instead of starting at the top and heading down.

Advocates of top down programming don't like this approach, but it's what
I use. It's probably my hardware orientation.

The other thing I like is COMMENTS!  I type fast enough that the time to
add comments is minimal. The top of each subroutine or function describes
what the function does (the gazinta and the gazouta), what its side
effects are (ideally none, but you often mess with registers in assembly),
and the "design philosophy" (WHY is it done this way, URLs of references,
etc.). As I think about the process while writing a line of code, the
thought goes in a comment on that line. What does this line do? Why is it
here? These help me a lot when I go back a year later trying to add
features.

The first class I taught was PDP-8 assembly language. I had students add
comments to their code after they got it working. Of course, by then, they
didn't really remember how the code worked, so the comments and the code
disagreed. Not super helpful.

We work with contract programmers for Windoze applications. While they may
feel their code is self documenting, not needing comments, I can't read
their code! When their ap needs to talk with my PIC, they can read my PIC
assembly code (even they don't know PIC assembly) and figure out what
needs to be done. Comments!!!


Harold


--
FCC Rules Online at http://www.hallikainen.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@142700 by Bruce Partridge

flavicon
face
> Harold Hallikainen
>
> The other thing I like is COMMENTS!  I type fast enough that the time to
> add comments is minimal. The top of each subroutine or function describes
> what the function does (the gazinta and the gazouta), what its side
> effects are (ideally none, but you often mess with registers in assembly),
> and the "design philosophy" (WHY is it done this way, URLs of references,
> etc.). As I think about the process while writing a line of code, the
> thought goes in a comment on that line. What does this line do? Why is it
> here? These help me a lot when I go back a year later trying to add
> features.
>

I first time I saw the "design philosophy" comments was only a couple of
years ago.  I was converting someone elses code and they had references to
documents with chapter numbers to describe why they were doing things that
way.  Awesome!  My code is now peppered with references to documents that
explain what I was thinking.  The documents are included in my version
control system along with the code and the tool chain.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 1/27/2004

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@142907 by Richard.Prosser

flavicon
face
Dave,
Slightly related, but no help at all I'm afraid.

I was told early on that it is 10 times harder to debug than it is to
actually write the program. Therefore, if you are as clever as you can be
when writing the program, you will never be able to properly debug it!

Keep it Simple.

Richard P




Ok, this isn't really a PIC question, as many of you know, I'm a charter
member of the dark side, programming in assembler, on AVRs.

However, this question is processor irrelevant, and I think PIC will reach
the most people.

So here goes.

I spend too much time debugging.
Why?
I know, at the bottom, it's sloppy technique.
Let's face it, almost every time the code doesn't do what it's supposed to
to, it's because we did something stupid.

The question is, how can I improve?
I know there are books out there, but they all seem geared twoard large
teams in high level languages, and I basically never go there.
I normally work on 1-3 person teams, in assembler.
This means that I am locked out of a lot of tools in the first place,
because they are C-centric.
It's no use arguing high level languages at me, I am frequently scraping
the last cycle in processor bound routines, and I simply can't pay that
penalty.

So, what is there, for guys like me?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@143113 by Dave VanHorn

flavicon
face
At 01:17 PM 1/29/2004 -0500, Anthony Toft wrote:
> > >Have you tried peer reviews and code walk-throughs?
> >
> > Not yet.
>
>Peer reviews are an _essential_ part of the development process, but don't
>limit them to the "formal" review, informal reviews ie one-on-one or three
>people are also very useful!


I've been there, back when I worked for Verifone, though they missed the
part about sending management off to manage something else, and the part
about having a third party moderate..   This is what I would term a "big
company" thing though, and hard to apply to a 1-2-3 person team, which is
where I most frequently operate.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@144116 by Dave VanHorn

flavicon
face
>
>Advocates of top down programming don't like this approach, but it's what
>I use. It's probably my hardware orientation.

I'm that way too.

>The other thing I like is COMMENTS!  I type fast enough that the time to
>add comments is minimal. The top of each subroutine or function describes
>what the function does (the gazinta and the gazouta), what its side
>effects are (ideally none, but you often mess with registers in assembly),
>and the "design philosophy" (WHY is it done this way, URLs of references,
>etc.).

IMHO, the WHY is the most important thing.
I can read the code, so I don't need comments to tell me what, and I do
assume you use mnemonic register names, instead of Gaskrt-1 or REG-11.


>We work with contract programmers for Windoze applications. While they may
>feel their code is self documenting, not needing comments, I can't read
>their code! When their ap needs to talk with my PIC, they can read my PIC
>assembly code (even they don't know PIC assembly) and figure out what
>needs to be done. Comments!!!

Indeed!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@144118 by Dave VanHorn

flavicon
face
>
>I first time I saw the "design philosophy" comments was only a couple of
>years ago.  I was converting someone elses code and they had references to
>documents with chapter numbers to describe why they were doing things that
>way.  Awesome!  My code is now peppered with references to documents that
>explain what I was thinking.  The documents are included in my version
>control system along with the code and the tool chain.

I did an avr package like that. All the inits were explained fully, down to
the bit level, in the comments (why make someone go to the data book?) and
I referenced the data book chapter and page, for more detail.  Now
everything changes so frequently, that you can't really do that, with the
CD-rom of the month with re-re-revised datasheet hosing up all the page
numbers.  Pity they don't use sections or something..

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@154009 by Andrew Warren

flavicon
face
John Plocher <spamBeGonePICLISTspam_OUTspamRemoveMEmitvma.mit.edu> wrote:

> You might want to check out the "XP - Extreme Programming" series
> of books on the topic of development processes.

   ... but only if you really like the idea of having some other
   guy crowding over your shoulder while you try to write code, or
   have so little faith in your code that you want to rewrite
   sections of it over and over, every chance you get.  It's also
   good if you seek justification for jumping right in and coding
   without really knowing what you're doing first, or don't think
   that the widely-publicized failures of XP mean anything.

   My take on XP is that it's a "do the best you can with the crap
   you've got" process... If your programmers are each only
   halfway-capable, put two of them in front of each keyboard;
   maybe you'll make one good programmer out of them. Since they
   don't know how to make their code correct by design, or to plan
   their code before writing it, just tell them that neither of
   those things is required anymore.  Make them write test cases
   concurrently with every line of real code they write, so they
   have at least SOME chance of verifying more-or-less correct
   operation of the project they're bumbling through.

   Most importantly... Since you know that code written this way
   SUCKS, incorporate its inevitable disposal into the process.
   Don't fight wholesale rewriting; embrace it by encouraging your
   programmers to rewrite their code again and again during
   development.

   I'll pass on XP.  Just my opinion, though.

   -Andy

=== Andrew Warren -- .....aiwspamRemoveMEcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@160201 by Russell McMahon

face
flavicon
face
> I spend too much time debugging.

I do too :-)

But these things help me:

1.    Write anything at all complex as pseudo code - my own HLL if you will.
Once written, duplicate the text block produced and use the second copy as
comments for the real code.
Thus I have the full pseudo code at the top and a line by line "compilation"
of it to follow with comments

2.    Name variables, constants etc with specific first letter.
V variable , K Constant etc.
Need varies with "typing" of the assembler.
Nothing worse than using a onstant as an address when you meant to do an
immediate load.

I even get carried away enough to put port names that pins belonmg to into
both the port name AND the pin name :-)

3.    Where state machines are concerned, write as a state diagram then turn
the transitions into psuedo code then treat as in 1 above.

4.    Realise that "boundary conditions" are where most errors occur. Starts
of loops, terminating conditions etc.

5    Comment like mad. Write full explanations about what the routine does
and why at the top. Discuss philosophy and state of Moon if it helps.



       Russell McMahon

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@163456 by Richard.Prosser

flavicon
face
A cynic may suggest that XP is a way of assisting management to "manage
programmers" without actually having to know anything about programming.
RP




John Plocher <PICLISTspam@spam@mitvma.mit.edu> wrote:

> You might want to check out the "XP - Extreme Programming" series
> of books on the topic of development processes.

   ... but only if you really like the idea of having some other
   guy crowding over your shoulder while you try to write code, or
   have so little faith in your code that you want to rewrite
   sections of it over and over, every chance you get.  It's also
   good if you seek justification for jumping right in and coding
   without really knowing what you're doing first, or don't think
   that the widely-publicized failures of XP mean anything.

   My take on XP is that it's a "do the best you can with the crap
   you've got" process... If your programmers are each only
   halfway-capable, put two of them in front of each keyboard;
   maybe you'll make one good programmer out of them. Since they
   don't know how to make their code correct by design, or to plan
   their code before writing it, just tell them that neither of
   those things is required anymore.  Make them write test cases
   concurrently with every line of real code they write, so they
   have at least SOME chance of verifying more-or-less correct
   operation of the project they're bumbling through.

   Most importantly... Since you know that code written this way
   SUCKS, incorporate its inevitable disposal into the process.
   Don't fight wholesale rewriting; embrace it by encouraging your
   programmers to rewrite their code again and again during
   development.

   I'll pass on XP.  Just my opinion, though.

   -Andy

=== Andrew Warren -- EraseMEaiwRemoveMEspamSTOPspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts34-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <RemoveME20040130074404.FTBY23141.tomts34-srv.bellnexxia.netKILLspamspamTakeThisOuTmitvma.mit.edu>>          for <spamBeGonepiclist_errorsspam@spam@SYMPATICO.CA>;
         Fri, 30 Jan 2004 02:44:04 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8255 ; Fri, 30 Jan 2004 02:44:00 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9330; Fri, 30 Jan 2004 02:44:00 -0500
Date:         Fri, 30 Jan 2004 02:44:00 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <RemoveMELISTSERVspam_OUTspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           listsjoshspamspam3MTMP.COM,
             "For spam_OUTBlackholeeclipsespam_OUTspamspam_OUTEarthlink.Net" <piclist_errorsspam_OUTspamSYMPATICO.CA>
Message-ID:   <LISTSERV%RemoveME2004013002440039KILLspamspam@spam@MITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'owner-piclistspamBeGonespam.....MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9328; Fri, 30 Jan 2004 02:44:00 -0500
Received: from mta108.mail.ukl.yahoo.com [217.12.11.45] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 02:44:00 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta108.mail.ukl.yahoo.com
From: KILLspamMAILER-DAEMONspam.....yahoo.co.uk
To: spam_OUTowner-piclistspamKILLspammitvma.mit.edu
X-Loop: RemoveMEMAILER-DAEMONRemoveMEspamEraseMEyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<KILLspamviniciusbhspamspamBeGoneyahoo.co.uk>:
Sorry, your message to viniciusbhspamspamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <RemoveMEowner-piclistspamBeGonespamRemoveMEmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta108.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 07:37:22 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <KILLspam20.00CC4284spamBeGonespamcherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:33:41 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1036 for @spam@PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:33:34 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7305; Fri, 30 Jan 2004 01:32:11 -0500
Received: from sj-iport-3.cisco.com [171.71.176.72] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 01:32:10 EST
X-Comment: mitvma.mit.edu: Mail was sent by sj-iport-3.cisco.com
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com
         with ESMTP; 29 Jan 2004 22:38:01 +0000
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by
         sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0U6WBKi016888 for
         <PICLISTspamBeGonespamspamBeGoneMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:11 -0800 (PST)
Received: from mac.com (sjc-vpn1-253.cisco.com [10.21.96.253]) by cisco.com
         (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA15059 for
         <spamBeGonePICLISTspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:10 -0800 (PST)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Message-ID:  <spam_OUTE1E7A176-5286-11D8-9E8E-000A95E5DF26STOPspamspammac.com>> Date:         Thu, 29 Jan 2004 10:13:47 -0800
Reply-To:     pic microcontroller discussion list <
RemoveMEPICLISTspamspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTspamspamRemoveMEMITVMA.MIT.EDU>
From:         William Chops Westfield <KILLspamwestfwspamspamspam_OUTMAC.COM>
Subject: Re: [PIC:] Process
To:           PICLISTRemoveMEspamMITVMA.MIT.EDU
In-Reply-To:  <EraseME5.2.0.9.2.20040129073858.01554480STOPspamspamRemoveMEmail.cedar.net>> Precedence: list

On Thursday, Jan 29, 2004, at 04:44 US/Pacific, Dave VanHorn wrote:

> I normally work on 1-3 person teams, in assembler.
>
You can get yourself some "structured assembler" macros, but
you have to be careful to make sure they're well documented
and used across everyone who's working together.  Having obscure
macros that only one person uses/understands makes things worse.

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
*** MESSAGE TRUNCATED ***


..
.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts2-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <TakeThisOuT20040128040541.OYLC22295.tomts2-srv.bellnexxia.netRemoveMEspam@spam@mitvma.mit.edu>>          for <EraseMEpiclist_errorsRemoveMEspamSYMPATICO.CA>;
         Tue, 27 Jan 2004 23:05:41 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6230 ; Tue, 27 Jan 2004 23:05:38 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 6847; Tue, 27 Jan 2004 23:05:38 -0500
Date:         Tue, 27 Jan 2004 23:05:38 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <spamLISTSERV.....spamspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           listsjoshspam_OUTspam@spam@3MTMP.COM,
             .....piclist_errorsspamspam.....SYMPATICO.CA
Message-ID:   <LISTSERV%2004012723053845KILLspamspamEraseMEMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'EraseMEowner-piclist@spam@spam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 6845; Tue, 27 Jan 2004 23:05:38 -0500
Received: from mta233.mail.scd.yahoo.com [66.218.86.149] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 23:05:38 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta233.mail.scd.yahoo.com
From: @spam@MAILER-DAEMONspamspamKILLspamyahoo.com
To: spamBeGoneowner-piclistRemoveMEspamEraseMEmitvma.mit.edu
X-Loop: RemoveMEMAILER-DAEMONKILLspamspamRemoveMEyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<TakeThisOuThbarregrdspamyahoo.com>:
Sorry, your message to spamBeGonehbarregrdKILLspamspamTakeThisOuTyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <EraseMEowner-piclist.....spamKILLspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta233.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 14:13:16 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <spam12.00CBF833spamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 14:36:08 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1194 for PICLISTSTOPspamspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         14:35:18 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 2440; Tue, 27 Jan 2004 14:34:42 -0500
Received: from mta06-svc.ntlworld.com [62.253.162.46] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 14:34:41 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta06-svc.ntlworld.com
Received: from dominic ([81.107.116.142]) by mta06-svc.ntlworld.com (InterMail
         vM.4.01.03.37 201-229-121-137-20020806) with SMTP id
         <20040127193250.RTCA22499.mta06-svc.ntlworld.com@dominic> for
         <PICLISTSTOPspamspamKILLspamMITVMA.MIT.EDU>; Tue, 27 Jan 2004 19:32:50 +0000
References:  <@spam@F7BD8A8C746E094FA316CDA960BD61DF30CAAF.....spamspamukxxlon01is0002.tmp.com>> MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID:  <015801c3e50c$452ab1a0$8e746b51@dominic>
Date:         Tue, 27 Jan 2004 19:32:05 -0000
Reply-To:     pic microcontroller discussion list <
spamPICLIST.....spam.....MITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <PICLIST.....spamMITVMA.MIT.EDU>
From:         Dominic Stratten <KILLspamdominic.strattenspam_OUTspamNTLWORLD.COM>
Subject: Re: [BUY:] smt resistors help please!
To:           spam_OUTPICLISTspamTakeThisOuTMITVMA.MIT.EDU
Precedence: list

John - try Rapid Electronics - They sell them in packs of 100 for 80 pence
(10R 0805 1%)

I'd get some for you but I'm not ordering for a couple of weeks or so.

Telephone for them is 01206 751166 - speak nicely and they may do you a deal
on the postage or even post you out some samples for free (especially if you
offer to open an account with them). You'll find them much cheaper than
Maplins, RS and Farnell for most of the everyday stuff you're after.

The code for a pack of 100 (80 pence) is 72-0507

Cheers

Dom

{Original Message removed}

2004\01\29@163703 by steve

flavicon
face
Dave,

Excellent topic and I believe that simply asking takes you out of Olin's
no-hoper category. You are addressing the root cause (procedure)
rather than the immediate problem (bugs).

I once heard embedded programming being described as "applied
problem solving" and I think that sums up the thought process really
well. If your car doesn't start and you think "fuel, spark, compression"
then you are in the right place. If you think "walk", then perhaps not.

I don't think that a procedure that works in a large team can be
assumed to be the right way to do things in a small team. However, you
can take the concept and adapt it to achieve a reasonable result.

The peer review is a good example. How do you do a peer review in a
one person shop ? The method I use is to not comment code as I write
it. I might make a note or two if I am doing something particularly odd
and there will be enough information to be able to use the function
block. Then I make sure that I have worked on enough other things
before I come back to comment it so that I am forced to read the code,
decipher what it is doing and put that into prose. That forces me to
continually question my earlier decisions - why did I do that, why did I
save that register, etc.

There have been some good points brought up already. Modularity is a
key one and complete testing at each upward step is too.

You mentioned having to write code to determine if something will work
or can be done. Make that a separate project. eg. This project reads a
key and flashes a light. Do all your testing on that. Put in your special
cases, etc. Once you are confident it works, use that as a knowledge
base for specifying, designing and coding the real project. So, rather
than doing a cut and paste of the SPI code for example, write it fresh in
the real project, based on the information you gathered in the other
project. Again, you are forcing yourself to review the knowledge and you
aren't inadvertantly putting in test code.

For tools - Got an emulator ? Take it somewhere about an hour away.
Buy a collection of highlighters and a small whiteboard that will sit on
your desk. Nothing encourages sloppy habits like the "suck it and see"
approach that an emulator makes so easy.
Since all the problems are going to be within a couple of pages of
printed code (due to the modular nature of the code) it is going to be
quicker to run through the printout with pencils and highlighters,
scribbling notes and variables on the whiteboard. You'll find that after a
short while, your approach to finding bugs will change too.

Someone else suggested recording your bugs. Also consider what you
could have done procedurally to prevent the bug or to pick it asap. Note
that at the time too.

Steve

==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: .....steve.....spamRemoveMEtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@164326 by John Plocher

picon face
Andrew Warren wrote:
> John Plocher <spam_OUTPICLISTTakeThisOuTspamEraseMEmitvma.mit.edu> wrote:
>
>
>>You might want to check out the "XP - Extreme Programming" series
>>of books on the topic of development processes.
>
>
>     ... but only if you really like the idea of having some other
>     guy crowding over your shoulder while you try to write code, or
>     have so little faith in your code that you want to rewrite
>     sections of it over and over, every chance you get.

>     I'll pass on XP.  Just my opinion, though.

Thats too bad - because you might have gleaned something useful
from it if you gave it a chance.

For example, frontloading the requirements gathering and converting
each requirement into an executable unit test, and putting all the
unit tests into a test suite ensures that when you *do* make changes
later on, you don't accidentially break something else.

Or, the concept of get something simple working, then use it as part
of a requirements-refinement discussion with your customer.  Putting
the customer in the middle of the development loop can help both of
you - the customer can discover gaps in their requirements, or
identify required changes early on, and you can - because of the
bevy of unit tests in your pocket, make those sweeping changes
to your system in confidence.

So you don't like someone crowding over your shoulder?  What about
inspection and peer reviews?  What if *you* were the guy peering
over my shoulder?[*]  Pair programming can be just continuous
peer review.  Sometines there is a place for this style, other times
there isn't.  I've found it effective in situations where new
ground was being covered (initial understanding of complicated
requirements, developing new skills...), and, like you imply,
close to worthless in others.

As with any process, the key is "what good things can I learn from
it?", and not "follow this blindly without question" or even
"dismiss it because my ego gets in the way".

  -John

[*]
Isn't that exactly what happens on the PIC list?  People have
problems, and others - thru the magic of email - peer over their
keyboard, dissect their code, and offer suggestions.  I could
argue that many of the people here actually *enjoy* being in
the look-over-shoulder position :-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@165328 by Ken Pergola

flavicon
face
steve@TLA.CO.NZ wrote:

> How do you do a peer review in a one person shop?

You just have to be a little more creative. :)

If you do not have a group or peers in you shop, you simply review your own
code.
You'd be amazed how helpful it is to review your own code as a step before
releasing your code. Believe me, this can be very helpful.

Code reviews and peer reviews do not have to be a formal and painful
process, and they are not a panacea -- just one method of many to help
catch problems. Every company has to decide how much formality they can
live with in this regard, however, whatever they collectively decide to do,
they should follow it and enforce it.

Does it take time and money, sure. And there's always a tightrope to walk.
You can lose customers by never having a product to deliver, and you can
lose customers by shipping a not-ready-for-prime-time product.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts41-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <EraseME20040129143145.SNMD29681.tomts41-srv.bellnexxia.netspamBeGonespamKILLspammitvma.mit.edu>>          for <RemoveMEpiclist_errorsspamBeGonespamspamSYMPATICO.CA>;
         Thu, 29 Jan 2004 09:31:45 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 7538 ; Thu, 29 Jan 2004 09:31:41 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 0895; Thu, 29 Jan 2004 09:31:42 -0500
Date:         Thu, 29 Jan 2004 09:31:42 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <@spam@LISTSERVspamspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from SOFTHOME.NET
To:           TakeThisOuTlistsjoshKILLspamspam@spam@3MTMP.COM,
             "For .....BlackholeeclipseRemoveMEspamEarthlink.Net" <KILLspampiclist_errorsspamTakeThisOuTSYMPATICO.CA>
Message-ID:   <LISTSERV%TakeThisOuT2004012909314168spamspam_OUTMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistspamspamSTOPspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0893; Thu, 29 Jan 2004 09:31:42 -0500
Received: from mambo.SoftHome.net [66.54.152.35] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with SMTP ; Thu, 29 Jan 2004 09:31:41 EST
X-Warning: mitvma.mit.edu: Host mambo.SoftHome.net claimed to be
          jive.SoftHome.net
Received: (qmail 22776 invoked for bounce); 29 Jan 2004 14:31:42 -0000
Date: 29 Jan 2004 14:31:42 -0000
From: .....MAILER-DAEMONEraseMEspamsofthome.net
To: spamBeGoneowner-piclistspamRemoveMEMITVMA.MIT.EDU
Subject: failure notice

Hi. This is the qmail-send program at softhome.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<.....lufcEraseMEspamSOFTHOME.NET>:
ld.so: Incorrectly built binary which accesses errno or h_errno directly.
ld.so: See /usr/share/doc/libc6/FAQ.gz.
Recipient address unavailable. (#5.2.2)

--- Below this line is a copy of the message.

Return-Path: <spamowner-piclistspam_OUTspam@spam@MITVMA.MIT.EDU>
Received: (qmail 19390 invoked by uid 417); 29 Jan 2004 14:29:13 -0000
Received: from cherry.ease.lsoft.com (209.119.0.109)
 by 192.168.0.39 with SMTP; 29 Jan 2004 14:29:13 -0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <spam6.00CC2A97@spam@spamSTOPspamcherry.ease.lsoft.com>; Thu, 29 Jan 2004 9:25:25 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 4030 for spamBeGonePICLISTspamBeGonespam@spam@MITVMA.MIT.EDU; Thu, 29 Jan 2004
         09:25:20 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0752; Thu, 29 Jan 2004 09:23:51 -0500
Received: from dwalin.rl.ac.uk [130.246.135.131] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Thu, 29 Jan 2004 09:23:48 EST
X-Comment: mitvma.mit.edu: Mail was sent by dwalin.rl.ac.uk
X-RAL-MFrom: <RemoveMEA.B.PearceRemoveMEspamRemoveMErl.ac.uk>
X-RAL-Connect: <sstdwkiwi.ag.rl.ac.uk [130.246.189.231]>
Received: from sstdwkiwi (sstdwkiwi.ag.rl.ac.uk [130.246.189.231]) by
         dwalin.rl.ac.uk (8.12.8/8.12.8) with SMTP id i0TEMPsj017264 for
         <PICLISTKILLspamspamspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 14:22:29 GMT
References: <spam_OUT2193429B07D9914D97216EBBAA6AB8BD1A0509@spam@spamwhitlam.corp.gli.com.au>  
           <TakeThisOuT5.2.0.9.2.20040129073858.01554480spam_OUTspammail.cedar.net>
           <003a01c3e66f$7520ad60$0300a8c0@main>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-CCLRC-SPAM-report: -4.9 : BAYES_00
X-Scanned-By: MIMEDefang 2.35
Message-ID:  <168f01c3e673$53b627a0$KILLspame7bdf682.....spamTakeThisOuTspace.rl.ac.uk>
Date:         Thu, 29 Jan 2004 14:22:25 -0000
Reply-To:     pic microcontroller discussion list <TakeThisOuTPICLISTEraseMEspamRemoveMEMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spam_OUTPICLISTRemoveMEspam.....MITVMA.MIT.EDU>
From:         "Alan B. Pearce" <spamA.B.PearceKILLspamspamKILLspamRL.AC.UK>
Subject: Re: [PIC:] Process
To:           spamPICLISTspam_OUTspamMITVMA.MIT.EDU
Precedence: list

{Quote hidden}

Olin replied

>For what little it's worth, my idea of a better environment
>and methodology for writing PIC assembler code is at
http://www.embedinc.com/pic.

And I agree. One of the reasons is one of the things Olin is always banging
on about - relocatable code.

Relocatable code allows you to think in modular software terms. It keeps all
the details about one portion of the code all together in one place. It
helps prevent unwanted interaction with other code in other modules because
local variables are effectively private to that module - unless you do some
other monumental stuff up. It forces you to think about how this module is
going to interact with the other modules.

Relocatable code also allows you to (with conditions) forget about the
paging and banking issues of the PIC. By thinking about how the variables
are stored the banks need to be changed minimally. In Olin's development
environment there are conditional macros that keep track of assembly time
variables that can minimise the creation of extra code for bank switching,
when you put a macro in where it is not actually needed. However having the
macro there documents where the bank should be pointing, and IF NECESSARY
generates the code to do so. There are some gotchas to this approach that
need to be kept track of, especially in loops, but it can be done.

Relocatable code is not really the big deal that many people make it out to
be. You do still have the necessary control over where code and variables
go - if you really need it -  and it does not have to inflate the code size.
The biggest hurdle seems to be the understanding of how the linker works.
Check out the example projects that Olin has at the same web site for
complete projects that help to explain all this.

Then at the end of the project you potentially have some modules for uart
handling, timer handling, I2C, or any other particular part that is
re-usable in another project with minimal changes, without having to copy
and paste from the original source, and then pondering what dependencies
there were in the original when it suddenly does not work.

also in Olin's code there are a very useful collection of macros that make a
number of items easier. Check out the FIFO handling, conditional branching,
the pre-processor functions for setting up I/O pins, the push and pop
macros, and they are all set up to work across the range of PICs that Olin
has used, 14 and 16 bit cores (cannot remember if there are any 12 bit ones
in there)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.
.

2004\01\29@170613 by Scott Dattalo

face
flavicon
face
On Thu, 29 Jan 2004, John Plocher wrote:

> Andrew Warren wrote:

<snip>

> >     I'll pass on XP.  Just my opinion, though.
>
> Thats too bad - because you might have gleaned something useful
> from it if you gave it a chance.

Give me a choice of any two programmers or Andy, I'd choose Andy.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@181553 by Andrew Warren

flavicon
face
John Plocher <STOPspamPICLISTspam_OUTspamspamBeGonemitvma.mit.edu> wrote:

> > I'll pass on XP.  Just my opinion, though.
>
> Thats too bad - because you might have gleaned something useful
> from it if you gave it a chance.
>
> For example, frontloading the requirements gathering and converting
> each requirement into an executable unit test, and putting all the
> unit tests into a test suite ensures that when you *do* make
> changes later on, you don't accidentially break something else.

   Regression testing is hardly a new concept; if you thought I was
   arguing against the testing of software, you misunderstood me
   and I apologize for being unclear.

   Ease of future regression testing, though, doesn't seem to be
   the primary motivation for XP's requirement that unit tests must
   be written as (or before) real code is written.  XP seems to use
   those tests as a crutch, as a replacement for a real spec.

> Or, the concept of get something simple working, then use it as
> part of a requirements-refinement discussion with your customer.
> Putting the customer in the middle of the development loop can help
> both of you - the customer can discover gaps in their requirements,
> or identify required changes early on, and you can - because of the
> bevy of unit tests in your pocket, make those sweeping changes to
> your system in confidence.

   "In confidence", huh?  I'm the one who wrote that bevy of unit
   tests, right, so what makes my tests more reliable then the rest
   of my code?  This fox-guarding-the-henhouse issue bothers me a
   lot.

   And putting the customer in the middle of the development loop
   may indeed help both of us... But only if cost and schedule are
   no object.  Product definitions that evolve during development
   are the devil; I have way too much experience with that to ever
   be convinced that it's a good idea.

> So you don't like someone crowding over your shoulder?  What about
> inspection and peer reviews?

   Inspection and peer reviews don't take place in one cubicle with
   two people literally sitting at one desk staring at the same
   monitor all day.  Pair programming, from what I've seen, does.

> What if *you* were the guy peering over my shoulder?

   I object to the concept whether I'm the one typing or the one
   kibitzing.

> Pair programming can be just continuous peer review.

   As can backseat driving and stage-mothering.  I don't do that,
   either.

> Sometines there is a place for this style, other times there
> isn't. I've found it effective in situations where new ground was
> being covered (initial understanding of complicated requirements,
> developing new skills...), and, like you imply, close to worthless
> in others.

   I agree that there's a time and place for two people to sit at
   one computer and work on code together.  In my opinion, though,
   that's really only appropriate when debugging a specific problem;
   I don't like the idea of making it the standard methodology for
   code development.

> As with any process, the key is "what good things can I learn from
> it?", and not "follow this blindly without question" or even
> "dismiss it because my ego gets in the way".

   Agreed, but here's more:  I'm aware of no other engineering
   discipline in which professionals routinely use XP-like methods;
   what's so different about computer programming that we need XP's
   radically different methodology?

   -Andy

=== Andrew Warren -- spam_OUTaiwspamspamBeGonecypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@193444 by steve

flavicon
face
> If you do not have a group or peers in you shop, you simply review
> your own code. You'd be amazed how helpful it is to review your own
> code as a step before releasing your code. Believe me, this can be
> very helpful.

I guess you didn't read the rest of the paragraph where I described my
own method for a one person code review. Simply reviewing your own
code is like reading your own text for spelling and gramatical errors.
Unless you have some means of distancing youself from the original
work, you'll just read what you expect to be there, rather than picking up
errors.

Steve.


==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: EraseMEstevespamKILLspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@195942 by John Plocher

picon face
Andrew Warren wrote:
>     and I apologize for being unclear.

Me too - I wasn't trying to flame :-)  Peace.

Nothing in XP is really new - like you said, inspections, reviews
etc are as old as dirt.  What is interesting about XP - to me,
at least, is the sequencing it uses, and the presumption that
the effort starts with 100% code test coverage.  The fallout from
this approach is certainly controversial - code that does not
contribute towards one of the regression tests should be removed
because it is unnecessary, simple designs are preferred over
general solutions, new requirements in mid project are not a
"Bad Thing", etc.

While I'm not sure that the flat cost-of-maintenance-over-time graph
that XP promotes is realistic, from my experience it seems that it
does at least help tame the traditional exponential model.

> XP seems to use those tests as a crutch, as a replacement for
> a real spec.

Sometimes the tests make a better spec than a page of words,
if only because the requestor is more comfortable with code
than documentation.  This certainly is an area that varies
considerably depending on your perspective - if you are
spec'ing a device that will be produced in large quantities,
or cost lots of money, formal specs are much more important,
and won't be written solely by a single developer :-)

I'm as much of a skeptic as you in this area; my comments are
based on projects I did that used my adaption of the things
I found useful in XP, and are probably not good indicators of
the official XP religion.

> This fox-guarding-the-henhouse issue bothers me a lot.

Having spent the time up front to gather the requirements, no
matter the form it takes, I find I am much better able to address
the problem at hand.  Having the reqs expressed as code let me
hand them off to the "customer" (other developers here...) with
the question: "Is this what you mean?".  Often, we found that
the exercise of coding up the requirements as unit tests uncovered
ambiguities or gaps in the requirements which we were able to
deal with before we were too far into the implementation.

The pair programming was useful in this phase, though much
of the pairing was done via speakerphone between colorado and
california, sometimes with the entire team on the phone
together.

> Product definitions that evolve during development
> are the devil;

I've got to agree with you here, but I note that the
inevitable "I thought you meant xxx" disconnects happened
extremely early in the XP-like projects I did, and mid- to
late-implementation in the ones I didn't.  Having prototypes
running and available for initial testing early in the dev
cycle was also a plus - even if they didn't really "do much".

>     I don't like the idea of making it the standard methodology for
>     code development.

I agree, and I hope my comments weren't taken as an endorsement
that it should be.

Looking back over my last (gaack!) almost 25 years of development
experience, the most fun I've had, and the most productive I've
been, has been in the product inceptions - the "group of insanely
motivated people, crammed into a small office, building the
impossible".  That sort of environment is completely inappropriate
for the "need to concentrate on finding a perverse glitch"
phases of things, and forcing either task into the other's
environment is wrong.

> I'm aware of no other engineering
>     discipline in which professionals routinely use XP-like methods


Civil Engineering, Life Critical development efforts, NASA etc
all use various mechanisms to get multiple eyeballs looking at all
code development and changes, modifications to specs trigger
significant process overhead, code coverage reports are the mid-level
manager's mainstay...

XP's methods are not new or unique; it is the ordering of the set
of operations that is what is different about it.  And, getting back
to PIClist focus, I'd have to agree that "full, official religious XP"
is not a good fit for most small firmware projects; on the other hand
(and the reason I've typed so much on this topic), there *is* value
in understanding what it does - value that can be applied to even the
single-person shops out there.


  -John

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@203340 by Andrew Warren

flavicon
face
John Plocher <EraseMEPICLISTRemoveMEspammitvma.mit.edu> wrote:

> I'd have to agree that "full, official religious XP" is not a good
> fit for most small firmware projects; on the other hand (and the
> reason I've typed so much on this topic), there *is* value in
> understanding what it does - value that can be applied to even the
> single-person shops out there.

   Yeah, ok, I think I can agree with that.

   -Andy

=== Andrew Warren -- .....aiwspamspam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@221702 by Ken Pergola

flavicon
face
Steve Baldwin wrote:

> I guess you didn't read the rest of the paragraph where I described my
> own method for a one person code review. Simply reviewing your own
> code is like reading your own text for spelling and gramatical errors.
> Unless you have some means of distancing youself from the original
> work, you'll just read what you expect to be there, rather than
> picking up errors.

Hi Steve,

Yes, I read your entire post, and I respectfully disagree that reviewing
your own code has no merit in finding errors (if that is indeed your
stance). The broad point I was trying to make is if you are in a situation
where you are the *only* coder, reviewing your own code (especially before
release) is a much better option than not reviewing your code at all.

But if I follow your argument, are you saying that you *never* found any
errors in your code by simply reviewing your code?

Sometimes it may be minutes, hours, or weeks (or longer) before I re-read
some of my code, but many times I have spotted problems (or better ways of
doing something) because I simply reviewed it again.

I'm not trying to start an argument with you and I apologize if I'm
misinterpreting your stance -- this has been a fascinating and interesting
thread. It just shows how different (and similar) we all are in our
methodologies.

Take care Steve,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@225515 by Hopkins

flavicon
face
Can you give an example of a state diagram, what do you include - port
states etc?

What software do you use to show the state diagram?

Roy

> 3.    Where state machines are concerned, write as a state diagram then
turn
>
>         Russell McMahon




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@234916 by steve

flavicon
face
Hi Ken,

> Yes, I read your entire post, and I respectfully disagree that
> reviewing your own code has no merit in finding errors (if that is
> indeed your stance). The broad point I was trying to make is if you
> are in a situation where you are the *only* coder, reviewing your own
> code (especially before release) is a much better option than not
> reviewing your code at all.

We are in agreement on that point. Any review is better than no review,
but self review can be made more effective and this is what I was trying
illustrate.

The concept of coming back to the code when you have forgotten what
it was that you did (so that you don't mentally skip over errors) and by
writing most of the comments at this time, you force yourself to actually
study the code. That makes you more critical and the process more
productive.

Note that this is contrary to the conventional wisdom of commenting as
you go and requires the discipline (or a preventative procedure) to not
just leave it as soon as it works.

> I'm not trying to start an argument with you and I apologize if I'm
> misinterpreting your stance -- this has been a fascinating and
> interesting thread. It just shows how different (and similar) we all
> are in our methodologies.

I reread what I had written earlier and seemed far more argumentative
this time than I recall I had intended when I wrote it. I guess that goes
someway towards illustrating my point too.

Steve.

==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: @spam@steveEraseMEspamspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\30@001702 by Bob Axtell

face picon face
Comments below:

Dave VanHorn wrote:

{Quote hidden}

You're right Dave, it has nothing to do with the processor itself.

I worked out a method which works well for me. Everyone is different,
but this one works well for me:

1. Decide in the beginning what the limits are, and what the program
NEEDS TO DO. If your client doesn't know YET, you'd better reach back
and make sure you still have your wallet. I've discovered that many
naive clients assume that you can make your PIC/AVR do anything. They
have no notion as to what is easy and what isn't.

2. Decide what the TOUGH problems are. For example, a program needs to
read in serial from two sources (mostly easy), then average the two
numbers to three decimal places (much harder). I examine the hard stuff,
and using PASCAL, I decide what actually has to take place. Instead of
using PASCAL's floating point unit, I do it the way the PIC/AVR would
have to do it- shifting and adding, etc etc. I don't have to hover over
a hot breadboard debugging; I hover over a hot PC, yes, but it's easier
on your back and nothing smokes. BTW, some people flowchart routines-
which is fine- but I found it too simplistic, trivializing what might be
a huge problem.

3. NOW you have a chance at coding with little trouble. Code it up, then
simulate it on your MPLAB. Did the results match what the PASCAL program
got? Keep debugging until you get the RIGHT answer every time.

4. Before you go HOT with the program, try to rangetest the variables.
What happens when a pointer value is larger than the buffer size? What
makes code bulletproof is RANGE TESTING. (That's what got Microsoft into
trouble with Windows; buffer overflows due to lack of range testing of
pointers) Methodically go through ALL pointers and verify that they
cannot ever fall outside of proper range.

5. NOW go live. You now have a very good chance that if you start
debugging after breakfast, you can celebrate at noon.

--Bob

--

 Replies: NOTE-Script, EXE,BAT and COM
    files will be rejected by server
             --------------
               Bob Axtell
       PIC Hardware & Firmware Dev
         http://beam.to/baxtell
             1-520-219-2363

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservTakeThisOuTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@013334 by William Chops Westfield

face picon face
On Thursday, Jan 29, 2004, at 04:44 US/Pacific, Dave VanHorn wrote:

> I normally work on 1-3 person teams, in assembler.
>
You can get yourself some "structured assembler" macros, but
you have to be careful to make sure they're well documented
and used across everyone who's working together.  Having obscure
macros that only one person uses/understands makes things worse.

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@013336 by William Chops Westfield

face picon face
On Thursday, Jan 29, 2004, at 06:02 US/Pacific, Wouter van Ooijen wrote:

>> This isn't what you wanted to hear, but frankly, if you've
>> been coding for a
>> while and you haven't already developed your own idea of how to do it
>> carefully and right you never will.

I think I disagree.  there are, unfortunately, plenty of environments
where you can code for years and years, and not learn those habits
that lead to "quality" software.  Schools are one - computer science
departments are infamous for grad students and profs who have plenty
of grand ideas, but "can't program their way out of a paper bag."
I suspect large companies are another (lots of shelter) and small
young companies ("get it done NOW, we'll fix it later!) a third.
Sadly, "open source" might be bad places; too many people to pick
up your pieces...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservSTOPspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@013337 by William Chops Westfield

face picon face
On Thursday, Jan 29, 2004, at 09:56 US/Pacific, Dave VanHorn wrote:

>
>> Have you tried peer reviews and code walk-throughs?
>
> Not yet.
>
DESIGN reviews might be more useful.  Usually, by the time you
do a code review, you have code that works at least some of the
time, and that can be a lot of pressure against improvement.  It
can be good for improving your coding style, eventually.  At least,
if you can keep the code reviews focussed on meaningful issues and
not on distractions that are really more a matter of personal
perference.  (although, truth be told, figuring out which are which
can be educational and helpful.)

OTOH, Who am I kidding.  I've been at cisco a very long time,
watching from the middle of the inside as we grew from a tiny
company to a very big company.  With constantly changing challenges
in the "quality" area.  Through three different source code control
systems, several compilers, pre and post symbolic debugger, half a
dozen different processors, ISO 9000, international protocol
certifications, and a plethora of test and "release processes."
Mostly, I've seen an awful lot of stuff that doesn't quite seem
to work all that much better than mere admonishments "write good
code."  (of course, maintaining even THAT level past certain critical
sizes of "the engineering department" is doing "ok."  maybe.)

Sigh.
BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservTakeThisOuTspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@033943 by

picon face
Are we still within the scope of the [PIC] topic ?

Jan-Erik.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@053209 by Russell McMahon

face
flavicon
face
> Are we still within the scope of the [PIC] topic ?

Absolutely not if we don't quote at least a small section of what made us
ask the question?
Possibly not if we do :-)


       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv.....spam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@053626 by Simon Davies

flavicon
face
When I used to do 'design on site' installations for solid state disk drives
replacing mechanical units (we are talking good old 14" drives here!), I
would ring one of my colleagues back in the office and explain very
carefully exactly what the current problem was and why I couldn't work out
what was going on. Almost inevitably, before the end of the call, I had
determined a) where I was going wrong, b) the false assumptions I was making
and c) what to do next. My 2 colleagues got used to this approach and just
sat and listened whilst my thought processes tidied themselves up
sufficiently to be explained to others.
Cost a lot of phone calls though!


>Often you will find that trying to explain the problem to someone else will
>sort all the aspects out in your mind, and the answer becomes obvious. This
>is because such a discussion involves having to set out all the aspects in
a
>logical sequence, and hence forces you to sort them out they way you should
>have before programming.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistserv.....spammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@055043 by Russell McMahon

face
flavicon
face
> When I used to do 'design on site' installations for solid state disk
drives
> replacing mechanical units (we are talking good old 14" drives here!), I
> would ring one of my colleagues back in the office and explain very
> carefully exactly what the current problem was and why I couldn't work out
> what was going on. Almost inevitably, before the end of the call, I had
> determined a) where I was going wrong, b) the false assumptions I was
making
> and c) what to do next. My 2 colleagues got used to this approach and just
> sat and listened whilst my thought processes tidied themselves up
> sufficiently to be explained to others.
> Cost a lot of phone calls though!


A friends and I use this method. We call it the monkey method - the monkey
just sits and listens and makes the occasional intelligent or interested
sound. Surprisingly - this only seems to work if one feels that the monkey
is actually understanding what you are telling them. If you use an
uninformed person as the monkey the answers don't appear.

This may SOUND lime a joke but actually works very well.



       Russell McMahon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@055459 by Simon Davies

flavicon
face
Perfectly true in my experience - you must be expecting that the other
person is going to produce the answer to your problem even if you actually
do it yourself. Explaining it to the receptionist just doesn't work...

Simon

{Original Message removed}

2004\01\30@063010 by Jinx

face picon face
> Often you will find that trying to explain the problem to someone else
> will sort all the aspects out in your mind, and the answer becomes
> obvious. This is because such a discussion involves having to set
> out all the aspects in a logical sequence, and hence forces you to
> sort them out they way you should have before programming

Many's the time I've come up against ignorance or a brick wall with
a PIC (> Are we still within the scope of the [PIC] topic ?) and started
an e-mail to the list, only to have it dawn on me with pointer poised
over Send

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@075300 by Wouter van Ooijen

face picon face
> just sits and listens and makes the occasional intelligent or
> interested sound.

In my experience a text processor works just as well, provided that you
seriously try to explain - whether in code comments, a design dcoument,
or even a manual.

Wouter van Ooijen

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@083242 by Alan B. Pearce

face picon face
>So you don't like someone crowding over your shoulder?  What about
>inspection and peer reviews?  What if *you* were the guy peering
>over my shoulder?[*]  Pair programming can be just continuous
>peer review.  Sometines there is a place for this style, other times
>there isn't.  I've found it effective in situations where new
>ground was being covered (initial understanding of complicated
>requirements, developing new skills...), and, like you imply,
>close to worthless in others.

I remember once seeing an article (Dr Dobbs magazine I think) written by one
of the early microprocessor C compiler gurus who had a company producing a C
compiler (but I cannot recall his name at present) where his team of
programmers worked in pairs in exactly this way. One typing, the other
"looking over shoulder" and he found that this produced a very high working
code output. What would happen is that code would be being entered/debugged
and then the "looking over shoulder" guy would suddenly have a bright idea
and take over the keyboard, while the other guy would now suggest changes.
They would swap back and forth like this, producing very high working
lines/day output figures.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv@spam@spam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@083656 by Alan B. Pearce

face picon face
>> How do you do a peer review in a one person shop?
>
>You just have to be a little more creative. :)
>
>If you do not have a group or peers in you shop, you simply
>review your own code.

And one of the best ways to do this is to "explain" it out loud to an
imaginary person. OK it looks like you are talking to yourself (and you
are), but the act of having to actually say the various bits so that you
hear them gets the whole process working properly.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@083902 by Alan B. Pearce

face picon face
>2.    Name variables, constants etc with specific first letter.
>V variable , K Constant etc.
>Need varies with "typing" of the assembler.
>Nothing worse than using a onstant as an address when you meant
>to do an immediate load.
>
>I even get carried away enough to put port names that pins belonmg
>to into both the port name AND the pin name :-)

This is an area where Olin's pre-processor is a great help. It predefines
names for the port and pin, and produces a macro that gets inserted into the
code to simplify the combination of the two.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@100037 by Bob Barr

flavicon
face
On Fri, 30 Jan 2004 11:54:24 +0100, Simon Davies wrote:

>Perfectly true in my experience - you must be expecting that the other
>person is going to produce the answer to your problem even if you actually
>do it yourself. Explaining it to the receptionist just doesn't work...
>

You might be surprised how well that actually does work. The key to
this technique working is the listener's interest rather than his
expertise.

On occasion, I've tried teaching non-technical coworkers how some
piece of problem code worked. When they were trying to understand what
I was telling them (or at least feigning interest), I found that any
fuzzy thinking on my part became immediately obvious. This didn't
always pinpoint the solution but it generally pointed me toward the
problem I was trying to solve.

I had no expectation that they would be able to produce the solution.
All I needed was for them to try to understand what I was explaining.


Regards, Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@105640 by Simon Davies

flavicon
face
Bob,
I think it might depend on how much prior knowledge you assume your listener
has - I am sure that I could have obtained the same result from the
receptionist but I would have found myself explaining significantly greater
parts of the problem and the background information rather than just
detailing the problem area itself so that I would feel that they had a
grounding in the problem area.
In my particular case this would have involved explaining some of the
fundamentals of disk drive interfaces so that I could be certain that my
listener understood (or at least pretended to understand) the basics before
going on to the actual problem.
I suspect this is a 'horses for courses' argument...

Simon

{Original Message removed}

2004\01\30@161354 by William Chops Westfield

face picon face
On Friday, Jan 30, 2004, at 05:35 US/Pacific, Alan B. Pearce wrote:

>> If you do not have a group or peers in you shop, you simply
>> review your own code.
>
> And one of the best ways to do this is to "explain" it out loud to an
> imaginary person.

You can add comments explaining how it works to an imaginary future
associate.  Your code should already have comments, of course, but on
this second pass you can add a different style of comments.  If you
already did "how it works overviews", you can add per-line details.
If you already have the details, you can add the overviews...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@spam@spamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts41-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <EraseME20040128024034.WZMB29681.tomts41-srv.bellnexxia.netRemoveMEspam@spam@mitvma.mit.edu>>          for <RemoveMEpiclist_errorsspamspamEraseMESYMPATICO.CA>;
         Tue, 27 Jan 2004 21:40:34 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6163 ; Tue, 27 Jan 2004 21:40:30 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 4315; Tue, 27 Jan 2004 21:40:31 -0500
Date:         Tue, 27 Jan 2004 21:40:31 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <STOPspamLISTSERV.....spamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           spamBeGonelistsjoshRemoveMEspamRemoveME3MTMP.COM,
             @spam@piclist_errorsspamBeGonespamSYMPATICO.CA
Message-ID:   <LISTSERV%spam_OUT2004012721403091spamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spamowner-piclistspamspamspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 4313; Tue, 27 Jan 2004 21:40:31 -0500
Received: from mta200.mail.scd.yahoo.com [66.218.86.116] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 21:40:30 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta200.mail.scd.yahoo.com
From: spamBeGoneMAILER-DAEMONKILLspamspamKILLspamyahoo.com
To: TakeThisOuTowner-piclistspamspammitvma.mit.edu
X-Loop: spamBeGoneMAILER-DAEMONspamyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<EraseMEhbarregrdEraseMEspamyahoo.com>:
Sorry, your message to spamBeGonehbarregrdspam_OUTspam.....yahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <spamowner-piclistspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta200.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 13:45:48 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <RemoveME5.00CBF6EBKILLspamspamKILLspamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 13:55:35 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 0646 for EraseMEPICLISTspamBeGonespamspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         13:55:29 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 1549; Tue, 27 Jan 2004 13:53:58 -0500
Received: from mta05-svc.ntlworld.com [62.253.162.45] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 13:53:58 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta05-svc.ntlworld.com
Received: from unknown ([80.1.136.189]) by mta05-svc.ntlworld.com (InterMail
         vM.4.01.03.37 201-229-121-137-20020806) with SMTP id
         <20040127185329.NMFY12068.mta05-svc.ntlworld.com@unknown> for
         <KILLspamPICLISTspamMITVMA.MIT.EDU>; Tue, 27 Jan 2004 18:53:29 +0000
References: <001001c3e4fe$2f061620$5d65a8c0@ISLANDERS>
           <5cad105lt01d9vs48mv5jk8vas1cafgracspam_OUTspamspam4ax.com>> X-Mailer: Forte Agent 1.9/32.560
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID:  <
kgcd1014gbviibchcpkd5bcq54c124au55spamspam@spam@4ax.com>> Date:         Tue, 27 Jan 2004 18:48:54 +0000
Reply-To:     pic microcontroller discussion list <
spamBeGonePICLIST.....spamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <.....PICLIST@spam@spamMITVMA.MIT.EDU>
From:         Mike Harrison <@spam@mikespamWHITEWING.CO.UK>
Organization: White Wing Logic
Subject: Re: [PIC:] Picstart plus as an in circuit programmer? (16F627A)
To:           PICLISTRemoveMEspamMITVMA.MIT.EDU
In-Reply-To:  <spam5cad105lt01d9vs48mv5jk8vas1cafgracspam4ax.com>> Precedence: list

On Tue, 27 Jan 2004 18:12:15 +0000, you wrote:

>On Tue, 27 Jan 2004 09:51:20 -0800, you wrote:
>>- Is the in-circuit programming of the 16F627A the same hookup, =
voltages and algorithm that the picstart plus uses?
>>(can I just jumper over the 5 pins needed for in-circuit programming =
from the picstart plus?)
>>
>I did that for a 16F74 and it worked fine. Make sure you don't have any
>electrolytics or tantalum capacitors on the VDD line to the PIC, the =
picstart
>doesn't have the power to charge those fast enough.

if Vcc is loaded, you can supply an external 5V for Vcc and this usually =
works OK, for all but the
8-pin devices, which need VCC on/off control.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.


'[PIC:] Process'
2004\02\01@221401 by John Ferrell
face picon face
There has been a wealth of great advice here. Let me add my thoughts.

Read code from many sources and evaluate the style from the standpoint of
how easy it is for you to read and understand.

The next step is to imitate the style until you are comfortable with it.

Evaluate your bugs and other problems and try to find "a better way for you"
and test the personal enhancements.

AFTER you are comfortable with that favored style THEN consider innovations.
Be consistent in your documentation and style. If you take a different tack
for every project, don't expect to improve.

I think the leveling off that is typical for programmers is because they
find a way that works, they are reluctant to look for some thing better.

If you have access to high level languages that will allow you better labor
efficiency, I can think of no reason to avoid them.

John Ferrell
6241 Phillippi Rd
Julian NC 27283
Phone: (336)685-9606
johnferrellspam_OUTspamTakeThisOuTearthlink.net
http://DixieNC.US
NSRCA 479 AMA 4190  W8CCW
"My Competition is Not My Enemy"

{Original Message removed}

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