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

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC checklist'
2007\09\25@125031 by M. Adam Davis

face picon face
So I finally found the problem in someone elses design (they asked me
to debug).  It wouldn't start up correctly (spurious resets, but mclr
was fine, power was fine, clock,etc was fine)  But when the
programming cable was connected (not the programmer, just the cable!)
it was fine.  Tracked it down to the LVP being enabled, with no pull
down.

So I'm adding it to my list of things to check in design reviews and
at system bootup:

Power good (voltage, current, correct pins, bypassed etc)
Clock oscillating
Configuration settings correct (WD, POR, BOR, clock, etc)
MCLR pulled high, maybe more depending on intended environment
LVP pin pulled low (even if disabled, as long as circuitry supports it)
All numbers in program are explicit (0xhex, d'decimal', etc) - don't
assume radix in assembly
Make sure I/O is one or the other and correctly set (tris/ddr, pullups, etc)
Make sure peripherals are disabled explicitly if they conflict (A/D on
some pins)
Use RA4 carefully - open collector, only pulls down, never goes high.
...

I'm referring to these by memory, but there are many more.  I ought to
break them up into categories (SW, HW, ?)

What are your checklist items?

-Adam


--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Moving in southeast Michigan? Buy my house: http://ubasics.com/house/

Interested in electronics? Check out the projects at http://ubasics.com

Building your own house? Check out http://ubasics.com/home/

2007\09\25@173713 by Zik Saleeba

face picon face
Out of curiosity which PIC was this? The LVP issue seems to vary
depending on the device.

Cheers,
Zik

On 9/26/07, M. Adam Davis <spam_OUTstienmanTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2007\09\25@213315 by M. Adam Davis

face picon face
It was an 18F4550.

-Adam

On 9/25/07, Zik Saleeba <.....zikKILLspamspam@spam@zikzak.net> wrote:
{Quote hidden}

2007\09\26@025935 by KPL

picon face
> All numbers in program are explicit (0xhex, d'decimal', etc) - don't
> assume radix in assembly

hmm, what is the reason for this?

--
KPL

2007\09\26@044208 by Jan-Erik Soderholm

face picon face
KPL wrote:
>> All numbers in program are explicit (0xhex, d'decimal', etc) - don't
>> assume radix in assembly
>
> hmm, what is the reason for this?
>

Clearity.
Less risks for error/bugs.

> (0xhex, d'decimal', etc)

Personaly I prefer to use the same format for
all constants :

b'01010101', o'177', d'256', h'FF', a'B'

and not mix it up with the "0x" format...

Jan-Erik.

2007\09\26@051346 by Dario Greggio

face picon face
Jan-Erik Soderholm wrote:

>>>All numbers in program are explicit (0xhex, d'decimal', etc) - don't
>>>assume radix in assembly
>>
>>hmm, what is the reason for this?
>>
> Clearity.
> Less risks for error/bugs.

I love the way I got used by Commodore 64 :) and Z80.
i.e. default is decimal, all of the rest has prefixes.
In fact, I changed the default I found on the very first project for PICs...

--
Ciao, Dario

2007\09\26@060016 by M. Adam Davis

face picon face
This error results from code re-use.

I have code that may assume a default radix, and a client wants me to
add some features to existing software.

I could re-invent the wheel, or simply plug in pieces I've built and
move on.  Unfortunately everyone seems to have a different opinion of
what the default radix should be (dec or hex, typically).

So, as a matter of habit, I always set the radix for each variable
explicitly.  No questions, no muss, no fuss, and no later debugging
due to radix issues.

-Adam

On 9/26/07, KPL <.....kpl.listesKILLspamspam.....gmail.com> wrote:
> > All numbers in program are explicit (0xhex, d'decimal', etc) - don't
> > assume radix in assembly
>
> hmm, what is the reason for this?
>
> --
> KPL
> -

2007\09\26@061709 by KPL

picon face
On 9/26/07, M. Adam Davis <EraseMEstienmanspam_OUTspamTakeThisOuTgmail.com> wrote:
> This error results from code re-use.

ok, thanks, this makes sense.


--
KPL

2007\09\26@062713 by Alan B. Pearce

face picon face
>So, as a matter of habit, I always set the radix for each variable
>explicitly.  No questions, no muss, no fuss, and no later debugging
>due to radix issues.

I tend to do this as well, means I don't have to think about what the
default should be when debugging, as it is explicit in the line you are
looking at. Saves much hassle when the number could be decimal or hex, with
no alpha in it.

2007\09\26@080838 by Howard Winter

face
flavicon
picon face
Adam,

On Wed, 26 Sep 2007 06:00:05 -0400, M. Adam Davis wrote:

{Quote hidden}

While I can see that this does avoid bugs when using code from other people, I prefer to always set the default radix to decimal and omit it when writing decimal
numbers (because it "reads" properly, IMHO).  I would always check any code when I include it, and change its radices if necessary.  I *never* just drop in someone
else's code without reading it and changing it to fit my own standards.  This normally involves *at least* adding or changing the comments, adjusting the vertical
alignment, and changing the case of instructions etc. to the way I do it.

I also try to use the most appropriate radix for each instruction - if I'm setting bits in a control register I always do it in binary, since that's what it is - unrelated
bits, and it's daft to make it look like a hexadeximal number (and counting bits in a row is less error-prone than converting hex to binary in your head).  Similarly, if
I'm dealing with a quantitive value (number of seconds, for example) I'll do it in decimal since that's the "natural" radix for it.  I use hex for addresses and such.  I
haven't felt the need to use octal since I stopped working on Datapoint systems!  :-)

As I used to tell my team:  any program worth having will have much more time spent reading it than was spent writing it, so taking extra care with how it's written
pays dividends later.  There is almost no such thing as a "quick one-off" program where you don't need to do it neatly - and if there is then you should delete it as
soon as it's had its one run!

Cheers,


Howard Winter
St.Albans, England


2007\09\26@152831 by Herbert Graf

flavicon
face
On Wed, 2007-09-26 at 09:59 +0300, KPL wrote:
> > All numbers in program are explicit (0xhex, d'decimal', etc) - don't
> > assume radix in assembly
>
> hmm, what is the reason for this?

Because the default radix is not standard. People differ as to what the
default should be. Different compilers/assemblers differ on the default.
On top of that, if you're trying to integrate code from others they
might have set the radix to something other then the default you've
assumed.

TTYL

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