[En-Nut-Discussion] State of the unix emulation: was: New __NUT_EMULATION__ macro

[Matthias Ringwald]

On Mar 6, 2009, at 8:32 PM, Ole Reinhardt wrote:

> Hi Matthias,
>
>> Ole just asked about the state of the unix emulation. the good think:
>> it works with the ETH BTnut distribution. There it basically supports
>> all software parts and the UART emulation. Since my fixed yesterday,
>> it even builds on the iPhone. :)   In BTnut, we have our own build
>> system, which is basically a snapshot of the nut/os makefile system
>> from 2004 and adapted minimally to follow changes in the nut/os tree.
>
> Ok, perhaps I'll find some time to make it at least running with a
> minimal configurator configuration. This should not be that much of a
> pain.
what about the nutsetup tool. I've used this as I did about four years  
ago. :)

> If the code itself is running everything else is just about filling in
> the dots.
I know that the Bluetooth stack works flawless. I did not test  
anything else.
I remember that the simulated nut timer (tick every ms) worked kind of  
Ok on OS X
but was to slow on linux. in the meantime, we changed the timer  
implementation.
I guess the we could get rid of the simulated timer interrupt and just  
use the
unix system clock (which should be correct ...)

>
>> Ole: yes, using "capabilities" instead of the __NUT_EMULATION__ does
>> make sense. However, the assumption for __NUT_EMUALTION__ is only  
>> that
>> we have a POSIX system supporting the standard C library and  
>> pthreads.
>> So, there is not much to gain.
>
> The thought was to also define "__arm__" or similar compiler /
> architecture dependant macros as a new "capability flag" to remove  
> these
> architecture specific macros completely from code. The iPod port might
> be the first, but not the last situation where these dependencies  
> might
> hurt.

Ok. I got it. Like defines in config.h in a autotools build system.  
that would be good.
I guess __NUT_EMUALTION__ could already be acccepted in some places  
for exactly this.
It is a "capability" in your sense. Others would be the architecture  
register width (8/16/32..)

cheers,
  Matthias