Replacement methods of pointer assignment

[ye]

HI all,

Since CCS doesn't support pointer assignment, are there any good ways to do that? I am using PIC18F8722 and I want to copy one array to another.

Certainly FOR loops will not be optimistic. I used to use 'memcpy' to copy the memory content of one array to another which was quick but it took too much space in memory.

Are there any efficient and 'light' ways?

cheers

[Ttelmah]

You can just point a pointer at the same target. CCS allows this fine (pointer assignment), _but_ there is the major caveat, that the target must exist in both locations where it is used. You have to remember that normal variables inside a function, do not remain allocated when the function exits, so the object pointed to by the second pointer, must be declared as static, or have it's scope launched in a function outside the location where it is used.
So CCS, _does_ allow 'pointer assignment', but _you_ have to ensure the target will exist.

Best Wishes

[ye]

Thankyou, Ttelmah.

Sorry, I think I need to make myself more clearly undertood. When I was saying CCS doesn't support pointer assignment, I was actually saying the statements like below do not work:

[Ttelmah]

The second declaration, declares the complete array. You are not trying to perform 'pointer assignment', but array copying. Pointer assignment, would be:

[ye]

Ttelmah, thanks.

But I think I have stressed that I was using memcpy but realised this command sacrifice too much rom.

[Ttelmah]

Memcpy, doesn't use much ROM. Seriously, this is about as closely coded as the chip can manage. How large it is, depends on the chip you are using. On (for instance), an 18F chip, which supports table reads/writes, the entire operation to move a 128byte array, only occupies 11 instructions. I assume you are on a smaller chip like the 16F, in which case the problem is that there is only one indirect addressing register to talk to the RAM, so the code has to calculate the source address, place this in the INDF registers, fetch the addressed byte, save this, calculate the destination address, place this in the INDF registers, write the saved byte, then increment the counter, and start again. The size will be almost exactly the same, even if you coded it in assembler...
At the end of the day, the compiler is stuck with the limitations of the chip.

Best Wishes

[Guest]

Thanks, Ttelmah.

If you are right, I think there is no other better way to do array coping than memcpy. Yes, I am using 18f. The reason I desperately want to reduce the number of assembly instructions contributed by memcpy is I have so many memcpy in my code! The characteristic of my code defines that I need to copy arrays a lot and the accumulated impact on rom space given by memcpy is big at the end of the day. I would think if I could somehow reduce the number of assembly instructions by 2 or 3, significant amount of rom space will be saved.

Cheers

[Ttelmah]

You don't need to have seperate versions.
If you code the standard 'memcpy' command, it is produced 'inline'. If instead, you 'encapsulate' the command, as:

[ye]

Yes, I have been paying attention to reusability and defining all variables requiring multiple uses as static, global or even dump them into rom by defining them as constant.

The problem with my code is, since I am designing a system GUI on an LCD, I need a lot of things like menus, text backgrounds, etc and on these various screens there are different texts, which means I have a vast number of different text templates defined as constant and stored in rom. Initially I stored the templates in ram but realised the ram couldn't accommordate so many!

Since I couldn't directly access these constants, I have to copy them into a general array to use them and this is why I am using so many memcpys!

If I could find a better way to store the massive amount of templates in which case I wouldn't have to use any array copying (I actually raise this question in another post), or if I could find a better way of array copying to reduce the memory usage contributed by the massive amount of memcpy uses, I will be on the moon!!

My ultimate goal is to save ROM!

Cheers

[Ttelmah]

I do a similar array system on a LCD, and have the messages stored as a single large 'block' in ROM, not as constants. They are seperated by marker characters,and during boot, the system scans the block, and stores just the location of each message in RAM. I have three different blocks, containing messages for different languages, and according to a EEPROM value, the decision is made as to which block to scan. The output is then done, for a given message 'number', by reading it's address from the RAM array, and then starting at this address, outputting the characters in turn, till the next 'marker'. I have a total of about 600 messages (200 each from three different languages), and only use 400 bytes of RAM for the address table. On another system the massages are stored in a similar way in an external FRAM.
You can directly access data in the program ROM (you must be doing this to copy the data into the RAM). Reads fom program memory are fast (it is only writes that are slow), so using some similar index system, may be an answer for you.
It is worth remembering that if you store data as a 'constant' (using const), the access code is added to the dront of each declaration, wasting a lot of space. Storing such data using a #ROM declaration, avoids this, and you can use a single copy of 'read_program_memory', to access such data.

Best Wishes

[Guest]

Your idea souds to work!

I will be very happy if I could apply this to my code to save space and at the mean time keep the speed but before that I would like to get more details from you about practical implementation.

[Ttelmah]

I actually use the '~' character. This was 'ancestral', since I originally used the same approach for a large array held on another C system, and did not want to use the null character. I also use the null inside the input routine, so want to avoid this.
I have the message numbers declared as #defines. So (for example):

[ye]

Ttelmah, the code is great !


I can see how you think here with the code: store the messages in one single block using #ROM and call them back using 'read_program_memory' according to the message address table stored in ram, right?

However,

[Guest]

1. another question is, how to use #rom to store multiple messages into the rom?

for simple integers you can do it like:

#rom 0x300 = {1,2,3}

but for arrays,how?

2. also, when you did it, did you define the block start address as the first rom address? would the content of this block be overlapped with the actual code

3. I browsed some posts in the forum and found people saying using #rom would store stuff into internal eeprom rather the actual ROM?


Cheers

[Ttelmah]

There is no code in a ROM declaration (this is how it differs from the 'const' declaration). I mentioned in one of the earlier posts, that I scan the area concerned during boot, to find the start of message characters. So the simple 'initialisation', involves setting msg[0] = 0, then scanning till I find the '~', and setting msg[1] to the next character. I repeat this to 'MAXMSGNO'. In fact I have the three language blocks one after the other, and for the second language, I start again, so that msg[0], now has the address of the first word in the next language. Obviously since I use an INT16, for the addresses, I can potentially have a maximum of 64KB, for the total of all the messages.
You can just directly declare strings into the ROM, with:
#ROM 0xnnnn = {
"Message one~Message two~Message three~",
"Message four~Message five~Message six"
}

#ROM, can store data _anywhere_. If the address '0xnnnn', is the address of the start of the internal EEPROM, then it's data is put here. If instead you point it to an address in the main memory, it's data goes here instead. If you are on a chip like the 18F252, which has memory, that reaches 0x7FFF, then if you declare:
#ORG 0x7c00,0x7FFF {}

#ROM 0x7C00 = {
"Required strings here"
}

Then the ROM block is placed at 0x7C00, and the area is reserved by the 'ORG', so that code cannot be placed here.

Best Wishes