A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
Interaction between TRISB and INTCON on a 16f876A - Chris - Oct 4 19:26:00 2005
Hello, I'm posting here in the hope that someone can tell me what I'm
doing wrong.
I have some code which BANKSEL's the TRISB register whilst on page1
of memory like this
banksel TRISB
movlw b'11111111'
movwf TRISB
I was having problems with too many interupts being created and so
used SIM mode of MPLAB. WHen I open a watch window with INTCON in it
I was amazed to see that as the code stepped the line immediately
aftre movwf TRISB that INTCON bit 0 became set, and a line after
that INTCON,1 too, but it doesn't always happen on each pass, plus an
interupt doesn't seem to take place immediately
My INTCON intialisation is to b'1010000', so you can see that I
shouldn't even be getting RBIF set !
I'm wondering if the problem is a paging issue in which case I'll be
pleased to hear the simple solution.
Thanks in advance
Chris

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - mikerey35475 - Oct 4 22:59:00 2005
--- In piclist@picl..., "Chris" <fixitsan@a...> wrote:
> Hello, I'm posting here in the hope that someone can tell me what I'm
> doing wrong.
>
> I have some code which BANKSEL's the TRISB register whilst on page1
> of memory like this
>
> banksel TRISB
> movlw b'11111111'
> movwf TRISB
>
> I was having problems with too many interupts being created and so
> used SIM mode of MPLAB. WHen I open a watch window with INTCON in it
> I was amazed to see that as the code stepped the line immediately
> aftre movwf TRISB that INTCON bit 0 became set, and a line after
> that INTCON,1 too, but it doesn't always happen on each pass, plus an
> interupt doesn't seem to take place immediately
>
> My INTCON intialisation is to b'1010000', so you can see that I
> shouldn't even be getting RBIF set !
>
> I'm wondering if the problem is a paging issue in which case I'll be
> pleased to hear the simple solution.
>
> Thanks in advance
> Chris
Possible simple explanation,
> My INTCON intialisation is to b'1010000'
Bit 7 is GLOBAL interrupt enable, which enables all non-peripheral
interrupts i.e. RB interupt-on-change and RB0/INT external interrupt.
When i/o pins are outputs these interrupts are disabled/ignored, when
i/o pins are inputs
> banksel TRISB
> movlw b'11111111'
> movwf TRISB
these interrupts are enabled and a change in pin state will set the
flag bit in INTCON and generate an interrupt if the state change
occurs prior to Tcy3 I believe it is. Therefore a floating input pin
in a noisy environment could cause this, or if port b internal
pull-ups are enabled they might cause this to occur.
Just my thoughts, could be way off track.
Mike

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - Chris - Oct 5 10:33:00 2005
--- In piclist@picl..., "mikerey35475" <mwrey@b...> wrote:
> --- In piclist@picl..., "Chris" <fixitsan@a...> wrote:
> > Hello, I'm posting here in the hope that someone can tell me
what I'm
> > doing wrong.
> >
> > I have some code which BANKSEL's the TRISB register whilst on
page1
> > of memory like this
> >
> > banksel TRISB
> > movlw b'11111111'
> > movwf TRISB
> >
> > I was having problems with too many interupts being created and
so
> > used SIM mode of MPLAB. WHen I open a watch window with INTCON
in it
> > I was amazed to see that as the code stepped the line
immediately
> > aftre movwf TRISB that INTCON bit 0 became set, and a line
after
> > that INTCON,1 too,
>
> Bit 7 is GLOBAL interrupt enable, which enables all non-peripheral
> interrupts i.e. RB interupt-on-change and RB0/INT external
interrupt.
>
> When i/o pins are outputs these interrupts are disabled/ignored,
when
> i/o pins are inputs
>
> > banksel TRISB
> > movlw b'11111111'
> > movwf TRISB
>
> these interrupts are enabled and a change in pin state will set the
> flag bit in INTCON and generate an interrupt if the state change
> occurs prior to Tcy3 I believe it is. Therefore a floating input
pin
> in a noisy environment could cause this, or if port b internal
> pull-ups are enabled they might cause this to occur.
>
> Just my thoughts, could be way off track.
>
> Mike
Thanks Mike, but as far as I know the portb change interupt can only
take place if the 'portb pin change interupt enable' flag, intcon
bit 3, is set. The symptoms I have are that the portb pin change
flag is being set even though the interupt for that event is
disabled !
I'm trying to see if theres a correlation between teh address of the
TRISB register on one memory page and the INTCON register on another
but there doesn't seem to be, INTCON is on every page and at the
same location, relatively speaking
Now, since writing that message last night I I've replaced....
movlw b'11111111'
movwf trisb
with ....
bsf trisb,0
bsf trisb,1
bsf trisb,2
and so on....setting the pins individually supposedly takes the
write buffer out of the equation.
Bit INTCON,0 doesn't change until the code reaches 'bsf trisb,5'.
There's nothing different about trisb,5 that isn't included on
trisb,4 and yet trisb 4 could create a portb pin change interupt too.
The only other different thing is that the USART uses pin portb,5
but not portb,4 BUT the USART isn't implemented in my code.
It's very bizarre
Chris

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - rtstofer - Oct 5 11:30:00 2005
> Bit INTCON,0 doesn't change until the code reaches 'bsf trisb,5'.
> There's nothing different about trisb,5 that isn't included on
> trisb,4 and yet trisb 4 could create a portb pin change interupt too.
>
> The only other different thing is that the USART uses pin portb,5
> but not portb,4 BUT the USART isn't implemented in my code.
>
> It's very bizarre
> Chris
If I read your previous post correctly, you are enabling Timer0 and
global interrupts. The fact that RBIF gets set doesn't matter because
RBIE isn't enabled.
So, could it be that the reason you don't get this every time and it
seems random be related to whatever is happening with Timer 0?
There are only 3 things that can cause an interrupt if you don't
enable peripheral interrupts. I would send part of INTCON to some
LEDs on the first interrupt so I could see which of the 3
possibilities caused the interrupt. But, I would bet on Timer 0 since
it is the only one that is enabled.
It is certainly unlikely that you are getting an RB interrupt if it
isn't enabled. Heck, I might output the entire INTCON to LEDs because
there is a chance it is getting changed. Some other instruction could
use an ORGd address that just happens to be INTCON.
Richard

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - Chris - Oct 5 16:07:00 2005
--- In piclist@picl..., "rtstofer" <rstofer@p...> wrote:
>
> > Bit INTCON,0 doesn't change until the code reaches 'bsf trisb,5'.
> > There's nothing different about trisb,5 that isn't included on
> > trisb,4 and yet trisb 4 could create a portb pin change interupt
too.
> >
> > The only other different thing is that the USART uses pin portb,5
> > but not portb,4 BUT the USART isn't implemented in my code.
> >
> > It's very bizarre
> > Chris
>
> If I read your previous post correctly, you are enabling Timer0 and
> global interrupts. The fact that RBIF gets set doesn't matter
because
> RBIE isn't enabled.
Okay so the intcon,0 bit can get set but no interupt actually happens
if intcon,3 is not set. Understood.
> So, could it be that the reason you don't get this every time and
it
> seems random be related to whatever is happening with Timer 0?
I sincerely would hope not. i don't like the thought that tmr0 can
access or affect any intcon bit other than it's own. I'll think on it
though.
>
> There are only 3 things that can cause an interrupt if you don't
> enable peripheral interrupts. I would send part of INTCON to some
> LEDs on the first interrupt so I could see which of the 3
> possibilities caused the interrupt. But, I would bet on Timer 0
since
> it is the only one that is enabled.
>
> It is certainly unlikely that you are getting an RB interrupt if it
> isn't enabled. Heck, I might output the entire INTCON to LEDs
because
> there is a chance it is getting changed.
It's a lot of trouble to do that though it does make sense. the
problem is that I'll have to introduce a lot of breaks in the running
so that I can see it change one step from the next.
i thought that I would be able to see it with the SIM mode of mplab.
I'm starting to wonder if it's not a bug with the simulator on the pc
which won't actually appear when run on the chip. Or maybe it's
wishful thinking ?!!
Some other instruction could
> use an ORGd address that just happens to be INTCON.
Thats a good point, I've adjusted my ORGs because they were in fact
off a little bit. i was using a code segment from another program,
that's my own fault.
The code doesn't run now unless I clear PCLATH bits 3 and 4 at the
start of the interupt routine, after saving pclath first and
restoring it after the interupt.
I'm making some changes but I don't know why they don't make the
expected results anymore.
Chris
> Richard

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - rtstofer - Oct 5 22:41:00 2005
>
> Thats a good point, I've adjusted my ORGs because they were in
fact
> off a little bit. i was using a code segment from another program,
> that's my own fault.
In my view you should never use ORG to define the address of a
variable. Every time I see it in one of the PICs for Dummies type
of books I just cringe. The proper way to allocate RAM storage is
with CBLOCK.
To further refine the process I define:
BYTE EQU 1
WORD EQU 2
then
CBLOCK 0x0020
Var1: BYTE
Var2: BYTE
Var3: WORD
ENDC
The only opportunity to mess up the addresses is with the address
parameter of CBLOCK
>
> The code doesn't run now unless I clear PCLATH bits 3 and 4 at the
> start of the interupt routine, after saving pclath first and
> restoring it after the interupt.
Yes, you are probably on a different code page when the interrupt
occurs. No big deal. In fact, if there are no GOTO or CALL
instructions in the interrupt routine, you don't have to worry about
PCLATH. But there usually are...
>
> I'm making some changes but I don't know why they don't make the
> expected results anymore.
As to the Timer 0 interrupt, don't enable it if you don't want it to
happen!
I wouldn't spend too much time worrying about what happens in the
simulator. I don't trust that type of thing and only use it when I
can't get there any other way.
My approach is LEDs and serial IO. Even if the LED blinks too fast
to see, I can catch it on a scope or logic analyzer. I also time my
interrupt routine by setting a bit on entry and clearing it on exit.
This can be critical if you are running some time of task switching
software.
>
> Chris
>
>
> > Richard

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - rtstofer - Oct 6 2:11:00 2005
Oops!
Should read "In my view you should never use EQU..."
> In my view you should never use ORG to define the address of a
> variable. Every time I see it in one of the PICs for Dummies type
> of books I just cringe. The proper way to allocate RAM storage is
> with CBLOCK.
>
> To further refine the process I define:
>
> BYTE EQU 1
> WORD EQU 2
>
> then
>
> CBLOCK 0x0020
> Var1: BYTE
> Var2: BYTE
> Var3: WORD
> ENDC
>
> The only opportunity to mess up the addresses is with the address
> parameter of CBLOCK
> >
> > The code doesn't run now unless I clear PCLATH bits 3 and 4 at
the
> > start of the interupt routine, after saving pclath first and
> > restoring it after the interupt.
>
> Yes, you are probably on a different code page when the interrupt
> occurs. No big deal. In fact, if there are no GOTO or CALL
> instructions in the interrupt routine, you don't have to worry
about
> PCLATH. But there usually are...
>
> >
> >
> > I'm making some changes but I don't know why they don't make the
> > expected results anymore.
>
> As to the Timer 0 interrupt, don't enable it if you don't want it
to
> happen!
>
> I wouldn't spend too much time worrying about what happens in the
> simulator. I don't trust that type of thing and only use it when
I
> can't get there any other way.
>
> My approach is LEDs and serial IO. Even if the LED blinks too
fast
> to see, I can catch it on a scope or logic analyzer. I also time
my
> interrupt routine by setting a bit on entry and clearing it on
exit.
>
> This can be critical if you are running some time of task
switching
> software.
> >
> > Chris
> >
> >
> >
> >
> > > Richard

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Interaction between TRISB and INTCON on a 16f876A - Chris - Oct 6 6:08:00 2005
--- In piclist@picl..., "rtstofer" <rstofer@p...> wrote:
> Oops!
>
> Should read "In my view you should never use EQU..."
>
> >
> > In my view you should never use ORG to define the address of a
> > variable. Every time I see it in one of the PICs for Dummies
type
> > of books I just cringe. The proper way to allocate RAM storage
is
> > with CBLOCK.
> >
> > To further refine the process I define:
> >
> > BYTE EQU 1
> > WORD EQU 2
> >
> > then
> >
> > CBLOCK 0x0020
> > Var1: BYTE
> > Var2: BYTE
> > Var3: WORD
> > ENDC
Yes I only use CBLOCK for variables. My use of ORG statements was a
reference to the way I ORG program code to locate it at the start
of the 2k code pages, which elliminates any problems created by
runtime code crossing pages.
I do need tmr0 because the device has a software RTC, so I have to
have the tmr0 interupt running and therefore have to have the global
interupt bit set.
All in all I use both PWM outputs, 1 a/d input and tmr0. The only
interupt I need is tmr0 and the a/d is left to idle until required,
once per second the a/d read command bit is toggled to instigate a
new read. It wouldn't be a problem to turn off the a/d between reads
if that were the cause, but I don't think i should have to turn off
the a/d just to find out, and what's going to happen after i turn it
on again ? !!!
i have 2k page org values of 00h,800h and 1000h for bank 0,1 and two
which is, apparently, correct for the 16f876A.
It's more likely to be a problem in some other way such as a stack
handling error or perhaps other finger trouble. I'm going to read
over my (40+) pages of code now, slowly.
Chris

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Interaction between TRISB and INTCON on a 16f876A - Aaron - Oct 6 9:33:00 2005
rtstofer wrote:
>The proper way to allocate RAM storage is with CBLOCK.
>
Be careful or you'll have somebody espousing the benefits of the linker
and relocatable code.... :) :)
Aaron

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
little of topic but.... how to program a 93l46 with com1: - Lez - Oct 7 10:04:00 2005
My programmer just ignores the 93l46, or the software does, esp as it
has no setting for it!
Can anyone point me to where I can get a simple schem to program a 93L46
off the serial port (or lpt if I have to)
And software of course!

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )