Jump to content

Rom Data Type Limitations

Recommended Posts



BUG DESCRIPTION: There is either a problem with the rom data type or in my understanding of its limitations.


I have a program with 4 arrays: 20 bytes, 162 bytes, 162 bytes & 142 bytes. I have been using #pragma DATA TABLE_START, 0x0782, followed by the number of required bytes in a header file to place the data in fixed locations at the top of memory (the longer ones were started at 256 byte boundaries). The data is accessed using short asm code. This works without any problems except there are obvious unused gaps in memory between the data and I am not sure if the compiler can work around the data and utilise these gaps when and if the program size ever reaches that point.


I thought I would try using the rom data type instead to see what difference there was in code size, speed etc. I simply removed the #pragma DATA HT_TABLE_START, 0x0782, etc and wrapped the required comma delimited data with:


rom char *table_1 = {----REQUIRED DATA BYTES----- }

rom char *table_2 = {----REQUIRED DATA BYTES----- } etc


The data was accessed using the form: char data = table_1[offset];


Checking the first few elements returned seemed to work fine for tables 1, 2 & 3 but when accessing table 4 the returned data was actually that from table 1. This seems to be a classic address wrap around situation. Looking at the amount of code generated to access the data I naturally assumed that the compiler would take care of 256 byte boundaries and paging issues. It certainly doesn't force the data to start at a 256 byte boundary.


The manual states that a rom pointer is limited to 8 bits or 256 elements, which is fair enough. I understood this to mean that I could have a number of rom arrays each of which could be up to 256 elements.


I haven't had time to fully analyse the problem or provide cut down code as an example but from what I have seen I would guess that the limit may be 256 elements in total no matter how many arrays are defined. This may be a bit simplistic and may vary depending on where the code is placed by the compiler.



Can anyone confirm if there is an overall limit on the number of rom array elements?



REPRODUCIBLE: Yes but haven't had time to fully investigate

IDE: V6.84

COMPILER: BoostC (Using aggressive optimisation)

TARGET: 16F887

OS: XP Pro SP2





Link to post
Share on other sites



Ignore my previous ramblings, I have found the problem!


During initialisation I was calling a function to block clear the ram. I have always used this when writing in assembler since I found it made debugging easier. With SourceBoost C it has had the opposite effect.


When the rom data type is used, SourceBoost C appears to create rom table numbers in ram which my routine then carefully cleared. This may also explain other problems as well.


Removing the function cured the problem. What fooled me was that three out of the four tables appeared to work correctly.


Not a bug in the rom data type as such, but remember not to clear the ram as a block and initialise any variables as and when required.


Still learning.



Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...