[En-Nut-Discussion] Runtime library dependencies

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Fri Sep 28 14:03:12 CEST 2012


>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi developers, the changes introduced to the 8-bit AVR parts of
    Harald> our code recently require avr-libc. Previous versions didn't
    Harald> include this dependency and were working fine with ImageCraft's
    Harald> runtime library.

    Harald> I know, that the number of ImageCraft users for Nut/OS never
    Harald> reached any noticeable figure, that ImageCraft is closed source
    Harald> and that the company promotes and supports Salvo OS, not
    Harald> Nut/OS. But that's not the point.

    Harald> In general, I do not think that it is a good idea to stick to a
    Harald> specific runtime library. If a some runtime libraries provide
    Harald> useful functions, we should use them, no question. But please,
    Harald> do not remove the independent code parts. Keep them as a
    Harald> fallback alternative. For avr-libc use

    Harald> #if defined(__AVR_LIBC_VERSION__) /* Code that requires
    Harald> avr-libc. */ #else /* Code for other libs or stand-alone
    Harald> code. */ #endif

    Harald> My reason for trying each final version with Imagecraft is to
    Harald> make sure, that we do not run into dependencies, which we may
    Harald> later regret.

    Harald> I never got Nut/OS implemented for ImageCraft (although Richard
    Harald> kindly provided a free version). I'm aware, that the ARM code
    Harald> makes some use of newlib specific features. But that shouldn't
    Harald> be an invitation to replace already standalone working code with
    Harald> newlib features. At least the very first Nut/OS for ARM
    Harald> implementation worked without any C library at all. May be I
    Harald> should re-awake this feature, which is still available in the
    Harald> Configurator.

Harald,

_delay_loop_2 is implemented in avr-libc/include/util/delay_basic.h like
void
_delay_loop_2(uint16_t __count)
{
        __asm__ volatile (
                "1: sbiw %0,1" "\n\t"
                "brne 1b"
                : "=w" (__count)
                : "0" (__count)
        );
}

can we perhaps pull that code in, so we resolve the avr-libc dependacy? Or
somebody clean-room reimplement it if the avr-libc license doesn't fit? Or
we ask Marek Michalkiewicz and Joerg Wunsch for another license?
Such a small and clean delay loop reliefs us from a lot of #ifdef cruft....

What headers does ImageCraft provide? I think recent changes (by me) also
depend on a lot of probably avr-libc specific 

B.t.w: Can you ask you mailer to break the lines resonable?

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



More information about the En-Nut-Discussion mailing list