CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

rom #org & multiple compilation unit woes

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kda406



Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA

View user's profile Send private message

rom #org & multiple compilation unit woes
PostPosted: Wed Sep 01, 2021 12:48 pm     Reply with quote

I am looking for advice or a trick to help #org work better with rom stored data when multiple compilation units are in play. Without assistance, CCS overlaps the ROM tables.

Today I'm working with a PIC18F67K40 and 5.104, but I have struggled with this problem with the CCS compilers for decades. My work-arounds so far have been time consuming and problematic.

The current project is only medium complexity with 40 .c files and about 55 .h files.

Tables for conversion data and strings are stored in program memory using the CCS "rom" type qualifier.

Without #org statements, the CCS compiler puts the rom data all on top of each other. It is a REAL PROBLEM! A peek at an example symbol file reveals:
Code:
User Memory space: rom
 01FCE0-01FFFF  c_cMenuMain
 01EC74-01FFFF  gczmR410ATempFromPress
 01FFB0-01FFFF  c_cSettingCategories

WHOOPS! All the data tables are in the same place!

All these data are stored in libraries and are included in different projects in different combinations. I cannot just put a #org 0xXXXXX into the library as it will be the wrong place on the next project. So I use preprocessor naming for each project to name the segments. In the ProjectConfig.h:
Code:
/*
 ___  ___  __  __     _      _    _
| _ \/ _ \|  \/  |   /_\  __| |__| |_ _ ___ ______ ___ ___
|   / (_) | |\/| |  / _ \/ _` / _` | '_/ -_|_-<_-</ -_|_-<
|_|_\\___/|_|  |_| /_/ \_\__,_\__,_|_| \___/__/__/\___/__/
*/
///// Locations where we store data tables in program memory /////
#define ROM_THERMISTOR2880      0x1E62E                           // 1604 (0x644) byte 2880 table, 0x1E62E - 0x1EC73
#define ROM_R410APT            0x1EC74                           // 5002 (0x138A) byte P-T table, 0x1EC74 - 0x1FFFF
In a typical library that uses this:
Code:
#ORG ROM_R410APT
rom INT16 gczmR410ATempFromPress[] = {...


As the projects grow the complexity increases. One issue is that you cannot create the #org statements until you know the sizes of each of the tables. You must compile to find the sizes and overlaps. Iteratively, I find the sizes of each rom section for each system, slowly untangling the overlapping rom data.

Then, the customer asks me to make one minor change to one user menu and WHOOPS, the entire table set are overlapped and messed up with no warning from the complier or linker!

I wish I had a computer to figure this out for me, but instead, I have to think for the computer. Laughing

So I've tried to simplify an example of a nightmare I face with every project. What do you do to manage your program memory stored data with CCS and MCUs, and how might I manage mine better?

Thanks,
Kyle
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Sep 01, 2021 12:58 pm     Reply with quote

My solution (Ok, I'm a dinosaur..started with PCM 2.435 +-) is to never,ever use MCU (Multiple Compilation Units).
I've never had 40 + '#include xxx.c' files for one project(15-20 max) though I suspect the compiler would be happy to figure it all out....
Historically CCS didn't do MCU well, maybe the newer compiler will ? Others far younger than me, can answer that.....
dyeatman



Joined: 06 Sep 2003
Posts: 1910
Location: Norman, OK

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 9:12 am     Reply with quote

Can we assume you have reported this to CCS?
_________________
Google and Forum Search are some of your best tools!!!!
kda406



Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 9:28 am     Reply with quote

dyeatman wrote:
Can we assume you have reported this to CCS?
I have not. This has been a problem for decades; surely CCS knows about it. I am seeking suggestions of how other users work around this problem.

Thanks,
Kyle
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 11:46 am     Reply with quote

Why do you use rom?. Consts are c6rrectly handled across MCU's and
given that for strings you can use the PASS_STRINGS option to allow
pointers, it might be much easier to not use the rom declaration.
However, CCS is very clear that if you use the rom format, and MCU's
then you have to ensure these do not overlap. What about generating a
macro to handle generating the addresses. Use a couple of values for start
and size, and have it automatically increment the start by the size each time
it is called.
I have to agree with the comments about not using MCU's. Generally things
work much better without them, and the compilation speed is usually fast
enough that there is no real advantage to using them.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 1:09 pm     Reply with quote

re: the compilation speed is usually fast
enough that there is no real advantage to using them.

it's lightning fast compared to how we erased PICs, back in the good old days.... 15 minutes under the UV bulb.....ah, coffee break times !!!
Jay
kda406



Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 1:16 pm     Reply with quote

Quote:
Why do you use rom?


I use const for some things, but it is buggy on large programs. Once the compiled program exceeds 20~30KB the const arrays start having problems.

I just grabbed a small test menu as an example.
Code:
#ORG 0x1D000
rom char c_cSettingCategories[4][20] = {
"Frequency [Hz]",
"Compressor [T]",
"Blower/Fan [CFM]",
"TXV [Steps]"
};
This prints correctly when used with a printing routine that expects a rom char * argument.

Now I change it to a const:
Code:
const char c_cSettingCategories[4][20] = {
"Frequency [Hz]",
"Compressor [T]",
"Blower/Fan [CFM]",
"TXV [Steps]"
};
And change the print routine to expect a char * argument, along with the "#device PASS_STRINGS=IN_RAM" directive.
Code:
Frequency [Hz]
Compressor [T]
Blower/Fan [CFM(
TXV [Steps]
Notice the incorrect character. I have put it into a loop for printing and every time it comes out with the exact same problem I show in this example. I can print it 10X and it still has a ( instead of a ] every time. Print problems is one thing, but we cannot tolerate mistakes like this in the data tables that control motors and valves(!).

I have seen this across various PIC18F families (87Kxx, 67Kxx, 46Kxx). This problem only manifests after the program gets large in size. It seems to get worse as the program gets larger.

I have never had the data get corrupted like this when I use rom instead of const. So I use rom. But that brings up the woes from the original post.

It seems there is no simple solution to the #org problem, but I appreciate everyone's input.

Thanks,
Kyle
kda406



Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 1:21 pm     Reply with quote

temtronic wrote:
it's lightning fast compared to how we erased PICs, back in the good old days.... 15 minutes under the UV bulb.....ah, coffee break times !!!
Jay

"Back in the day," I had two PIC16C54s and I was always erasing one while programming/testing with the other.
Code:
     ; I wrote everything in assembly back then.

Very Happy
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 6:00 pm     Reply with quote

Have you tried declaring all of your rom variables together in a single file and using "extern" versions in your libraries? If that works it would ensure they don't overlap while allowing your library to work as long as you link in the file with the defined variables:


library.h
- Has typedef for your data structure
- has public interface to your library

library.c
- externs a known variable by name that has the type defined in library.h. I don't know if you can extern a rom variable or not or if you still need to have "rom" in the type definition or not, but something to play with

rom_defs.c
- #includes the library.h file for the typedef
- allocates a variable of that type with the same name as the extern'ed variable in library.c.
- has other rom variables declared here too, #includes appropriate .h files for them

Again, I haven't tried any of this. I avoid MCU's altogether cause the compiler doesn't have an actual linker, just a emulated linker stage and it has always caused me trouble. An actual linker would allow you to specify the memory map of your program separate from the code (which is what the rom_defs.c file is trying to emulate in my thought process).

Alternatively, if that doesn't work you could try adding a library init function that takes a "rom pointer" to your rom type for the library and assigns it to in internal global pointer and use that in your library instead of the rom variable directly. Then you again would define all of your rom variables in a single file and just call the various library init functions at the start of your program to assign them to the library
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Sep 02, 2021 10:13 pm     Reply with quote

Agree totally with Jeremiah.
Having multiple separate declarations, is asking for trouble, Single set
of declarations that all the modules then access, would seem by far
the easiest, and most likely to work.
kda406



Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA

View user's profile Send private message

PostPosted: Fri Sep 03, 2021 7:53 am     Reply with quote

That's a great concept, Jeremiah. I'm going to give this a try. This is exactly the kind of suggestion I was hoping to get from this great forum.

Many thanks,
Kyle
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group