[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