hi Philipp, hello Rolf,
actually I have an STM8 application where I need access to >64kB address range.
Specifically I want to program a 128kB device as a datalogger. The SW already
works under Cosmic (using @far identifier), but I understand that sdcc doesn’t
(yet?) support far address pointers. I tried to work around this using inline
assembler, see the below code. Specifically sdcc aborts with the below error
code in the line containing the LDF instruction. Does this mean that even the
assembler doesn’t support far pointers? Or am I just using the wrong (i.e.
Cosmic) syntax? For your support thanks a lot in advance!
Georg
Error messages:
Error: <a> machine specific addressing or addressing mode error
Error: <q> missing or improper operators, terminators, or delimiters
———————
Source Code:
void flash_write_byte(uint32_t addr, uint8_t ch) {
// disable interrupts
DISABLE_INTERRUPTS;
// unlock w/e access to P-flash
FLASH_PUKR.byte = 0x56;
FLASH_PUKR.byte = 0xAE;
// unlock w/e access to EEPROM
FLASH_DUKR.byte = 0xAE;
FLASH_DUKR.byte = 0x56;
// wait until access granted
while(!FLASH_IAPSR.reg.PUL);
while(!FLASH_IAPSR.reg.DUL);
// Cosmic compiler (supports far pointer)
#if defined(__CSMC__)
// write byte to p-flash (use 3b address for near&far range)
*((@far uint8_t*) addr) = ch;
// SDCC compiler (doesn't support far pointer --> use inline assembler)
#elif defined(__SDCC)
// store address & data globally for assember
g_addr = addr;
g_val = ch;
// use inline assembler
ASM_START
ld a,_g_val
ldf [_g_addr+1.e],a
ASM_END
#endif // SDCC
// wait until done
while (!FLASH_IAPSR.reg.EOP);
// lock P-flash again against accidental erase/write
FLASH_IAPSR.reg.PUL = 0;
// lock EEPROM again against accidental erase/write
FLASH_IAPSR.reg.DUL = 0;
// enable interrupts
ENABLE_INTERRUPTS;
} // flash_write_byte
———————
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Dec 2014 17:42:38 +0100
> From: Philipp Klaus Krause <p...@spth.de>
> Subject: Re: [Sdcc-user] Migrating from Cosmic to SDCC;
> ASlink-Warning-Undefined Global
> To: sdcc-user@lists.sourceforge.net
> Message-ID: <5489c97e.80...@spth.de>
> Content-Type: text/plain; charset="windows-1252"
>
> On 18.11.2014 15:14, Rolf Schroder wrote:
>
>> FYI: I could not find any information about Storage Class Language
>> Extensions for the STM8 in the doc so I removed the "@near" / "@far"
>> extensions used by the COSMIC compiler (instead of replacing them with
>> SDCC's version). I am not sure whether the code will still work.
>
> sdcc does not yet support storage class extensions for the stm8. The two
> that would make sense are __near and __far (I don't know about Cosmic,
> but would suppose that they correspond to their @near and @far). I do
> not consider implementing them a priority currently:
>
> - They are only relevant for global variables.
>
> - Implementing them would require some effort in various places (code
> generation, peephole optimization, linker, assembler).
>
> - __near corresponds to what is called short addressing mode in the STM8
> manuals. It would allow the programmer to specify up to 256 bytes of
> global variables to be in the lower 256 B of memory. Accesses to these
> global variables would result in more compact code than other global
> variables. Most instructions support short addressing mode, so most
> accesses to these variables would result in slightly shorter code than
> normal global variables. The programmer would have to make sure that he
> uses __near for at most 256B (maybe the linker could give an error
> message otherwise). Summary: __near provides a limited code size benefit
> at the cost of some extra burden on the programmer.
>
> - What sdcc currently uses for all global variables is called long
> addressing mode in the STM8 manual. It allows access to 64 KB of memory.
> Enough to access all memory on nearly all STM8 microcontrollers. Most
> instructions support long addressing mode. Summary: This is the perfect
> default for global variables.
>
> - __far corresponds to what is called extended addressing mode in the
> STM8 manual. It allows access to up to 16MB of memory. Only very few
> instructions support extended addressing mode (ldf, callf, jpf, retf).
> So any access to a __far variable would have to go through ldf
> instructions for every byte copying the variable elsewhere first. This
> makes access to __far variables very inefficient. Currently no STM8
> microcontroller that has more than 6 KB of RAM exists. Very few STM8
> microcontrollers have flash memory outside the lower 64 KB. And only if
> you want to use that flash for constant global variables (instead of for
> code) is this addressing mode useful: Summary: __far is something only
> useful in rather exotic use-cases.
>
> - Note that sdcc currently also does not support __banked calls. This
> means that code is currently also limited to the lower 64KB of memory.
> Lifting this restriction would however be far easier than implementing
> __far (we would use callf, jpf, retf), as long as no functions pointers
> to functions outside the lower 64KB are used (for function pointers
> pointing to code outside the lower 64KB we would need __far).
>
> Philipp
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
