Re: [ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett <nickg at ecoscentric dot com>]

Simon Kallweit <simon.kallweit@intefo.ch> writes:

> Nick Garnett schrieb:
> > "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.
> >
> 
> Yep, I can see. I think I was kind of blinded with the way the
> Cortex-M3 presumed you to do context switching.

The Cortex-M seems to be designed to a particular model that ARM
decree is the right way to do things. Unfortunately that doesn't quite
fit with the way eCos works, so some extra effort is needed to match
them up.
 
> >
> >> 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.
> >
> 
> True, but compared to the ARM port it's like nothing. I think the port
> is very readable.

While there are some bits and pieces copied over from the ARM HAL,
particularly in the debug code, the HAL is structured more like the
PowerPC and MIPS HALs. In some ways the ARM HAL is a bit of a maverick
in the way it is structured.

> 
> >
> >> 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.
> >
> 
> The idea is that you can OR multiple pins of the same port and
> configure/set them in one go.

I'm not really convinced that would be very useful. The pins for a
particular device are the ones that need relating, but they often need
configuring to different modes. See the UART pins for example. I think
having a set of pins defined in one decriptor might be confusing.

> >> 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.
> 
> Ok, I'll port it soon and post it. Btw. I did not find any interface
> to set alarms for the Wallclock. Is there a common interface to set
> such an alarm-wakeup?

There is no alarm support in the wallclock device. Wallclocks are very
variable in the functionality they supply so the driver was designed
to support just the absolute minimum: just read and set a
seconds-since-epoch value.


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