Exact match. Not showing close matches.
'[PIC] Re: PIC18 jump tables'
On Fri, Jan 13, 2012 at 2:43 PM, Steve Willoughby <alchemy.com> wrote: steve
> I'm trying to implement my first PIC18 project (after spending all my
> PIC work so far in the PIC16 family). Â So far it's a big improvement but
> I'm having a little trouble figuring out the best way to do jump tables
> in this architecture.
> I have three questions around this which I haven't seen anything
> specific to the PIC18 family in my searching so far:
One thing I would recommend is using the MPLAB simulator to step
through your code. This should work very well for illustrating what
the PIC is doing internally.
You can pretty much do the same jump table as you might got used to it on
the 16F using math operation on the PCLATU:PCLATH:PCL, except that:
1. On a 18F the addressing of he program memory is in bytes, not in words
-- and as 1 word is 16 bit on a 18F you need to count 2 bytes per
2. However, there are 2 word sized instructions such as GOTO, CALL, MOVFF
etc (use BRA and RCALL instead if you can)
3. You may also want to study the CALLW instruction which is a good thing
in many times
On 15 January 2012 13:19, M.L. <lkeng.net> wrote: m
For some reason I didn't receive the original post
ML's reply Subject is
[PIC] Re: PIC18 jump tables
Re: [PIC] Re: PIC18 jump tables
Looking in the archives I notice that I didn't receive several
others, including [TECH]
> Check your subscription options. There are options for which
> tags you want to subscribe to as well as an option for whether
> you want to receive posts with no tag.
I'm subscribed for everything, always have been
And for example I didn't get the threads
[OT] Microsoft Outlook email received time issue
[TECH] 1.1TeraHz xmtr
and several other [TECH]
I've not purposely changed my subscription but I'll check it
Missing only some [OT] and [PIC] posts is unusual, especially
as others did receive them because I see their replies
I've noticed two things about the Piclist lately. First is that spam
traffic is waaaay up. Since Christmas/New Year. The general public
doesn't see it, but from observing the admin channel it's dramatic. And
messages are being dumped or delayed by up to 12 hours. Basically the
mail queue is full and the servers are way overloaded.
On Mon, Jan 16, 2012, at 12:08 PM, IVP wrote:
-- http://www.fastmail.fm - Access all of your messages and folders
wherever you are
On Sun, Jan 15, 2012 at 6:08 PM, IVP <clear.net.nz> wrote: joecolquitt
> For some reason I didn't receive the original post
> ML's reply Subject is
> [PIC] Re: PIC18 jump tables
> Tamas' is
> Re: [PIC] Re: PIC18 jump tables
> Looking in the archives I notice that I didn't receive several
> others, including [TECH]
The OP's message was missing the [PIC] tag, which I added. It had no tag at all.
-- Martin K
> I've noticed two things about the Piclist lately
Thanks, looks like you're aware of some unusual goings-on
Just thought it was worth a mention. I'll leave it in the Admins'
> The OP's message was missing the [PIC] tag, which I added. It
> had no tag at all
Checked my subscription - [TECH] and 'no tag' were unticked
Not by me though, and it must have happened fairly recently
Oh well, back to normal now I hope
|My apologies for not putting [PIC] in the subject in my OP. Oops. Anyway,
On 15-Jan-12 05:19, M.L. wrote:
> One thing I would recommend is using the MPLAB simulator to step
> through your code. This should work very well for illustrating what
> the PIC is doing internally.
Good suggestion. From experimenting with this, it looks like once you set up TBLPTRU:TBLPTRH:TBLPTRL, doing math on TBLPTR just affects the TBLPTRL 8-bit portion only. In other words, if the full pointer is
0x0012f4, and you add 0x10 to TBLPTR, you get 0x001204, not 0x001304.
On the other hand, if (and apparently only if) you use the TBLRD operations with pre/post increment (e.g., TBLRD *+), that will affect the entire set of registers, incrementing 0x0012ff to 0x001300.
On the question of what's best practice for jump tables, I was able to get all of them to work (RETLW blocks, TBLRDs, etc) so I'm just leaving it up to what makes sense in each situation, lacking any compelling reason to prefer one over the others. I would say that if there is a large number of entries in the branch table or alignment to 256-byte boundaries is a problem, just storing a block of PCLATU:PCLATH:PCL value tuples and using TBLRD on them makes sense.
Thanks for the help!
-- Steve Willoughby / alchemy.comsteve
"A ship in harbor is safe, but that is not what ships are built for."
PGP Fingerprint 4615 3CCE 0F29 AE6C 8FF4 CA01 73FE 997A 765D 696
More... (looser matching)
- Last day of these posts
- In 2012
, 2013 only
- New search...