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

[Harald Kipp]

Hi again,

OK, rebuilding under Windows CMD shell is gone. It may work
on a Cygwin shell, but I'd prefer the native system without
too many tools required to get it build.

Anyway, the port is clean and you really invested a lot of
effort, so I decided to add it to the CVS head. Fixing the
Windows environment problem should be easy.

I added missing or changed a few existing copyrights and ran
indent -kr -nut -l 132
on all sources. This will produce more diff lines against
your patch. But it will avoid them in the future, not all
contributors are as disciplined as you are.


At 08:04 16.03.2004 +0100, you wrote:

>Below is the list of changes. The order is not important:
>
>- support for H8 and (partially) ARM MCUs has been added and appropriate
>   makefiles provided,

Different from my ARM sandbox, but no problem.



>- arch subdirectory has been added in the Nut/OS main directory - currently it
>   contains startup code, header file and generic linker scripts for H8/3068F,

I still don't think it would have been required to
use the arch subdir. Actually I have no preference.




>- __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.

I noticed a few lines, where you replaced program memory
strings by standard literals in NUTDEBUG sequences. Some
application may now fail to link with NUTDEBUG, because
they simply run out of RAM.



>- file include/sys/config.h has been renamed to nutconfig.h and all references
>   to it have been changed accordingly - config.h is also part of newlib 
> (which
>   is included in H8 gcc package) so there was obvious conflict,

Good point.



>- directory include/cpu has been renamed to arch - just a cosmetic chnge,

As I said above, no preference. If you like it that
way, we will follow. :-)



>- ureg_t, reg_t and uptr_t typedefs has been moved from include/compiler.h to
>   include/sys/types.h; SRF* macro definitions has been moved to _IMAGECRAFT
>   only section - for avr-gcc these macros are provided byc avr-libc,

I'm even wondering why they made it in there. Was that me?



>- files include/sys/uart.h and include/sys/ir.h has been moved to include/dev
>   and os/ir.c to dev - these are the right places for these files,

My first thought was: NO, UNACCEPTABLE. I then realized
that I mismatched global with sys. You are right, that's
indeed dev stuff.



>- places where pointers were casted to integers have been adjusted (many, many
>   files); format strings in printf like functions have been changed as well,

Many thanks, the original u_short casts had been created
with the clear statement, that Nut/OS was not intended to
run on any other platform than ATmega103. :-)



>- files ctx_*.c, tmr_*.c have been renamed and moved to os/arch subdirectory;
>   nutinit.c has been also splitted into 4 parts,

OK.



>- macro NutJumpOutCritical() has been added in atom.h; on H8 and ARM 
>interrupts
>   may have different priorities so it would be good to save current value of
>   condition register (or whatever is it called) before entering critical 
> section
>   so smarter Nut{Enter,Exit}Critical() have been defined (for H8 at the 
> moment);
>   the nice side effect of such definitions is that a programmer must 
> always close
>   a critical section (a compiler will remind him about it ;-) ); not so nice
>   is the fact that special function/macro must be provided in order to 
> exit from
>   critical section dur to an exception, eg.:
>   [.....]
>   NutEnterCritical();
>   [.....]
>   if (an_exception_occured)
>      NutJumpOutCritical();
>   [.....]
>   NutExitCritical();
>   [.....]

Frankly, I need some time to fully understand this.




>- 9366 EEPROM routines has been added for H8,

Nice.



>- SCI (aka USART) driver has been added for H8 (works pretty well although a
>   lot of festures are not implemented yet),

OK.



>- siple SCI based devices for debugging are provided (scih8dbg.c),


OK.



>- RTL8019 driver for H8 is in separate file but I am going to merge changes
>   I have made into original driver;  BTW. couldn't be original RTL driver 
> files
>   renamed to a more descriptive names, eg. rtl8019.*?

Similar as above, only ATmega103 and RTL8019AS are supported. :-)

Yeah, we'll change this.




>- interrupt code in dev directory has been splitted into architecture
>   dependant files.

OK.




>Of course it is sure that I have forgotten to mention a lot of changes but all
>is in the sources. ;-)

And I set aside to list every file in ChangeLog or add
individual commit messages.



>Just a few suggestions at the end:
>
>- there is a lot of files with functions marked as deprecated which just
>   pollute source tree; IMO they should be removed before the next release,

Yes.



>- IMO bankmem.c should be moved to dev directory,

Agreed.



>- include/sys/atomic.h should be removed - any other file doesn't include it,

If I remember correctly, this is the first public complain.
That's astonishing, because I'm stumbling over it all the
time. Sheer lazyness kept it alive.




>- AVR interrupt functions/variables definitions should be put into one file.

No, because they consume a lot of space.

In general I'd recommend to split even more files. The
linker will always add a complete module, even if the
application needs a single routine only.




>Harald, I hope also that my patch will help you to make port for ARM beacause
>a lot of stuff is "ARM ready" - H8/300H and H8S in advanced mode have 32 bit
>internal architecture (with 16 bit data bus).

I already made some of these changes, but your port is
much more complete and I'll take it over. On the other
hand I made additional changes, like using 32-bit loop
counters for the ARM.

Great work, Jan. I really appreciate it.

Harald