Rolf Schröder | 16 Dec 14:56 2014
Picon

Re: Sdcc-user Digest, Vol 102, Issue 2

Dear Philipp,

Thank you for the detailed explanations about short/long adressing.
Indeed, Cosmic's  <at> near/ <at> far corresponds to the usual __near/_far. I
just wanted to leave this information for reference and did not intend
to ask for any future work from the sdcc devs.

Best,
Rolf

------------------------------------------------------------------------------
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
Georg Icking-Konert | 17 Dec 16:30 2014
Picon

Re: Migrating from Cosmic to SDCC; ASlink-Warning-Undefined Global (Philipp Klaus Krause)

hello Philipp,

you’re right, with '.e‘ outside the brackets it worked right away! Now I am able to write to and read from the full 128kB STM8 flash :-)   Attached please find the respective routines for SDCC and Cosmic. Passing arguments between C and assembler is done via global variables g_addr and g_val.

Thanks a lot for your support and have a nice Christmas!
Georg

PS: is there a way to attach .zip files to the mailing list to avoid epic listings inside the mails?

——————

/**
  \fn void flash_write_option_byte(uint16_t addr, uint8_t byte)
  
  \brief write option byte to flash
  
  \param[in] addr   address to write to
  \param[in] byte   byte to program

  write single option byte to given address
*/
void flash_write_option_byte(uint16_t addr, uint8_t byte) {

  uint8_t        *addr_near;    // option bytes are in 2B range

  // check address
  if ((addr < 0x4800) || (addr > 0x48FF))
    return;
  
  // disable interrupts
  DISABLE_INTERRUPTS;

  // unlock w/e access to EEPROM & option bytes
  FLASH_DUKR.byte = 0xAE;
  FLASH_DUKR.byte = 0x56;
  
  // additionally required
  FLASH_CR2.byte  |= 0x80;
  FLASH_NCR2.byte &= 0x7F;
  
  // wait until access granted
  while(!FLASH_IAPSR.reg.DUL);

  // set address
  addr_near = (uint8_t*) addr;
  
  // write option byte to p-flash
  *(addr_near++) = byte;
  
  // wait until done
  while (!FLASH_IAPSR.reg.EOP);
  
  // lock EEPROM again against accidental erase/write
  FLASH_IAPSR.reg.DUL = 0;
  
  // additional lock
  FLASH_CR2.byte  &= 0x7F;
  FLASH_NCR2.byte |= 0x80;
  
  
  // enable interrupts
  ENABLE_INTERRUPTS;

} // flash_write_option_byte



