[ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

"simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:

> 
> This is good news. Already checked out and tried on my
> evalboard. Seems to run, expect some small issues. I have had a look
> at you're approach to context switching and interrupt handling. It's
> quite nicely done, although you don't use NVIC exception handling for
> normal context switches during thread execution, which is something I
> absolutely tried to do (and had lots of trouble with :).

I tried that approach originally and had trouble with it too. Keeping
all thread context switching entirely in thread mode made a lot of
stuff much simpler, particularly the use of the two stacks.

> Also, your
> port does not have a unified SavedRegisters structure, which mine
> had.

I also tried that originally, but decided that the extra code needed
to save and restore compatible register sets, particularly during
interrupts was an unnecessary burden. The only place that the
different formats matter are in the debug code, where a little extra
code probably doesn't matter. The result is that threads, exceptions
and interrupts can use the most natural and efficient code to push and
pop state.

To be honest, I have never been entirely convinced that the use of a
common saved state format for all contexts was the right approach,
despite it being my idea. So this HAL was a small experiment to see
how using different formats would work. I think it has worked very
well.

> But it's nice that so much is written in plain C, my port has
> rather more assembler code.

Given that one of the features of the Cortex-M was that it could be
programmed in C throughout, I wanted to try and keep as close to that
idea as possible. I didn't quite manage it since there are some things
that eCos needs doing that can only be achieved in assembler.

> Another difference is your GPIO framework for the STM32. As it seems
> your framework does not support "chanining" multiple pins on the same
> pin for configuration, which mine offered. In contrast your framework
> offers the possibility to store the configuration directly in the pin
> definition, which is a nice thing I guess. I might add support for
> chaining multiple pins, if there is nothing against it?

I'm not sure what you mean by chaining here. Could you explain.

 
> My port also featured some more "helper macros". This included things
> like enable/disable/reset peripheral clocks, setup FSMC controllers
> etc. which obviously improve code readability. Is there interest to
> get such macros in the main repo?

My general approach to macros is that things that get done a lot
(like configuring GPIO lines), or which are exported to more generic
code (like the interrupt mask stuff) should go into macros.  However,
stuff that will only ever be called once (for example in a driver or
in HAL init code) should usually just be written out in the code. This
makes things easier for future maintenance since you don't have to go
searching for a macro defined in some obscure header.

So for things like peripheral clocks, which may be manipulated in
different drivers, I suspect a macro may be useful. However, for the
FSMC I suspect it is not very useful since this tends to be set up
once, and having the code scattered in various macros makes it harder
to read and maintain.

> 
> Also I had done some more register definitions which I can add.

Typing in register definitions is the most time consuming part of a
new port, so any new definitions will be welcome. Just make sure they
conform to the current naming and layout convention.

> I also
> have a working wallclock driver for the STM32, which I will port to
> your port :) Will it be included or do you already have such a driver
> in the pipeline?

We don't currently have a wallclock driver, so please feel free to
contribute yours. 

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss