part 1 1502 bytes content-type:text/plain; charset=iso-8859-1 (unknown type 8bit not decoded)
Hi,
I have a project that is pretty much brought to a
stand still because of this simple problem. As one of
my first real life PIC projects, I am doing an
ultrasonic range finder (every beginner has to do
one!) which is going to be used as fluid level
detector. I am using pic16f628 for it. I have
attached the cc5x program and it explains how it works
in more detail. It is fairly simple and sequential in
design. I am simulating the program in MPLAB. I
simulate a pulse on CCP1 pin to cause a capture
condition. But, the interupt never happens. CCP1IF
is never set and I never enter the serverX() function
for this interupt. Other interupts work just fine.
What am I missing? It is probably something right
under my nose that I can't see. I have also tried to
generate a real hardware interupt in a test circuit to
eliminate any doubts about bugs in MPLAB but no luck.
Any help is appreciated.
Here is some more background if it is relevant. The
US burst of 20 pulses is generated by the PWM module
at 40KHz and transmitted by a US transducer. It would
have been simpler to just keep flipping a pin of portb
but I wanted get some hands on experience with the CCP
module. The US reflected burst is received,
amplified, rectified and then interfaced to the
CCP1/RB3 pin. These circuits are already tested
independently. The reflected pulse is supposed to
cause the capture condition and thus giving me the
time of travel.
-Hasan
part 2 4716 bytes content-type:application/octet-stream; name="usranger.c" (decode)
part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)
> -Hasan,
>
> What kind of compiler are you using?
> I tried to compile in CCS IDE I got too many errors.
>
> Andre
>
>
>
>
> {Original Message removed}
I know C very well, but I've never programmed a PIC in C... Looking over
your code I don't see any obvious mistakes. Could you post the listing file
that contains the assembly statements generated by the compiler? You may get
more help this way, as the majority of people here are familiar with PIC
assembly code.
Take care, Matthew.
--
Excess on occasion is exhilarating. It prevents moderation from acquiring the
deadening effect of a habit. -- W. Somerset Maugham
> Hello Hasan,
>
> I know C very well, but I've never programmed a PIC
> in C... Looking over
> your code I don't see any obvious mistakes. Could
> you post the listing file
> that contains the assembly statements generated by
> the compiler? You may get
> more help this way, as the majority of people here
> are familiar with PIC
> assembly code.
>
> Take care, Matthew.
>
> --
> Excess on occasion is exhilarating. It prevents
> moderation from acquiring the
> deadening effect of a habit. -- W. Somerset
> Maugham
I think I have found the problem. The CCP module in capture mode uses timer1
as a resource. You haven't properly configured timer1, though you are
turning it on and off. In the 16F628 datasheet read up on timer1 and its
control register T1CON. You need to select a prescaler value, clock source,
and there are a few other bits to check.
The bit in T1CON you overlooked is called T1OSCEN. This enables or shuts-off
the oscillator for the timer.
I also have a comment about the code:
In the detectFor65ms() function I think you should order some of the
statements differently. Here is a part of that function's body:
I think you should initialize everything _before_ enabling the
interrupts. As it stands now, it is possible for a capture interrupt to
occur before the variables timeout and detected are set to zero! That means
you could miss your compare event. I would organize the above code like
this:
TMR1ON = 0;
CCP1CON = 0x05;
TRISB = 0b00001000;
#if defined DEBUG
TMR1L = 0xe0;
TMR1H = 0xff;
#endif
timeout = 0;
detected = 0;
TMR1IE = 1;
CCP1IE = 1;
PEIE = 1;
GIE = 1;
TMR1ON = 1;
When I encounter a problem like this I do two things (in this order). One,
read the datasheet throughly; be absolutely certain you understand
everything about the module you are using. Second, re-write the code, in as
simple a manner as possible, to do only thing you're having trouble with (in
your case, get rid of the timeout stuff and concentrate on the CCP module).
I hope this helps you. There may be someother problems with your code that
I've not found; I've never used the CCP module before.
Good luck, Matthew.
--
Memory is like an orgasm. Its a lot better if you dont have to fake it.
-- Seymour Cray, commenting on virtual memory
Hi,
Thanks for your advice again.
I was excited when you pointed out t1con which I had
forgotten about. Unfourtunately even after setting it
up, it didn't make any difference. I am working on a
stripped down version of the program that will have
only CCP module working in capture mode. I'll update
you later.
> Hello Hasan,
>
> I think I have found the problem. The CCP module in
> capture mode uses timer1
> as a resource. You haven't properly configured
> timer1, though you are
> turning it on and off. In the 16F628 datasheet read
> up on timer1 and its
> control register T1CON. You need to select a
> prescaler value, clock source,
> and there are a few other bits to check.
>
> The bit in T1CON you overlooked is called T1OSCEN.
> This enables or shuts-off
> the oscillator for the timer.
>
> I also have a comment about the code:
>
> In the detectFor65ms() function I think you should
> order some of the
> statements differently. Here is a part of that
> function's body:
>
> TMR1ON = 0;
> CCP1CON = 0x05;
>
> TMR1IE = 1;
> CCP1IE = 1;
> PEIE = 1;
> GIE = 1;
> timeout = 0;
> detected = 0;
> TMR1ON = 1;
> #if defined DEBUG
> TMR1L = 0xe0;
> TMR1H = 0xff;
> #endif
> TRISB = 0b00001000;
>
> I think you should initialize everything _before_
> enabling the
> interrupts. As it stands now, it is possible for a
> capture interrupt to
> occur before the variables timeout and detected are
> set to zero! That means
> you could miss your compare event. I would organize
> the above code like
> this:
>
> TMR1ON = 0;
> CCP1CON = 0x05;
> TRISB = 0b00001000;
>
> #if defined DEBUG
> TMR1L = 0xe0;
> TMR1H = 0xff;
> #endif
>
> timeout = 0;
> detected = 0;
>
> TMR1IE = 1;
> CCP1IE = 1;
> PEIE = 1;
> GIE = 1;
>
> TMR1ON = 1;
>
> When I encounter a problem like this I do two things
> (in this order). One,
> read the datasheet throughly; be absolutely certain
> you understand
> everything about the module you are using. Second,
> re-write the code, in as
> simple a manner as possible, to do only thing you're
> having trouble with (in
> your case, get rid of the timeout stuff and
> concentrate on the CCP module).
>
> I hope this helps you. There may be someother
> problems with your code that
> I've not found; I've never used the CCP module
> before.
>
> Good luck, Matthew.
>
> --
> Memory is like an orgasm. Its a lot better if you
> dont have to fake it.
> -- Seymour Cray, commenting on virtual memory
On Thu, Jun 09, 2005 at 09:47:33PM -0700, Hasan A. Khan wrote:
> Hi,
> Thanks for your advice again.
> I was excited when you pointed out t1con which I had
> forgotten about. Unfourtunately even after setting it
> up, it didn't make any difference. I am working on a
> stripped down version of the program that will have
> only CCP module working in capture mode. I'll update
> you later.
Good, if you have any trouble just start a new thread. I would also suggest
that since you are just learning the CCP module, debugging, and such; to
write your test program in assembly and not C. This will make it easier for
others to help you and improve your learning. Once you have things
straightened out you could switch back to C. :)
Matthew.
--
"The test of a first-rate intelligence is the ability to hold two opposed
ideas in mind at the same time and still retain the ability to function. One
should, for example, be able to see that things are hopeless and yet be
determined to make them otherwise."
> I would also suggest that since you are just learning the CCP module,
> debugging, and such; to write your test program in assembly and not C.
> This will make it easier for others to help you and improve your
> learning. Once you have things straightened out you could switch back to
> C. :)
This is definitely a possible approach, probably good for some, but
possibly not the best for all... :)
[Before you flame me, please consider this :) The following is not a
C-vs-Assembler discussion, as far as development environments go. I'm very
well aware that both have their place, within project, company and
individual preferences and requirements. It is a reply to the point made
that it is helpful to write an assembler program when the desired target
environment is C.]
I would stick to C. If you have a decent compiler, you can rely on the
infrastructure to work and you don't have to worry about it all (startup
code, interrupt entry/exit code, memory banks, code pages). Considering
that C is your target environment, there's really not much of a point to
get deeper into those issues, other than knowing what it is about and being
able to read and understand what the compiler does with that. Which is
somewhat different from programming it yourself in assembler.
I know that there are many people here who use only assembler, and maybe
it's easier to tap into their experience when using assembler. OTOH the
code you presented is probably readable for an assembler programmer just as
well.
I haven't written a single assembler program for the PIC. I have written a
number of assembler code parts, but not many, and always within the
framework of a C program. I have never found a problem that would require
me to write an assembler program to tackle it -- or even that would make it
easier to find in an assembler program. I prefer the ease of use of C,
especially for debugging problems. Since C is my target environment, I have
my debugging aids in that environment. Of course, I have found a number of
bugs (in both my code and in the compiler) by looking at (and
understanding) the assembler code in the compiler-generated list files.
------------------------------------------
Just out of curiosity: There are programmers who only work in assembler.
There are programmers who only work in C (or Jal or Basic or whatever
semi-high level language). There are programmers who work mostly in C (or
whatever semi-high level language) and some in assembler.
But are there programmers who work mostly in assembler and only some in a
semi-high level language like C? I would think not, but I'd like to hear if
there are -- and why they're doing it this way.
Well, I have resolved the problem but I don't know why
it is working :-o
There is a function in the probram that generates a
burst of pulses by using the PWM module (I wanted to
learn PWM module). All I did was the disable ccp
module by setting CCP1CON=0 when I was done with PWM
module. I still don't know how this is related to
interupts on the ccp1 pin but it fixed my problem.
> Hi,
> Thanks for your advice again.
> I was excited when you pointed out t1con which I had
> forgotten about. Unfourtunately even after setting
> it
> up, it didn't make any difference. I am working on
> a
> stripped down version of the program that will have
> only CCP module working in capture mode. I'll
> update
> you later.
>
>
> --- Matthew Miller <EraseMEnamiller2spam_OUTTakeThisOuTnaxs.net> wrote:
>
> > Hello Hasan,
> >
> > I think I have found the problem. The CCP module
> in
> > capture mode uses timer1
> > as a resource. You haven't properly configured
> > timer1, though you are
> > turning it on and off. In the 16F628 datasheet
> read
> > up on timer1 and its
> > control register T1CON. You need to select a
> > prescaler value, clock source,
> > and there are a few other bits to check.
> >
> > The bit in T1CON you overlooked is called T1OSCEN.
> > This enables or shuts-off
> > the oscillator for the timer.
> >
I have background in high level programming languages
like Java and C/C++ and I am aware of advantages of
HLL. I have also written enough assembler programs to
know, I am much more productive in C than assemblers.
So, I am going to stick to C for now. I'll use
assemblers when forced to by some need. May be after
a lot of experience and knowledge people become so
good that they are equally productive in assembler but
I am not there yet.
> Matthew Miller wrote:
>
> > I would also suggest that since you are just
> learning the CCP module,
> > debugging, and such; to write your test program in
> assembly and not C.
> > This will make it easier for others to help you
> and improve your
> > learning. Once you have things straightened out
> you could switch back to
> > C. :)
>
> This is definitely a possible approach, probably
> good for some, but
> possibly not the best for all... :)
>
> [Before you flame me, please consider this :) The
> following is not a
> C-vs-Assembler discussion, as far as development
> environments go. I'm very
> well aware that both have their place, within
> project, company and
> individual preferences and requirements. It is a
> reply to the point made
> that it is helpful to write an assembler program
> when the desired target
> environment is C.]
>
> I would stick to C. If you have a decent compiler,
> you can rely on the
> infrastructure to work and you don't have to worry
> about it all (startup
> code, interrupt entry/exit code, memory banks, code
> pages). Considering
> that C is your target environment, there's really
> not much of a point to
> get deeper into those issues, other than knowing
> what it is about and being
> able to read and understand what the compiler does
> with that. Which is
> somewhat different from programming it yourself in
> assembler.
>
> I know that there are many people here who use only
> assembler, and maybe
> it's easier to tap into their experience when using
> assembler. OTOH the
> code you presented is probably readable for an
> assembler programmer just as
> well.
>
> I haven't written a single assembler program for the
> PIC. I have written a
> number of assembler code parts, but not many, and
> always within the
> framework of a C program. I have never found a
> problem that would require
> me to write an assembler program to tackle it -- or
> even that would make it
> easier to find in an assembler program. I prefer the
> ease of use of C,
> especially for debugging problems. Since C is my
> target environment, I have
> my debugging aids in that environment. Of course, I
> have found a number of
> bugs (in both my code and in the compiler) by
> looking at (and
> understanding) the assembler code in the
> compiler-generated list files.
>
> ------------------------------------------
>
> Just out of curiosity: There are programmers who
> only work in assembler.
> There are programmers who only work in C (or Jal or
> Basic or whatever
> semi-high level language). There are programmers who
> work mostly in C (or
> whatever semi-high level language) and some in
> assembler.
>
> But are there programmers who work mostly in
> assembler and only some in a
> semi-high level language like C? I would think not,
> but I'd like to hear if
> there are -- and why they're doing it this way.
>
> Gerhard
I write every single PIC program I ever have done in assembler. The
only time I use C compilers is when there is something that is easily
done in C, which is quite complicated in assembler - in some cases
it's useful to use the C compiler and check the output assembler to
see how it's done.
However, when working on computer programs (i.e. x86), I always use C
or visual basic - I have never found a good reference for 32bit
assembler.
> Matthew Miller wrote:
>
> > I would also suggest that since you are just learning the CCP module,
> > debugging, and such; to write your test program in assembly and not C.
> > This will make it easier for others to help you and improve your
> > learning. Once you have things straightened out you could switch back to
> > C. :)
>
> This is definitely a possible approach, probably good for some, but
> possibly not the best for all... :)
>
> [Before you flame me, please consider this :) The following is not a
> C-vs-Assembler discussion, as far as development environments go. I'm very
> well aware that both have their place, within project, company and
> individual preferences and requirements. It is a reply to the point made
> that it is helpful to write an assembler program when the desired target
> environment is C.]
>
> I would stick to C. If you have a decent compiler, you can rely on the
> infrastructure to work and you don't have to worry about it all (startup
> code, interrupt entry/exit code, memory banks, code pages). Considering
> that C is your target environment, there's really not much of a point to
> get deeper into those issues, other than knowing what it is about and being
> able to read and understand what the compiler does with that. Which is
> somewhat different from programming it yourself in assembler.
>
> I know that there are many people here who use only assembler, and maybe
> it's easier to tap into their experience when using assembler. OTOH the
> code you presented is probably readable for an assembler programmer just as
> well.
>
> I haven't written a single assembler program for the PIC. I have written a
> number of assembler code parts, but not many, and always within the
> framework of a C program. I have never found a problem that would require
> me to write an assembler program to tackle it -- or even that would make it
> easier to find in an assembler program. I prefer the ease of use of C,
> especially for debugging problems. Since C is my target environment, I have
> my debugging aids in that environment. Of course, I have found a number of
> bugs (in both my code and in the compiler) by looking at (and
> understanding) the assembler code in the compiler-generated list files.
>
> ------------------------------------------
>
> Just out of curiosity: There are programmers who only work in assembler.
> There are programmers who only work in C (or Jal or Basic or whatever
> semi-high level language). There are programmers who work mostly in C (or
> whatever semi-high level language) and some in assembler.
>
> But are there programmers who work mostly in assembler and only some in a
> semi-high level language like C? I would think not, but I'd like to hear if
> there are -- and why they're doing it this way.
>
> Gerhard
>I write every single PIC program I ever have done in assembler. The
>only time I use C compilers is when there is something that is easily
>done in C, which is quite complicated in assembler - in some cases
>it's useful to use the C compiler and check the output assembler to
>see how it's done.
>
>However, when working on computer programs (i.e. x86), I always use C
>or visual basic - I have never found a good reference for 32bit
>assembler.
>
>
> Well, I have resolved the problem but I don't know why
> it is working :-o
>
> There is a function in the probram that generates a
> burst of pulses by using the PWM module (I wanted to
> learn PWM module). All I did was the disable ccp
> module by setting CCP1CON=0 when I was done with PWM
> module. I still don't know how this is related to
> interupts on the ccp1 pin but it fixed my problem.
That's a typical situation, and Matthew's advice to separate things and
test the code that talks to the PIC's hardware one hardware module at a
time is definitely a good advice -- independently of whether you do it in C
or assembler.
This probably won't be the last time that you experience something like
this. Get used to it... :)
> when working on computer programs (i.e. x86), I always use C or
> visual basic - I have never found a good reference for 32bit assembler.
>
Really? The x86 is quite pleasant to program in assembler, and I didn't
think there was any shortage of applicable books. (Hmm. Interesting
thought for intel: embedded x86; not like their x186, but with included
ram and flash and "useful" microcontroller peripherals...) It does have
the usual CISC issues - too many instructions that can be used to do the
same thing; just the thing to make an assembler programmer feel like
they're
really making useful decisions that a compiler wouldn't...
OTOH, a modern windows GUI program is more about setting up big data
structures as arguments to arcane library and OS functions. The sort
of thing that is inconvenient and annoying to do in assembler, and not
worth the effort. Also, I don't know if I've ever seen a reference for
the windows OS API (as opposed to the standard library APIs...)
On Sat, Jun 11, 2005 at 09:24:48AM -0300, Gerhard Fiedler wrote:
>
> I know that there are many people here who use only assembler, and maybe
> it's easier to tap into their experience when using assembler. OTOH the
> code you presented is probably readable for an assembler programmer just as
> well.
This is the reason I suggested assembler; more poeple know it on this
list. I didn't have too much trouble with his C code, but one thing struck
me as odd. To turn timer 1 off, this was being written (which I guess was
valid for his compiler):
TMR1ON = 0;
Having never programmed a PIC in C I would have expected this to be written
in this way:
T1CON.TMR1ON = 0;
I don't care much for the shortcut his compiler supports.
Take care, Matthew.
--
"The soft-minded man always fears change. He feels security in the status
quo, and he has an almost morbid fear of the new. For him, the greatest pain
is the pain of a new idea."
Hi,
I am using CC5x. This is because at the time I was
only aware of this free compiler. I can't justify
cost of a professional compiler since I build
projects at level of "serious hobbist" and earn no
income from it. When I first started using CC5x, I
had written code just as you say T1CON.TMR1ON = 0 but
the compiler gave a syntax error. I am going to
evaluate SDCC and see how that measures up.
Anyway, thank for you help. I have learned a lot from
from people like you on this list already. I hope to
become good enough to help others someday...soon.
> Hello,
>
> On Sat, Jun 11, 2005 at 09:24:48AM -0300, Gerhard
> Fiedler wrote:
> >
> > I know that there are many people here who use
> only assembler, and maybe
> > it's easier to tap into their experience when
> using assembler. OTOH the
> > code you presented is probably readable for an
> assembler programmer just as
> > well.
>
> This is the reason I suggested assembler; more
> poeple know it on this
> list. I didn't have too much trouble with his C
> code, but one thing struck
> me as odd. To turn timer 1 off, this was being
> written (which I guess was
> valid for his compiler):
>
> TMR1ON = 0;
>
> Having never programmed a PIC in C I would have
> expected this to be written
> in this way:
>
> T1CON.TMR1ON = 0;
>
> I don't care much for the shortcut his compiler
> supports.
>
> Take care, Matthew.
>
> --
> "The soft-minded man always fears change. He feels
> security in the status
> quo, and he has an almost morbid fear of the new.
> For him, the greatest pain
> is the pain of a new idea."
>
> -- Rev. Dr. Martin Luther King Jr.
On Mon, Jun 13, 2005 at 02:45:55AM -0700, Hasan A. Khan wrote:
>
> I am using CC5x. This is because at the time I was
> only aware of this free compiler. I can't justify
> cost of a professional compiler since I build
> projects at level of "serious hobbist" and earn no
> income from it.
Yeah, the cost of a compiler is largely the reason that I still use assembly
(this, and my projects have been small enough to not need a high level
language.) I've been thinking about the C compiler and tools offered by
Forest Electronics. Their prices aren't too bad for a hobbyist, IMO. Here is
their website: http://www.fored.co.uk/
Take care, Matthew.
--
"Thoughtcrime was not a thing that could be concealed forever. You might
dodge successfully for a while, even for years, but sooner or later they were
bound to get you." -- George Orwell, _1984_
Ha ha!! Ok, that made me laugh. :) You're not the first online person to
make this comment about how I sign my messages. Trying to think back, I
don't know how I got the habit/style I use. ?? Perhaps I should sign like
this:
Take care.
Matthew
--
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
-- Benjamin Franklin, _Historical_Review_of_Pennsylvania_, 1759.
Lol, yeah, now I come to think of it like that, it makes a bit more
sense. I thought it was a script like the many scripts i have running
on IRC etc. which often malfuntion and make me say hi to myself, etc..
Now that I come to think of it, I probably should make a script to
say hi to people in emails.
> Hi Dave,
>
> On Mon, Jun 13, 2005 at 05:25:24PM +0100, RemoveMEdave.w.turnerEraseMEEraseMEgmail.com wrote:
> > On 6/13/05, Matthew Miller <RemoveMEnamiller2spam_OUTKILLspamnaxs.net> wrote:
> >
> > Take care, Matthew.
> >
> > ??????
> >
> > Is that a script or something? Or do you have duel personalities ;-).
>
> Ha ha!! Ok, that made me laugh. :) You're not the first online person to
> make this comment about how I sign my messages. Trying to think back, I
> don't know how I got the habit/style I use. ?? Perhaps I should sign like
> this:
>
> Take care.
>
> Matthew
>
> --
> "They that can give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
>
> -- Benjamin Franklin, _Historical_Review_of_Pennsylvania_, 1759.
ditechnology.com> wrote:
