Hello, I use keil compiler V7.50 with DS80C400 µC in LARGE memory model. I declare several string constants like this :
const char far image[] = "\x25\x50\x44\x46\x2D\x31\x2E\x34\xD\xA\x25[...] \x30\x34\x38\xD\xA\x25\x25\x45\x4F\x46\xD\xA";
SRC\UTILE.C(255): error C281: illegal hex constant SRC\UTILE.C(255): error C103: '<string>': unclosed string SRC\UTILE.C(256): error C141: syntax error near '42' SRC\UTILE.C(258): error C103: '<string>': unclosed string
SRC\IMAGE.C(360): error C249: '!': SEGMENT TOO LARGE
I do not know how related this is, but the Keil '51 compuker hold offsets internally in 16 bits. Thus if an offset cross a 64k boundary you are out of luck. Erik
STRING (FAR) should do the job. See: http://www.keil.com/support/man/docs/c51/c51_string.htm Reinhard
Thanks, STRING (FAR) should do the job No, It doesn't, as I said in my first message, I already use a "#pragma STRING (far)" at the beginning of the file.
The constants in a single file cannot be larger than 64KB. You need to create multiple files in such cases.
The constants in a single file cannot be larger than 64KB. You need to create multiple files in such cases Ok for this problem. But what about my first problem which is the most important one because I have no solution to it ? According to my tests, it seems the 64kB limit is applied to the string before its analysis. If so, when I declare a string like this : "\x5A", it takes 4 times the real size. Hence the 16kB limit which corresponds to 64kB / 4. If my above analysis are correct, this is a bug and I would be pleased to receive a patch or at least a workaround to declare tables up to 64kB. Thanks a lot, Xavier
"According to my tests, it seems the 64kB limit is applied to the string before its analysis. If so, when I declare a string like this: "\x5A", it takes 4 times the real size" What happens if you do
const char far image[] = {0x25,0x50,0x44,0x46,0x2D,0x31,0x2E,0x34,0xD,0xA,0x25...
const char far image[] = "\x25\x50\x44\x46\x2D\x31\x2E\x34\xD\xA\x25...
What happens if you do const char far image[] = {0x25,0x50,0x44,0x46,0x2D,0x31,0x2E,0x34,0xD,0xA,0x25... instead of const char far image[] = "\x25\x50\x44\x46\x2D\x31\x2E\x34\xD\xA\x25... It works better. I can declare array up to 32kB (tested with the same values). The same if I declare strings like this : const char far image[] = "ABCDEF..."; /* OK up to 32kB */ If I exceed 32kB, I get this error : SRC\HTML.C(226): error C249: '!': SEGMENT TOO LARGE Xavier
I guess that if you use banking the 64k reduces to segment size. Erik
So, it looks like you're trying to load a static web page into ROM - yes? Looks like it might be easier to just have a separate utility that create the HEX file directly, and merge that as a post-build operation? I wouldn't be surprised if there are ready-made utilities to do that, but it shouldn't be hard to create one with a quick bit of VB/MSVC/C++ Builder/Delphi or whatever you prefer...
I guess that if you use banking the 64k reduces to segment size. Erik I am not sure I understood the question, but I don't use banking, I use "Contiguous Mode: 16MB program" and "Code Banking" is not checked. I just tried to ckeck "code banking" but I can't really understand how it works ; it seems to perform exactly as before except that I get errors at linking stage Xavier
So, it looks like you're trying to load a static web page into ROM - yes? yes, except that web page are not really static, I use sprintf functions to get them alive Looks like it might be easier to just have a separate utility that create the HEX file directly, and merge that as a post-build operation? Thanks for your suggestion, however I don't think this is the right solution. I use a lots of html files and I have a tool which creates one C file containing all the corresponding vars ; then keil compiler manage to get them at the right memory location automatically. Creating an hex file would mean to handle all the memory organization by hand ... Moreover, I am just doing a product upgrade, the actual product is up and running. the size of my files has slightly increased that's why I discovered this 16kB limit. I can't change everything just because keil doesn't support what it advertises ! Sorry to be a bit crude but as it seems to be the compiler fault it should be solved at compiler level. Regards, Xavier
Are you using an outdated C51 version ? Tried it with C51 V8.01c, here is the result:
#pragma OMF2 STRING (far) const char far cTab[] = { "0123456789ABCDEF 0123456789ABCDEF 0123456789ABCDEF 0123456789ABCDEF" // line repeated 978 times ... };
MODULE INFORMATION: STATIC OVERLAYABLE CODE SIZE = ---- ---- CONSTANT SIZE = ---- ---- XDATA SIZE = ---- ---- PDATA SIZE = ---- ---- DATA SIZE = ---- ---- IDATA SIZE = ---- ---- BIT SIZE = ---- ---- EDATA SIZE = ---- ---- HDATA SIZE = ---- ---- XDATA CONST SIZE = ---- ---- FAR CONST SIZE = 65393 ---- END OF MODULE INFORMATION.