Exact match. Not showing close matches.
'[PIC] Table Read Confusion'
I have a stupid (newbish) question about table read using TBLPTRU,
TBLPTRH, and TBLPTRL. I understand what they do and how to use them.
The question is: if I need to read the table in the interrupt, is it a good
idea for me to store the original values of TBLPTRs or should I disable
interrupts when I need to do program flash memory reads/write in the main
loop (like a critical section in x86)?
Also, shouldn't this problem also apply to FSRnH / FSRnL? How come the
manual doesn't mention this at all?
In the example in the PIC18 Reference, the manual only mention to save
~Terry (Seitai) Chen
> In the example in the PIC18 Reference, the manual only mention
> to save WREG/STATUS/BSR...
You store what might change. If an FSR or a TBL pointer is
used both inside and outside the ISR and you want to retain it,
then save it. If TBLPTR is not used outside the ISR then it isn't
going to change (except when you change it within the ISR).
That applies to any other register or variable
In the case of WREG/STATUS/BSR... they will probably change,
you save them, so that when PC returns back to outside the ISR
(via the ISR context restore) the values in WREG/STATUS/BSR...
are as they were before the interrupt
When writing to Flash, instruction execution is halted by the micro
during the write, so you can't enter an ISR during the write anyway.
Hardware flags will be set so that IRQ processing resumes as soon
as the write is complete. Whether you're inside or outside the ISR,
reading Flash shouldn't be affected. An ISR is just a piece of code.
Where you can make a difference is what you do at the point of an
IRQ. If you're executing sensitive code, then temporarily suspend
IRQs. When you re-enable them, any IF set will be processed
Terry Chen wrote:
> The question is: if I need to read the table in the interrupt, is it
> a good idea for me to store the original values of TBLPTRs or should
> I disable interrupts when I need to do program flash memory
> reads/write in the main loop (like a critical section in x86)?
Either method works. This is true of any such register that may be used in
both the interrupt and foreground routines, not just the TBLPTR.
> Also, shouldn't this problem also apply to FSRnH / FSRnL?
Of course, and to PRODL/PRODH, PCLATH/PCLATU, and to anything else that
might get used in both places. It's no different than the contention for W,
STATUS, and BSR if you think about it. It's just those are pretty much
guaranteed to be contentions so they are mentioned more.
> How come the
> manual doesn't mention this at all?
It can't mention everything. It does describe how things work enough so
that you can figure this out on your own. Also my PIC 18 interrupt routine
template QQQ_INTR18.ASPIC at http://www.embedinc.com/pic takes care of some
of these issues. It has constants at the top where you expclicitly tell it
which FSRs to save/restore in which interrupts.
Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
consultant in 2004 program year. http://www.embedinc.com/products
Terry Chen wrote :
Others have well enough replyed on saving
regs in general. I'd just like to comment on :
> In the example in the PIC18 Reference, the manual only
> mention to save WREG/STATUS/BSR...
Note that if you're running with *one* interrupt priority
level (quite normal, I think), *and* you are using
"RETFIE FAST", you don't have to worry about
WREG, STATUS and BSR, they are taken care of
automaticly with no overhead (time wise).
I think I understand now. Everyone, thanks alot for helping me! :-)
I hope all of you guys have a merry holidays!
By the way, Olin, I have been looking over the macros you have
I will definitely be using them in the near future. The banking macros
On 12/22/05, Jan-Erik Soderholm <telia.com> wrote: jan-erik.soderholm
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...