[En-Nut-Discussion] Nut/OS port for H8/300H.

[Matthias Ringwald]

Hi Jan

thanks for your work on the H8 port.

It looks like your work helps me making my unix emulation port.

with the __HARVARD_ARCH__ flag those _P functions can easily
be handled. as you said compatibilty #defines are needed.

I assume someone writing a AVR application for nut/os
and then compiling it for a unix environment, beeing able
to debug it with all provided tools. Because of this,
those defines are really required.

another point is sorting the sources to be platform specific
and paltform dependend. I started throwing in #ifdefs
but using seperate files at least for startup, etc.. is
very nice.

right now I'm implementing a stdio wrapper, I discussed with Harald
recently on the list, so I can use native stdio calls to implement
e.g. the uart driver by replacing "uart0" with "/dev/ttyS0" ...

regards,
matthias



On 16.03.2004, at 23:51, Jan Dubiec wrote:

>>> - __HARVARD_ARCH__ has been added which which allows to turn off 
>>> building
>>>    of functions with _P suffix on non Harvard based micros,
>>
>> That might become a problem. Most commercial projects I
>> know of make extensive use of string constants in program
>> space. At least something like
>> #define printf_P printf
>> would be required to maintain portability of existing
>> applications.
> ...
> So, when __HARVARD_ARCH__ is defined (which should be defined for
> AVRs!), _P functions are built. On von Neumann MCUs only few aliases
> must be provided:
> #define strlen_P(x)             strlen(x)
> #define strcpy_P(x,y)           strcpy(x,y)
> #define strcmp_P(x, y)          strcmp(x, y)
> #define memcpy_P(x, y, z)       memcpy(x, y, z)
> #define fputs_P(x, y)           fputs(x, y)
> #define fprintf_P               fprintf