/**
  \fn void flash_write_byte(uint32_t addr, uint8_t ch)
  
  \brief write single byte to flash
  
  \param[in] addr   address to write to
  \param[in] ch     byte to program

  write single byte to address in P-flash or EEPROM
*/
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)
  *(( <at> 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



/**
  \fn uint8_t read_byte(uint32_t addr)
  
  \brief read single byte from memory
  
  \param[in] addr  memory address to read from

  \return byte read from memory

  read single byte from address in memory
*/
uint8_t read_byte(uint32_t addr) {
    
// Cosmic compiler (supports far pointer)
#if defined(__CSMC__)

  // return read byte from memory (use 3b address for near&far range)
  return(*(( <at> far uint8_t*) addr));

// SDCC compiler (doesn't support far pointer --> use inline assembler)
#elif defined(__SDCC)
  
  // store address & data globally for assember 
  g_addr = addr;

  // use inline assembler
ASM_START
  ldf a,[_g_addr+1].e
  ld _g_val,a
ASM_END

  // return read byte from memory
  return(g_val);

#endif // SDCC

} // read_byte




Message: 2
Date: Tue, 16 Dec 2014 17:16:26 +0100
From: Philipp Klaus Krause <pkk-dH2bkuHepfc@public.gmane.org>
Subject: Re: [Sdcc-user] Migrating from Cosmic to SDCC;
ASlink-Warning-Undefined Global (Philipp Klaus Krause)
To: sdcc-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Message-ID: <54905ADA.9030001-dH2bkuHepfc@public.gmane.org>
Content-Type: text/plain; charset="windows-1252"

On 16.12.2014 16:35, Georg Icking-Konert wrote:
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 <at> 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!

I'm not the one who wrote the assembler, but looking at the source it
seems the .e needs to be outside the brackets.

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@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Georg Icking-Konert | 16 Dec 16:35 2014
Picon

Re: Migrating from Cosmic to SDCC; ASlink-Warning-Undefined Global (Philipp Klaus Krause)

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 <at> 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)
  *(( <at> 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 <pkk-dH2bkuHepfc@public.gmane.org>
Subject: Re: [Sdcc-user] Migrating from Cosmic to SDCC;
ASlink-Warning-Undefined Global
To: sdcc-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Message-ID: <5489C97E.80307-dH2bkuHepfc@public.gmane.org>
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 " <at> near" / " <at> 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 <at> near and <at> 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@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
陳韋任 (Wei-Ren Chen | 4 Dec 10:57 2014
Picon

Question about binary constant casting

Hi All,

  I have the following code below, with "default" signed char type.

-----------
#define BIT4             0b00010000
#define P_IO_Ctrl_Base   0x2080

#define P_IO_PortC_Data  *(volatile unsigned char *) (P_IO_Ctrl_Base+0x1A)

#define DrvGPIO_SetBit(GPIO,BITIO)    GPIO |= BITIO; 
#define DrvGPIO_ClrBit(GPIO,BITIO)    GPIO &= ~BITIO;

void main()
{
  DrvGPIO_ClrBit(P_IO_PortC_Data,BIT4);
}
----------

  I add `--fverbose-asm` option to see more details on the codegen. What
I'm curious about is the code snipt below:

----------
        ld      a,(#0x209A)
; peephole 17 loaded a from (#0x209A) directly instead of using hl.
;       genCast
;       genAnd
        and     a, #0xEF
---------

Although the genCast doesn't emit code, I am wondering why we need a
casting here. So I study C integer conversion rules [1] a little bit,
and here is my reasoning.

  1. BIT4  => signed char

  2. ~BIT4 => int

  3. and we now have the following situation,

     P_IO_PortC_Data &= ~BIT4
     ^^^^^^^^^^^^^^^    ^^^^^

      unsigned char      int

            | *
            v

           int

    the reason we have genCast is because we have unsigned char to int
promotion. 

Am I right or wrong about the C integer conversion rules? :-)

Thanks in advance.

[1]
https://www.securecoding.cert.org/confluence/display/seccode/INT02-C.+Understand+integer+conversion+rules

Regards,
chenwj

--

-- 
Wei-Ren Chen (陳韋任)
Homepage: http://people.cs.nctu.edu.tw/~chenwj

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Alan Cox | 30 Nov 01:05 2014
Face
Picon

SDCC and 8080/8085

Has anyone done any work on this before I start randomly fiddling ?

Looking at the SDCC tree the gbz80 port actually appears to be pretty
close to what is needed for 8080 (asm mnemonics conventionally used are
different but the actual instruction set is) and also to generate
remarkably good code for such a limited CPU.

>From some initial scoping it seems that for Sdcc output the differences
that matter are

- no LD x , (HL+) or (HL-)

which is fine because they are semantically identical to the two
instruction sequence with the following INC (as INC 16bit doesn't touch
flags)

- 8080 has in/out

- no shortforum loads to 0xFFxx

not a big deal, as we don't have I/O in this way and Sdcc doesn't seem to
use them

- no LDHL SP, #n

becomes ld hl, #n
	add hl, sp

I think

- no bit instructions and arbitrary register shifts (basically no CBxx)

Looks harder to deal with, particularly the top bit testing stuff. Any
shifts have to go through A, so the usually generated stuff for

	rla (hl)
	inc hl
	rla (hl)

doesn't work but needs to be

	ld a, (hl)
	rla
	ld (hl), a
	inc hl

etc

ditto for bit operations, you end up with

	ld a, (hl)   ; or ld a, b
	and 0x80

stuff so need a clear a lot more than a gbz80 or real Z80

- no swap r, (hl)

but fortunately I've not found that in any sdcc output 8)

- interrupt stuff is different

ret not iret, no way to stack the existing interrupt state from the
hardware (much like an NMOS Z80 in fact where ld a,i push af doesn't work
reliably).

And since its a strict subset of Z80, the Z80 assembler will do fine

Alan

------------------------------------------------------------------------------
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=157005751&iu=/4140/ostg.clktrk
Rolf Schroder | 20 Nov 16:28 2014

Migrating from Cosmic to SDCC; ASlink-Warning-Undefined Global

Dear All,

<at> Maarten, Philip, Raphael:
thank you for your comments. You were all right: I did not pass the STM8 lib as an argument and it wasn't in the current folder. I tried to link against the lib which came with the SDCC 3.4.0 (win32) install but it did not work (same errors). I managed to compile the two STM8 libraries (discovery + periph-driver; again slightly adapting the src), put them into one binary and were able to compile my main.c without warnings. I think this did the trick. I did not have the time to test this out but I hope I will in the future. Thank you again for answering.

FYI: I could not find any information about Storage Class Language Extensions for the STM8 in the doc so I removed the " <at> near" / " <at> 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.

<at> Maarten: I am not sure where the STM8 discovery + periph-driver src comes from. I did not create the project initially.

<at> Philip: Thank you for clarifying about ihx format + MCU damaging.

Best,
Rolf



------------------------------------------------------------------------------
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=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
curliph | 20 Nov 12:41 2014
Picon

Help for building sdcc with msvc2010!

Hi Guys,
 
   I try to build the latest sdcc using msvc2010 following the sdcc compiler user guide,
but failed, here is the output from msvc2010:
3>Build started 2014-11-20 13:27:14.
1>CustomBuild:
1>  Generating: asxxxx_config.h
3>InitializeBuildStatus:
3>  Creating "Debug\sdcpp.unsuccessfulbuild" because "AlwaysCreate" was specified.
2>CustomBuild:
2>  Generating Parser: SDCCy.c
4>Build started 2014-11-20 13:27:15.
1>  Generating: version.h
4>InitializeBuildStatus:
4>  Creating "Debug\packihx.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>  Generating: sdcc_vc.h
2>  sdcc.y:182: type clash (`' `sym') on default action
3>CustomBuild:
3>  Generating: auto-host.h
2>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
2>
1>FinalizeBuildStatus:
3>  Generating: options.c and options.h
1>  Deleting file "Debug\config.unsuccessfulbuild".
1>  Touching "Debug\config.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.83
2>Build FAILED.
2>
2>Time Elapsed 00:00:00.50
5>------ Build started: Project: stm8, Configuration: Debug Win32 ------
6>------ Build started: Project: ds390, Configuration: Debug Win32 ------
5>Build started 2014-11-20 13:27:15.
5>InitializeBuildStatus:
5>  Touching "Debug\stm8.unsuccessfulbuild".
6>Build started 2014-11-20 13:27:15.
6>InitializeBuildStatus:
6>  Touching "Debug\ds390.unsuccessfulbuild".
6>CustomBuild:
6>  Generating Peephole Rule: peeph.rul
5>CustomBuild:
5>  Generating Peephole Rule: peeph.rul
4>ClCompile:
4>  packihx.c
6>ClCompile:
6>  ralloc.c
3>ClCompile:
3>  dirent.c
6>e:\projects\sdcc\sdcc\src\common.h(44): fatal error C1083: Cannot open include file: 'SDCCy.h': No such file or directory
6>  main.c
6>e:\projects\sdcc\sdcc\src\common.h(44): fatal error C1083: Cannot open include file: 'SDCCy.h': No such file or directory
6>  gen.c
5>ClCompile:
5>  ralloc.c
5>e:\projects\sdcc\sdcc\src\common.h(44): fatal error C1083: Cannot open include file: 'SDCCy.h': No such file or directory
5>  peep.c
5>e:\projects\sdcc\sdcc\src\common.h(44): fatal error C1083: Cannot open include file: 'SDCCy.h': No such file or directory
5>  main.c
6>e:\projects\sdcc\sdcc\src\common.h(44): fatal error C1083: Cannot open include file: 'SDCCy.h': No such file or directory
6>  Generating Code...
6>
6>Build FAILED.
 
I follow the guide strictly and carefully, but always fail...
What's wrong with me?
 
Thanks,
Best regards
 
curliph
------------------------------------------------------------------------------
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=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Kio | 18 Nov 16:00 2014
Picon

Re: support for zasm z80 assembler

Hi,

this is the dead for any port to another assembler. :-/
then i'll stick to the non-standard sdas syntax. Eliminating '#' is a job of one line, but parsing the n(IX) syntax requires additional code at multiple positions.

Anyhow a compilation of all emitted z80 opcodes, sdas pseudo opcodes and what each .area is for would be nice.

... Kio !

p.s.: this reply is rather late due to a mailing list hickup just for me…

Am 18.11.2014 um 00:27 schrieb sdcc-user-request <at> lists.sourceforge.net:

From: Philipp Klaus Krause <pkk-dH2bkuHepfc@public.gmane.org>
Subject: Re: [Sdcc-user] support for zasm z80 assembler

On 14.11.2014 19:14, Kio wrote:

i currently implement sdcc support in my z80 assembler zasm
(http://k1.spdns.de/Git/zasm-4.0.git/). My first try was to implement
the sdasz80 syntax until i discovered that sdcc already supports more
than one z80 assemblers.

However the support for others is not working fully: Sometimes asxxx
code will still be emitted, and the peephole rules only work for asxxxx,
too.


------------------------------------------------------------------------------
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=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Rolf Schroder | 17 Nov 13:05 2014

Migrating from Cosmic to SDCC; ASlink-Warning-Undefined Global

Dear All,

I am trying to compile a firmware for the STM8L. I used STVD & Cosmic (compiler) but want to switch to sdcc. I had made some small code changes to get everything running and I feel it's compiling correctly. I am using the following cmd to compile:

 sdcc -lstm8 -mstm8 -I inc -I ../../Source/inc -I ../../Libraries/STM8L15x_StdPeriph_Driver/inc -I ../../Libraries/STM8L-discovery_Libraries/inc -D STM8L15X_MD -D __CSMC__ --opt-code-size --disable-warning 126 src/main.c

(warning 126 is about unreachable code, I have to define __CSMC__ [Cosmic compiler] because my project was created with STVD which only supports 3 compilers [otherwise, I would need to change a lot of header files]; my MCU is STM8L152C8)

As I said, it compiles, but generates the following warnings:

?ASlink-Warning-Undefined Global '_RTC_SetWakeUpCounter' referenced by module 'main'

?ASlink-Warning-Undefined Global '_GPIO_Init' referenced by module 'main'

?ASlink-Warning-Undefined Global '_ADC_DeInit' referenced by module 'main'

?ASlink-Warning-Undefined Global '_RTC_WakeUpCmd' referenced by module 'main'

?ASlink-Warning-Undefined Global '_FLASH_ProgramOptionByte' referenced by module 'main'

?ASlink-Warning-Undefined Global '_ADC_ChannelCmd' referenced by module 'main'

?ASlink-Warning-Undefined Global '_RTC_ITConfig' referenced by module 'main'

?ASlink-Warning-Undefined Global '_ADC_GetFlagStatus' referenced by module 'main'

?ASlink-Warning-Undefined Global '_CLK_PeripheralClockConfig' referenced by module 'main'

?ASlink-Warning-Undefined Global '_FLASH_EraseOptionByte' referenced by module 'main'

?ASlink-Warning-Undefined Global '_RTC_WakeUpClockConfig' referenced by module 'main'

I am not very experienced and I don't know whether this should be a problem or not. main.map contains:

...
ASxxxx Linker V03.00 + NoICE + sdld,  page 1.
Hexadecimal  [32-Bits]

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
CABS                                00000000    00000000 =           0. bytes (ABS,CON)

      Value  Global                              Global Defined In Module
      -----  --------------------------------   ------------------------
     00000000  _ADC_ChannelCmd
     00000000  _ADC_DeInit
     00000000  _ADC_GetFlagStatus
     00000000  _CLK_PeripheralClockConfig
     00000000  _FLASH_EraseOptionByte
     00000000  _FLASH_ProgramOptionByte
     00000000  _GPIO_Init
     00000000  _RTC_ITConfig
     00000000  _RTC_SetWakeUpCounter
     00000000  _RTC_WakeUpClockConfig
     00000000  _RTC_WakeUpCmd
...

Greping for these keywords tells me that these are function names (without the prefixing underscore) in the STM8L libraries (inside my project). So they are there and I feel I just need a small change in order to prevent this problem.

So, to sum up:
#1 Does anyone know about this problems and how to deal with it?
#2 I don't know whether I can flash my MCU and just check if it still works (as I said, I am inexperienced and I fear to damage the chip with a faulty firmware)
#3 I am not sure, whether I need to use packihx or not. The sdcc manual states the the default output is already the Intel Hex format (which I used previously).

Last but not least: You guys rock! I am really thankful for your project :)
Thanks in advance,
Rolf

------------------------------------------------------------------------------
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=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Kio | 14 Nov 19:14 2014
Picon

support for zasm z80 assembler

Hi,

i currently implement sdcc support in my z80 assembler zasm (http://k1.spdns.de/Git/zasm-4.0.git/).
My first try was to implement the sdasz80 syntax until i discovered that sdcc already supports more than
one z80 assemblers. I compared their output and found that z80asm provides the most standard and
compatible output, but unfortunately it seems to not support segments and sdcc only emits commented-out
segment declarations for z80asm. So i added code to support zasm in sdcc directly.

Question: is there interest to add support for yet another assembler? (standard z80 syntax plus segments)
and if, how should i best submit the patches? Affected files are src/z80/main.c and mappings.i.

Also, i have implemented zasm support by "similarity", based on z80asm. So i still need some advice on some
settings which i do not understand. Who is the best person to ask; maybe just in the mailing list?

Greetings from Germany,

	... Kio !
--

-- 
http://k1.spdns.de/Vintage/Sinclair/
GPG-ID: 80E6A1DA

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Hynek Sladky | 11 Nov 08:24 2014
Picon

Z80: function in RAM

Hello,

I need to make function which must run in RAM (Flash programming in bootloader). So far I haven't found how to do it. Nor in C neither in assembler.

What I have found is way how initialized variables are translated from C to assembly: the value is added to segment _INITIALIZER and space is allocated in _INITIALIZED. But this IMHO can't be used for code: code needs to be compiled for final placement (e.g. _INITIALIZED) and then moved as data to _INITIALIZER segment. Is there any way how to do it?

BTW, it seems to me that there is some problem with crt0.s - I have to have my own start-up routine so I used crt0.s as template. Unfortunately it can't be compiled unless .globl is added for l__INITIALIZE* and s__INITIALIZE* values. Does it work differently when using standard crt0.s?

Thanks,
Hynek Sladky
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Gmane