This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

compile two assembly func

Hi all,
I am stuck up with an issue in Keil uvision 3

I am trying to create a project with combination of C source and assembly source files.

I am trying to write all the basic functions like delay, lcd driver etc, in different assembly files eg. delay.a51 ,lcd.a51

I include these A51 file in project and call these functions in Main.c file. Now the problem is I am successfully calling delay function, but i am not able to call lcd functions, rather gives me a warning saying

assembling lcd_driver.a51...
linking...
*** WARNING L7: MODULE NAME NOT UNIQUE
    MODULE:  lcd_driver.obj (ASM_COD)
*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL
    SYMBOL:  _LCD_INTIALISE
    MODULE:  SPI_Protocol_v2.obj (SPI_PROTOCOL_V2)
*** WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL
    SYMBOL:  _LCD_INTIALISE
    MODULE:  SPI_Protocol_v2.obj (SPI_PROTOCOL_V2)
    ADDRESS: 019AH

0 Error(s), 3 Warning(s).

The M51 file says

BL51 BANKED LINKER/LOCATER V6.11, INVOKED BY:
G:\KEIL\C51\BIN\BL51.EXE SPI_Protocol_v2.obj, delay_ms.obj, lcd_driver.obj TO SPI_Protocol RAMSIZE (256)


MEMORY MODEL: SMALL


INPUT MODULES INCLUDED:
  SPI_Protocol_v2.obj (SPI_PROTOCOL_V2)
  delay_ms.obj (ASM_COD)
  G:\KEIL\C51\LIB\C51S.LIB (?C_STARTUP)
  G:\KEIL\C51\LIB\C51S.LIB (?C?SIDIV)
  G:\KEIL\C51\LIB\C51S.LIB (?C?LLDIDATA)
  G:\KEIL\C51\LIB\C51S.LIB (?C?LLDIDATA0)
  G:\KEIL\C51\LIB\C51S.LIB (?C?LSTIDATA)
  G:\KEIL\C51\LIB\C51S.LIB (?C?LSTKIDATA)
  G:\KEIL\C51\LIB\C51S.LIB (?C?LROL)
  G:\KEIL\C51\LIB\C51S.LIB (?C?UIDIV)

It looks like it is ignoring lcd_driver.obj

What am i doing wrong ??

Parents
  • There are numerous reasons why one might consider writing an LCD driver in assembler; especially if the facilities to be provided by that driver extend beyond the basic boring static text that many developers seem to be satisfied with.

    You got that backwards. To the negligibly small extent that the boringness, staticness or textness of the display has any relation to whether an LCD driver should be written in C or assembler, it's actually such simple applications that would be feasible in asm. It's the additional complexity of a more fully featured, general-purpose driver that will make the case for choosing C.

Reply
  • There are numerous reasons why one might consider writing an LCD driver in assembler; especially if the facilities to be provided by that driver extend beyond the basic boring static text that many developers seem to be satisfied with.

    You got that backwards. To the negligibly small extent that the boringness, staticness or textness of the display has any relation to whether an LCD driver should be written in C or assembler, it's actually such simple applications that would be feasible in asm. It's the additional complexity of a more fully featured, general-purpose driver that will make the case for choosing C.

Children