Exact match. Not showing close matches.
PICList
Thread
'[PIC] strange problem'
2005\05\12@202752
by
rumpelteazer666
|
I've tried to find something useful on the datasheet,tutorials and pic books, i've tried to write it both in c and in assembler, you never know, but the problem is always there. I don't know if i can reasonably expect someone to look at the code and do the thinking for me, but this is my last hope, so i will try. The code in the while(1) block should just send a square
wave to PORTA, but i put a while(B0!=1); before it. What i think it should do is, it stays still until i press the button (putting a 1 on the first bit of PORTB) and then start to play the squarewave, forgetting about the button. Well, i put it on the breadboard and i found that actually it plays the wave only as long as i keep the button pushed down. If i let a 0 on PORTB it stops again, waiting for a new 1. So somehow it goes back to the first while, how's that? :-/
ps. i know the code is useless and weird, it was a starting point to develop what i wanted to be my first pic project, but then i got blocked on my first steps by this thing.
#define __16f628
#include <pic/pic16f628.h>
typedef unsigned int config;
config at 0x2007 __CONFIG = _HS_OSC &
_WDT_OFF &
_PWRTE_ON ;
BIT_AT(PORTB_ADDR,0) B0;
void delay(void);
unsigned char a,d1;
void main(void){
CMCON=7;
TRISA=0;
TRISB=255;
a=150;
PORTA=0;
while(B0!=1);
while(1){
PORTA=1;
delay();
PORTA=255;
delay();
}
}
void delay(void){
_asm
movlw _a
movwf _d1
Delay_0:
decfsz _d1, f
goto Delay_0
nop
nop
_endasm;
}
2005\05\12@205431
by
John Ferrell
I am not proud of my C skills, but until you get better advice take a hard
look at that
"while(B0!=1);"
and see if you really can get by it without the bit button.
John Ferrell
http://DixieNC.US
{Original Message removed}
2005\05\12@210546
by
Bob Ammerman
|
Watch dog timer resetting????
----- Original Message -----
From: "John Ferrell" <spam_OUTjohnferrellTakeThisOuT
earthlink.net>
To: "Microcontroller discussion list - Public." <.....piclistKILLspam
@spam@mit.edu>
Sent: Thursday, May 12, 2005 8:55 PM
Subject: Re: [PIC] strange problem
{Quote hidden}>I am not proud of my C skills, but until you get better advice take a hard
>look at that
> "while(B0!=1);"
> and see if you really can get by it without the bit button.
>
> John Ferrell
>
http://DixieNC.US
>
> ----- Original Message -----
> From: "rumpelteazer666" <
rumpelteazer666
KILLspamgmail.com>
> To: <
.....piclistKILLspam
.....mit.edu>
> Sent: Thursday, May 12, 2005 8:27 PM
> Subject: [PIC] strange problem
>
>
> I've tried to find something useful on the datasheet,tutorials and pic
> books, i've tried to write it both in c and in assembler, you never know,
> but the problem is always there. I don't know if i can reasonably expect
> someone to look at the code and do the thinking for me, but this is my
> last
> hope, so i will try. The code in the while(1) block should just send a
> square
> wave to PORTA, but i put a while(B0!=1); before it. What i think it should
> do is, it stays still until i press the button (putting a 1 on the first
> bit
> of PORTB) and then start to play the squarewave, forgetting about the
> button. Well, i put it on the breadboard and i found that actually it
> plays
> the wave only as long as i keep the button pushed down. If i let a 0 on
> PORTB it stops again, waiting for a new 1. So somehow it goes back to the
> first while, how's that? :-/
>
> ps. i know the code is useless and weird, it was a starting point to
> develop
> what i wanted to be my first pic project, but then i got blocked on my
> first
> steps by this thing.
>
>
> #define __16f628
> #include <pic/pic16f628.h>
>
> typedef unsigned int config;
> config at 0x2007 __CONFIG = _HS_OSC &
> _WDT_OFF &
> _PWRTE_ON ;
>
> BIT_AT(PORTB_ADDR,0) B0;
>
> void delay(void);
>
> unsigned char a,d1;
>
> void main(void){
>
> CMCON=7;
> TRISA=0;
> TRISB=255;
>
> a=150;
> PORTA=0;
>
> while(B0!=1);
> while(1){
> PORTA=1;
> delay();
> PORTA=255;
> delay();
>
> }
> }
>
> void delay(void){
> _asm
> movlw _a
> movwf _d1
> Delay_0:
> decfsz _d1, f
> goto Delay_0
> nop
> nop
>
> _endasm;
> }
> --
2005\05\12@212458
by
rumpelteazer666
looks like something like that, but isn't
config at 0x2007 __CONFIG = _HS_OSC &
_WDT_OFF &
_PWRTE_ON ;
enough to turn it off? what can i do to check if this is due to wdt?
On 5/13/05, Bob Ammerman <EraseMErammermanspam_OUT
TakeThisOuTverizon.net> wrote:
>
> Watch dog timer resetting????
>
>
2005\05\12@220707
by
phil B
that was my first thought. something is resetting the
device. can you read the config word in your
programmer to be sure? brown-out? flakey power?
--- rumpelteazer666 <rumpelteazer666
spam_OUTgmail.com> wrote:
{Quote hidden}> looks like something like that, but isn't
>
> config at 0x2007 __CONFIG = _HS_OSC &
> _WDT_OFF &
> _PWRTE_ON ;
>
> enough to turn it off? what can i do to check if
> this is due to wdt?
>
> On 5/13/05, Bob Ammerman <
@spam@rammermanKILLspam
verizon.net>
> wrote:
> >
> > Watch dog timer resetting????
> >
> >
> -
2005\05\13@001024
by
Matthew Miller
Hi,
On Fri, May 13, 2005 at 01:24:58AM +0000, rumpelteazer666 wrote:
> looks like something like that, but isn't
>
> config at 0x2007 __CONFIG = _HS_OSC &
> _WDT_OFF &
> _PWRTE_ON ;
>
> enough to turn it off? what can i do to check if this is due to wdt?
You overlooked John's answer. :) He said look at the statement:
"while(B0!=1);"
This statement contains your error. Compare it to your next while statement
to see what is wrong. Also, a comment on style: if you write in a language
such as C, please, oh please, indent your code! If you did, I bet you would
have caught this mistake.
Take care, Matthew.
--
"Every sensible man, every honest man, must hold the christian sect in
horror. 'But what shall we substitute in its place?' you say. What? A
ferocious animal has sucked the blood of my relatives. I tell you to rid
yourselves of this beast and you ask me what you shall put in its place?"
-- Voltaire
2005\05\13@051514
by
Peter Onion
> while(B0!=1);
What is connected to the other 7 bits of PORTB ? Since your setting in
TRISB makes them all inputs, unless they are all wired to 0v then the
above loop will NOT wait for you to press the button.
You probably want to test just the bottom bit like this ...
while((B0 & 1) == 0) ;
Peter
2005\05\13@053234
by
Michael Rigby-Jones
|
{Quote hidden}>-----Original Message-----
>From:
KILLspampiclist-bouncesKILLspam
mit.edu [
RemoveMEpiclist-bouncesTakeThisOuT
mit.edu]
>Sent: 13 May 2005 10:15
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] strange problem
>
>
>
>> while(B0!=1);
>
>What is connected to the other 7 bits of PORTB ? Since your
>setting in TRISB makes them all inputs, unless they are all
>wired to 0v then the above loop will NOT wait for you to press
>the button.
>
>You probably want to test just the bottom bit like this ...
>
> while((B0 & 1) == 0) ;
>
>Peter
I'm not familiar with the compiler (CCS?), but the syntax suggests that
the original code is a bit test on RB0 and therefore quite valid.
To the OP: If you are certain it's not a watchdog issue, then persuade
your compiler to produce an assembly listing so you can check if the
code the compiler is producing matches your source. It's a very small
program so should be easy enough to follow. Post it to the list if it
dosen't make sense.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
2005\05\13@062302
by
rumpelteazer666
looks like the main suspicions are on the "while(B0!=1);". It's the first time i use sdcc but i think it should just cycle until B0 becomes 0 (!=1), then quit the loop and go on with the program. I guess since it has a semicolon at end, it should not contain the other while, but rather be a different loop. However i tried to do something like this:
while(B0!=1){
_asm
nop;
_endasm
}
(you never know) and it's the same. For resetting issues:the power is from a 9v battery -> 78ls05 regulator and pin 4 is connected directly to the regulator output. This is how it writes the while in assembler (second version):
_00105_DS_
;#CSRC a.c 24
; while(B0!=1){
BTFSC (_B0 >> 3), (_B0 & 7)
GOTO _00109_DS_
nop;
GOTO _00105_DS_
Looks like there is no problem here.
2005\05\13@062408
by
Peter Onion
On Fri, 2005-05-13 at 10:31 +0100, Michael Rigby-Jones wrote:
{Quote hidden}>
> >-----Original Message-----
> >From:
spamBeGonepiclist-bouncesspamBeGone
mit.edu [
TakeThisOuTpiclist-bouncesEraseME
spam_OUTmit.edu]
> >Sent: 13 May 2005 10:15
> >To: Microcontroller discussion list - Public.
> >Subject: Re: [PIC] strange problem
> >
> >
> >
> >> while(B0!=1);
> >
> >What is connected to the other 7 bits of PORTB ? Since your
> >setting in TRISB makes them all inputs, unless they are all
> >wired to 0v then the above loop will NOT wait for you to press
> >the button.
> >
> >You probably want to test just the bottom bit like this ...
> >
> > while((B0 & 1) == 0) ;
> >
> >Peter
>
> I'm not familiar with the compiler (CCS?), but the syntax suggests that
> the original code is a bit test on RB0 and therefore quite valid.
Ah , right I see now that "B0" means bit zero of PORTB. Not ANSI C
then !
Peter
2005\05\13@062626
by
Dave Turner
Hmmm... Not so good at C or BASIC coding (or whatever it is), but I
think the problem might be with the second loop (that's supposedly
continuous). If the second (always) loop wasn't working, the button
loop might work, but the next loop only executes once, so the square
wave works fine, as long as the button is held down. I usually use,
instead of while(1), I use while(5==5), because I have found some
compilers don't always treat ones as trues. At least with 5==5 I can
be certain. Also, with the language you are using, if it reaches the
end of main, does it loop back to the begining, or what?
On 5/13/05, Michael Rigby-Jones <RemoveMEMichael.Rigby-Jones
TakeThisOuTbookham.com> wrote:
>
>
> >{Original Message removed}
2005\05\13@063525
by
Peter Onion
On Fri, 2005-05-13 at 11:26 +0100, Dave Turner wrote:
> I usually use,
> instead of while(1), I use while(5==5), because I have found some
> compilers don't always treat ones as trues.
If your compiler doesn't treat "while(1)" as an endless loop, IMHO
you're not using a "C" compiler ! LOL
Peter
2005\05\13@065738
by
Peter van Hoof
I am not a C programmer but it looks exactly like a programming language for IBM
industrial robots I learned 17 years ago AML2.
Could the problem be the double definition of delay? or do you need this far a
forward reference?
TTYL
Peter van Hoof
{Original Message removed}
2005\05\13@081301
by
John Ferrell
Do it like this:
void main(void)
{
CMCON=7; // I am assuming this is correct, did not verify
TRISA=0; // set port A, bit 0 to output
TRISB=255; // set all port B to input
a=150; // initialize delay time
PORTA=0; // turn off output bit to start
while(B0!=1); // this statement hangs waiting on hardware to
force B0 on.
while(1) // 1 will always evaluate to 1. therefore you
cannot get out of this while loop with software
{
PORTA=1; // output a bit
delay(); // wait on time
PORTA=255; // output all bits in Port A if the default for PORTA is
output
delay(); // wait on time
} // end while(1)
} //end main
I am assuming the // initiates a comment in your compiler.
I cannot see any reason for the software to allow you out of the while(1)
loop.
I did not examine the rest of the code.
I admit to being an extremist on comments. An uncommented line is an
opportunity lost.
If you are serious about the problem, take a herd look at ALL of the
suggestions and the PIC Collective will eventually solve the problem.
If you are a Troll, it is your move....
John Ferrell
http://DixieNC.US
2005\05\13@082126
by
Michael Rigby-Jones
|
>-----Original Message-----
>From: piclist-bouncesEraseME
.....mit.edu [EraseMEpiclist-bounces
mit.edu]
>Sent: 13 May 2005 01:28
>To: RemoveMEpiclistEraseME
EraseMEmit.edu
>Subject: [PIC] strange problem
>
>
>
>typedef unsigned int config;
>config at 0x2007 __CONFIG = _HS_OSC &
>_WDT_OFF &
>_PWRTE_ON ;
Just a thought, have you tried importing the hex file into MPLAB and
actually checking the fuse values that the compiler has generated?
Try including a CLRWDT command in your while(1) loop just to check (I'm
not sure how you achieve this with SDCC, but if it allows inline
assembly it should be easy).
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
2005\05\13@091623
by
rumpelteazer666
|
dave: i checked the generated asm code, and looks like even if it exits from the second while, it doesn't go back to the start of the program
peter v.h. : i declare the delay procedure so when i call it in the main it knows it has to search for it at the end of the code. however, i can write all the function before the main block, avoiding the declaration, but the problem still remains.
john: you are right, my programming teacher at high school always scolded me for lazy indentation and scarce/non-existant commenting. when i'm working on the code i always think "there's no need for it, this is so simple and selfexplanatory!" but if i put it away for a couple of weeks and then look back at it not only i have a hard time figuring out what it does, but i could also swear that it wasn't me who wrote it :) Should i post code again in the future i promise it will be presented in a better form.
michael: yes, i tried to check the wdte but when i load the .hex file it unchecks. neither had i luck adding a clrwdt
maybe it is resetting for hardware causes? how should i check that?
2005\05\13@120040
by
William Chops Westfield
On May 13, 2005, at 6:16 AM, rumpelteazer666 wrote:
> when i'm working on the code i always think "there's no need for it,
> this is so simple and selfexplanatory!"
It is especially important to comment things that look like common
mistakes, like your:
while(B0!=1);
Look at the number of people assumed that was wrong or suspect!
It looks OK to me, based on your text, but I would have written:
while (B0 != 1)
; /* Spin waiting for B0 = 1 */
BillW
2005\05\13@121548
by
Jan-Erik Soderholm
rumpelteazer666 wrote :
> i checked the generated asm code, and looks like even
> if it exits from
> the second while, it doesn't go back to the start of the program
So what *does* it do. The PIC must do *something*...
Note that if the PIC just runs away, it will pretty soon (when
the program counter rolls over to h'0000') start all over
again, just as after a reset.
If you realy want it to "hang", you have to have a endless loop.
Jan-Erik.
2005\05\13@124053
by
John Ferrell
See below...
John Ferrell
http://DixieNC.US
john: you are right, my programming teacher at high school always scolded me
for lazy indentation and scarce/non-existant commenting. when i'm working on
the code i always think "there's no need for it, this is so simple and
selfexplanatory!" but if i put it away for a couple of weeks and then look
back at it not only i have a hard time figuring out what it does, but i
could also swear that it wasn't me who wrote it :) Should i post code again
in the future i promise it will be presented in a better form.
*Most of the guys who really know the answers off the tops of their heads
will not bother with looking at your code without reasonable formatting. I
consider myself a "top down" programmer. I start by writing the comments and
then I do the code. It works for me and my meat-memory is old enough to be
on Medicare...
maybe it is resetting for hardware causes? how should i check that?
*All inputs should be tied either up, down or to a signal.
The power supply should be bypassed at the chip.
How do you know it is running?
2005\05\13@131337
by
rumpelteazer666
|
>How do you know it is running?
I know it is running because when i put a 1 on that pin it plays the squarewave (i connected the outputof to my bass amplifier), but only as long as i keep that 1 on the pin.
>All inputs should be tied either up, down or to a signal. The power supply should be
>bypassed at the chip.
Then, maybe we found the problem. Not every pin of PORTB is pulled down, i left some floating. I don't have enough resistors right now, so i will try to set only the first bit of PORTB as input and the rest as outputs, and pull down that bit, and report as soon as possible. How does this thing work? (ie. why floating input pins make the pic reset?). And does the second thing (power supply bypassed at the chip) mean that i have to put a capacitor between power and ground?
for jan-erik: sorry, i'm really a beginner and don't know much, i just checked the generated asm code to see if sdcc put something to go back to the start, but didn't think about the fact the pic might do this automatically.
2005\05\13@132933
by
rumpelteazer666
nothing yet. I substituted TRISB=255; with TRISB=1; (setting as input only the last bit), and put a 220ohm resistor between PORTB0 and ground. The i use a clip to connect the 5V to PORTB0 and it plays, i disconnect the clip and it stops again until i connect it again.
2005\05\13@134114
by
John Ferrell
Configuring unused pins as output has worked for me so far.
You can tie a group of inputs together and tie them up or down through just
one resistor. Some chips can be tied directly but why take a chance?
The problem is that the inputs are generally high impedance and thus noise
susceptible. The region between "up and down" levels is considered
"undefined" so the cautious technician just does not go there!
BTW, that is a clever way of checking the output. You might also try to
alter the delay constant to see if you can change the tone frequency. If you
can, you must be coming through the program..
Gotta go offline for a few hours to deliver some junk furniture (he says
antique) to one of my nephews.
John Ferrell
http://DixieNC.US
{Original Message removed}
2005\05\13@180007
by
phil B
maybe a dumb question but have you pulled mclr high?
If its not, body capacitance can make for some rather
odd effects.
--- rumpelteazer666 <RemoveMErumpelteazer666spam_OUT
KILLspamgmail.com> wrote:
> nothing yet. I substituted TRISB=255; with TRISB=1;
> (setting as input only
> the last bit), and put a 220ohm resistor between
> PORTB0 and ground. The i
> use a clip to connect the 5V to PORTB0 and it plays,
> i disconnect the clip
> and it stops again until i connect it again.
> -
2005\05\13@201220
by
Hector Martin
|
rumpelteazer666 wrote:
> nothing yet. I substituted TRISB=255; with TRISB=1; (setting as input only
> the last bit), and put a 220ohm resistor between PORTB0 and ground. The i
> use a clip to connect the 5V to PORTB0 and it plays, i disconnect the clip
> and it stops again until i connect it again.
220ohm seems too low to me. 10K is what I use for pull-up/down. Maybe
the switching causes a glitch and resets the PIC?
Make sure your circuit is OK. You should have capacitors next+ to the
supply pins. Tie MCLR to VCC with a 10K resistor or so. Tie unused
pins either high or low (you shouldn't need a resistor since pins are
supposed to startup as inputs and nothing should happen due to a
direct connection, but you might want to use resistors to prevent a
software bug that sets them as outputs from blowing your pins). Also
make sure you are connecting your output properly to your amp. Direct
connection to a low impedance input may not be a good idea, you might
want to try capacitor coupling it to a small speaker which is usually
OK for testing. Wire a standard 8ohm small speaker in series with a
1uF capacitor, from PIC pin to ground.
Also you shouldn't just let the program "hang off" the end, even if
there is an infinite loop. Set something notable there, say set some
other output pin and wait 1 second. Then you can watch for that behaviour.
Add a delay at the beginning of the program. Set all output pins low
by default, then wait and set one of them high. wait and set another
one high and unset the first one. Wait for a button press, once
pressed set both and begin the squarewave loop. That should give you
an idea of what happens by connecting 2 LEDs to the pins (through a 1k
resistor of course.)
Oh, a thought. That is pin RB0/INT. Maybe you've got interrupts
enabled for INT input? That could potentially trigger an interrupt on
either the rising or falling edge and jump to position 0x4 in program
space, quite probably restarting the program (which usually begins at
position 0x5 with a jump at 0x0 or so). Setting INTCON=0 should kill
all interrupts
Another thing:
{Quote hidden}> _asm
> movlw _a
> movwf _d1
> Delay_0:
> decfsz _d1, f
> goto Delay_0
> nop
> nop
>
> _endasm;
That seems wrong to me. I haven't worked with C compilers but _a
should be a *register* or RAM location, NOT a literal value. So not
"movlw _a", but "movf _a,w". I think. You can also just use a constant
with movlw, but I'm guessing you would want to vary the frequency in
the future using 'a'.
I think something is quickly resetting the PIC, and instead of the
delay frequency you are really experiencing startup delays (since your
delay function looks nonfunctional due to the aforementioned detail)
which produce the output squarewave.
Greets,
--
Hector Martin (RemoveMEhectorTakeThisOuT
spammarcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc
2005\05\13@211437
by
rumpelteazer666
phil: yes i directly connected mclr to the supply voltage
hector: you are completely right! sdcc leaves the code in _asm blocks unchanged, so it actually did the movlw using the ram address as an argument. I will try everything you said; for now, before i go to bed, besides changing it with a movf, i put an INTCON=0 at the beginning, but this didn't solve the reset problem.
2005\05\13@215531
by
rumpelteazer666
but after all how could i sleep thinking about this non-working circuit... hector: i've tried random things from your list, and now it works: it was the output connection to the amplifier to ruin all, i guess it draws too much corrent. Thanks to all you guys for your advices, i think i will need your help again soon for this thing to work, but now i can go happily back to program. thanks!
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- Today
- New search...