---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A8E5B4019A; Thu, 29 Jan 2004 21:17:25 -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 <20.00CC40D0@cherry.ease.lsoft.com>; Fri, 30 Jan 2004 0:17:15 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 0134 for PICLIST@MITVMA.MIT.EDU; Fri, 30 Jan 2004 00:17:02 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 5736; Fri, 30 Jan 2004 00:00:21 -0500 Received: from www.cotse.net [216.112.42.60] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with ESMTP ; Fri, 30 Jan 2004 00:00:20 EST X-Comment: mitvma.mit.edu: Mail was sent by www.cotse.net Received: from localhost (localhost[127.0.0.1]) (authenticated bits=0) by www.cotse.net (5.7.4/5.7.4) with ESMTP id i0U50Ln8049515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2004 00:00:22 -0500 (EST) (envelope-from cr_axtell@yahoo.com) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <2193429B07D9914D97216EBBAA6AB8BD1A0509@whitlam.corp.gli.com.au> <5.2.0.9.2.20040129073858.01554480@mail.cedar.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4019E4E1.7050708@yahoo.com> Date: Thu, 29 Jan 2004 22:00:17 -0700 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Bob Axtell Organization: BA http://beam.to/baxtell Subject: Re: [PIC:] Process To: PICLIST@MITVMA.MIT.EDU In-Reply-To: <5.2.0.9.2.20040129073858.01554480@mail.cedar.net> Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856439 Comments below: Dave VanHorn wrote: > 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? 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 listserv@mitvma.mit.edu with SET PICList DIGEST in the body .