[ECOS] eCosCentric Cortex-M port contribution

Simon Kallweit simon.kallweit@intefo.ch
Tue Nov 4 20:46:00 GMT 2008

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.

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

Ok sounds like a good idea then. Your code looks cleaner than mine did, 
so it probably is the right way.

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

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

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

Understood. I'll try to cut it down and post a version.

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

Yeah, I had a slightly different naming scheme, but adapting it should 
be simple.

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


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

More information about the Ecos-discuss mailing list