Forum : ST7/STM8
Post Information | Post |
---|---|
October 19, 2012 - 3:48am
|
You might remember a little while ago you (Raisonance) were kind enough to create a work around for us for the linker for relocating memory segments into a higher program memory space (i.e. higher than 16bit address) that would normally be forced into a low program memory space. That worked out well for us mostly. One major extra workaround we've had to deal with is string manipulations. The linker would usually force strings into the low program space so the rest of how Raisonance deal with strings in this environment assumes that the string will exist in a 16 bit address space. However, using the special linker with the lxf file workaround, we force these strings into a program memory space beyond a 0xFFFF. As a recap, none of our application code exists below an address of 0xFFFF. There is a bootloader/manager that resides in low program memory(<0xFFFF). fnStringManipulator("This is a string that always gets passed as a 16 bit address in the X register"); The strings address is unable to be recast, it's address always gets loaded in to the X register as a 16 bit address even if its been shifted to a high program memory space by the linker workaround which would need a 24 bit address. I wonder, as a feature request or workaround, is there an switch option that could be added to the compiler to treat all non variable strings passed in a function in double quotes as a 24 bit address? maybe to help with compatibility with string.h, the lower 16 bits could go in the X register and then the most significant 8 bits of the 24 bit address could go in the Y register? The unattractive workaround that we have been using is to declare an fcode string at the start of a module (c file). Then, in the function we would copy it using 24 bit addressing into either a static RAM variable or local stack variable and then pass that into our own string manipulation functions. It works that way but its ugly. Thanks in advance, |
Hello John,
The Raisonance STM8 compiler supports "far" data, but it's (currently) hidden.
Specify DGC(fdata) in the compiler additional options to force all global data to be acceded as far.
Warning, pointers may be located far but still access near data. For a far access, you have to specify it:
char far* ptr;
For your function prototype, it will look like:
fnStringManipulator( char far* msg);
Just one thing, code generated for far data is very fat.
Regards,
Stéphane