This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: eCosCentric Cortex-M port contribution
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
alarm-wakeup?
Simon
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss