Indirect Addressing in 16 bit PICs

[Diver300]

I have been doing some programming on a 16 bit pic, a PIC24FJ32GA002.

In many ways it is a huge improvement over all the 8 bit PICs that I have used, but it also has some flaws.

In particular, the RAM is arranged as 8 bit memory, which can be accessed 16 bits at a time, as long as the address is even.

Now when doing data tables, it is usual to calculate offsets and use indirect addressing, but if the address end up as odd, the processor resets. It can be avoided using byte addressing, (8 bit) instead word addressing but of course it takes twice as many operations to handle the data and it really makes the whole 16 bit concept a bit pointless.

Has anyone got any comments or workarounds? I will probably be putting traps for odd addressing all over my code from now on, but I wondered if there were any neat ways of aproaching it.

 

[eng1]

Now when doing data tables, it is usual to calculate offsets and use indirect addressing, but if the address end up as odd, the processor resets. It can be avoided using byte addressing, (8 bit) instead word addressing but of course it takes twice as many operations to handle the data and it really makes the whole 16 bit concept a bit pointless.

I would use table instructions (TBLRDL, TBLRDH, etc.) with auto-increment ("plus-plus").

the core recognizes that Post-Modified Register Indirect Addressing mode [Ws++] will result in a value of Ws + 1 for byte operations and Ws + 2 for word operations.

 

[Pommie]

Has anyone got any comments or workarounds? I will probably be putting traps for odd addressing all over my code from now on, but I wondered if there were any neat ways of aproaching it.

I don't know the 24 series but I would just write a function that returned any address. But, if you are writing tables, shouldn't they be in rom anyway?

Mike.

 

[Diver300]

Firstly, I do write data tables in ROM when I know what they will be at programming time.

The particular application is setting up GPRS on a mobile application, where the APN (access point name) etc is sent to the application as a text message, so the APN is stored in RAM between being read from the text message and being used.

I do use the

mov [w2++], [w3++]

but I have to calculate the start values of w2 and w3, and the program resets if either are odd. (except for byte operations)

Since starting the thread, I have found that there is an address trap flag that tells me if this has happened, but there is no way to find where the code went wrong.

Most of it will probably work itself out as all text ( in bytes ) has to be byte operations anyhow.

 

[Pommie]

Are you saying that you can write to ram as bytes but if you read it back it errors? Or are you saying that accessing words on a non even address errors? If the latter then the 8086 got there first.

Mike.

 

[donniedj]

Diver300:
I had a rough time with the same family series. Got it all straigthened out now, thanks to nearly infinite single line debugging on my behalf. Post your code and I can show where that little change needs to be. It most likely will be very small and that causes a huge frustration.

1. TBLRDL/H instruction is to read from Program memory only.
2. MOV is to read from Data memory only.
3. Store your Data memory as 16-bit words. You can concatenated 2 byte values into a word and just use the whole 16-bits to store a single byte.

How are you declaring Data memory? With .bss or .data and value1: .space 2?

 

[Diver300]

Are you saying that you can write to ram as bytes but if you read it back it errors? Or are you saying that accessing words on a non even address errors? If the latter then the 8086 got there first.

Mike.

The problem is that accessing words with an odd address causes an error, which resets the processor.

 

[Diver300]

Diver300:
I had a rough time with the same family series. Got it all straigthened out now, thanks to nearly infinite single line debugging on my behalf. Post your code and I can show where that little change needs to be. It most likely will be very small and that causes a huge frustration.

I'm sorry but I'm not going to post the code. For one thing it is going into a commercial product, and secondly there are about 5000 lines of it so I doubt that anyone would be bothered to go through it.

1. TBLRDL/H instruction is to read from Program memory only.
2. MOV is to read from Data memory only.

I have also been using Program Space Visibility to read from program memory. The data sheet says:-

The upper 32 Kbytes of the data space memory map
can optionally be mapped into program space at any
16K word boundary defined by the 8-bit Program Space
Visibility Page Address (PSVPAG) register. The program
to data space mapping feature lets any instruction
access program space as if it were data space.

Is there anything wrong with that?

3. Store your Data memory as 16-bit words. You can concatenated 2 byte values into a word and just use the whole 16-bits to store a single byte.

That is what I do most of the time, but I can't see much alternative to using 8 bit bytes for storing text strings.

The actual errors that I have found have been when I have been handling text and used mov when I should have used mov.b

How are you declaring Data memory? With .bss or .data and value1: .space 2?

I just declare the start value

APN = 0x2160
max_APN_length = 64
whatever_follows_APN = 0x21a0

There are probably lots of better ways of doing it.