'So you got a problem?'
| > From: Clyde Smith-Stubbs <HITECH.COM.AU> clyde
> "J. Cabral" <DEI.UMINHO.PT> wrote: Jorge.Cabral
> > I've compiled sucesseful the project and made a dowload to memory!
> > I connected an oscilloscope to the socket pin 2 (used pin 12 as GND)
> > and ... nothing worked!
> It's never useful to say "nothing worked". Firstly - did you start the
> program running? Did you single step to confirm that it executes the code
> you wrote? Did you examine the contents of TRISA and PORTA to see if the
> bits actually changed? When using the PICMaster you can do this - it's not
> like you're just programming a ROM and turning it on.
> Maybe the lines like "bsf rp0" should be "bsf status,rp0". But your message
> should be much more detailed when asking for help.
I have to agree with Clyde. Some of us like to help so _please_ spend a
few minutes polishing your email and adding the necessary information for
I propose the following "form" which indicates the sort of information that
should be provided if you want a quick answer from fellow piclisters. If
you _really_ feel that something is not applicable then leave it out. However,
since you are posting a problem then presumably you are not expert enough
to solve it yourself so it would be best to enter all information. The problem
is often in a totally unexpected direction.
I would hope that the form would be made more comprehensive. It should also
be the first answer to posters who say "My PIC's broken. Please help!".
PIC HELP FORM
. Description of application.
. PIC Device number.
2) Hardware config including
. Power supply
- Voltage confirmed (oscilloscope, multimeter)
- Connected to _all_ power pins e.g. '74 has two GND and +5 pins
- Bypass cap
. Oscillator type
- Clock speed?
- Confirmed set configuration bits.
- Confirmed clock signal on OSCOUT.
- Confirmed frequency (oscilloscpe, freq meter)
. MCLR pin
- Method of control e.g. tie to +5, external brownout protection
. I/O pins
- Connections in circuit - give description or ascii diagram.
- Mode (in, out, I/O, analogue, comparator, used by peripheral)
. Other considerations e.g.
- Electrically noisy environment
- Temp range
. What is the code supposed to do?
. Reset path
- Setting of option register
- Setting I/O port directions and initial values
- Analogue input configuration
- Peripheral configuration
. Using interrupts?
. Code lowest and highest address (looking for page boundary overflows)
. Use of peripheral functions
. Using watchdog timer?
. Using power-down (sleep) modes?
. Add assembler listing fragments if appropriate. Note that a balance h
be made between excessive bandwidth from list server and ability
to see all the code. You should be prepared to send a complete
listing if requested.
. Add listing of interrupt routine. Since interrupt handlers can
have drastic and unexpected effects, it is well worthwhile to
include at least this part of the code.
NB: Assembler list output is more useful than source code since it allows
confirmation that macros have expanded correctly etc. In many cases you will
solve your own problem by looking through the listing.
4) Development environment
. PC operating system (DOS, WIN31, WIN95 etc.)
. MPLAB, Clearview PDE etc. and version numbers
. Programmer hardware
5) Testing procedure - detail results.
. Use MPSIM? If not, give reason as to why use of MPSIM etc. was
not helpful e.g. too difficult to make real-time stimulus.
. Use in-circuit-emulator?
. Use programmed chip in target circuit?
. Was test-point code added e.g. toggling a spare port pin at
certain points in code. If so, what did this indicate?
6) Any other relevant information.
7) Go over your email to make sure that it is not ambiguous or misleading.
Correct the typos, spelling and grammar to the best of your ability.
I for one am under the distinct impression that brevity is cumpulsory.
I've never been particularily adept at expressing myself succinctly.
The PIC'S are new to me but they interest me greatly as my post's to
date no doubt reflect. Cheers
|Tony Matthews <MITVMA.MIT.EDU> wrote: PICLIST
> I for one am under the distinct impression that brevity [when
> asking for help] is cumpulsory.
This is why my answer to the question you recently asked me in
private e-mail included the following phrases:
"I'm a little confused...."
"Did you mean to say...., or are you...., or what?"
"Are you seeing anything at all on...."
"Assuming that you've...."
"I have no idea, of course whether your programmer...."
I'm not so sure that Steve Hardy's suggestion for filling out a
standard form will really be workable, but he and Clyde are right on
the money when they point out that "it doesn't work" is not an
adequate description of ANY problem. Many of us are more than
willing to help solve other list-members' problems, but it's
impossibly frustrating when adequate background information isn't
=== Andrew Warren - ix.netcom.com === fastfwd
=== Fast Forward Engineering - Vista, California ===
=== Custodian of the PICLIST Fund -- For more info, see: ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===
> From: Andrew Warren <IX.NETCOM.COM> fastfwd
> I'm not so sure that Steve Hardy's suggestion for filling out a
> standard form will really be workable, but he and Clyde are right on
> the money when they point out that "it doesn't work" is not an
> adequate description of ANY problem.
Agreed, it wouldn't be workable unless it became widely known - perhaps
on the FAQ (I have vague recollections of one existing somewhere).
Anyhow, if any future posts come along with similar ill-defined
problems then I will post them the form (in private email).
The fact that the original poster's problem turned out to be a dodgy
emulator pod connection (who would have thought of _that_?) shows just
how comprehensive a real checklist would have to be. At least the
current form was filled out by the poster and hopefully it helped to
zoom in on the problem area.
Andrew Warren wrote:
I understand and will endeavour to comply. regards Tony M.
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...