up_mdelay multiple definitions

[robin-raymond]

In file:
nuttx/arch/arm/src/common/up_mdelay.c

void up_mdelay(unsigned int milliseconds)
{
  volatile unsigned int i;
  volatile unsigned int j;

  for (i = 0; i < milliseconds; i++)
    {
      for (j = 0; j < CONFIG_BOARD_LOOPSPERMSEC; j++)
        {
        }
    }
}

is defined. But if you enable the timer driver you get:

void up_mdelay(unsigned int milliseconds)
{
  up_udelay(USEC_PER_MSEC * milliseconds);
}

in file nuttx/drivers/timers/arch_timer.c

And thus the compiler error becomes:

nuttx/nuttx/staging/libdrivers.a(arch_timer.o): In function `up_mdelay':
arch_timer.c:(.text+0x208): multiple definition of `up_mdelay'
nuttx/nuttx/staging/libkarch.a(up_mdelay.o):up_mdelay.c:(.text+0x0): first defined here

[xiaoxiang781216]

@robin-raymond you shouldn't do these two things at the same time:
1.Include up_mdelay.c in your CSRCS
2.Enable CONFIG_ARCH_TIMER in your defconfig
Please see the detailed discussion here:
#353
You can remove up_mdelay.c from CSRCS, because the implemenation in arch_timer.c is more accurate.

[patacongo]

drivers/timer/arch_timer.c cannot be used with most configurations. If you do want to use it for some reason, you will need to manually modify the architecture's Make.defs file to remove the duplicate builds of up_mdelay.c and friends. There was a lot of discussion about this, but no agreement.  I argued that: 1) architectures that do support up_mdelay() et al must disable selection of the arch_timer driver, or 2) A new configuration option must be added to control if the the architecture should or should not build up_mdelay.c and friends. It is really a pretty bad design.  If you get motivated to clean it up, feel free.  Just submit a PR.  I like option #2 Greg

…

On 3/7/2020 9:12 AM, Robin Raymond wrote: In file: |nuttx/arch/arm/src/common/up_mdelay.c| |void up_mdelay(unsigned int milliseconds) { volatile unsigned int i; volatile unsigned int j; for (i = 0; i < milliseconds; i++) { for (j = 0; j < CONFIG_BOARD_LOOPSPERMSEC; j++) { } } } | is defined. But if you enable the timer driver you get: |void up_mdelay(unsigned int milliseconds) { up_udelay(USEC_PER_MSEC * milliseconds); } | in file |nuttx/drivers/timers/arch_timer.c| And thus the compiler error becomes: |nuttx/nuttx/staging/libdrivers.a(arch_timer.o): In function `up_mdelay': arch_timer.c:(.text+0x208): multiple definition of `up_mdelay' nuttx/nuttx/staging/libkarch.a(up_mdelay.o):up_mdelay.c:(.text+0x0): first defined here | — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#475>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFUG6UWI775BBF7J2VGQNLRGJP4HANCNFSM4LDQO7FQ>.

[robin-raymond]

Thank you for the help! I disabled Timer Arch Implementation (TIMER_ARCH) and the problem stopped. I do think that either 1 or 2 should be done though. I do agree there should be some coordination though between the timer arch and the system. I'm less confident on the code just yet to submit a patch (still learning but enthusiastic).