This is the mail archive of the
mailing list for the eCos project.
Re: Cortex port
- From: "simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>
- To: "simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>, ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 10 Sep 2008 16:52:29 +0200
- Subject: Re: [ECOS] Cortex port
- References: <48C7CD52.firstname.lastname@example.org> <20080910144351.GC30859@lunn.ch>
Andrew Lunn wrote:
On Wed, Sep 10, 2008 at 03:36:18PM +0200, email@example.com wrote:
As some of you know, I'm currently writing a port for the Cortex-M3,
specifically the STM32 CPU. I'm making good progress. The following is
in place and working so far:
* clock configuration using CDL (number of options might be a bit
excessive, but the STM32 offers quite a few possibilities for clock
configuration, see below)
* basic initializiation of cpu and startup code (clocks, flash,
* serial debug/diagnostic driver (ethernet is not available on STM32)
* simple "framework" for GPIO configuration and manipulation
* partly (as I go) written register definitions for the STM32 (the STM32
provided "header" files are pretty unusable)
A few comments...
You need to clearly separate your code into two or maybe three
1) The arch package. This contains things which are available on all
Cortex-M3 processors. Basic startup, interrupt handling, the timer
tick if it is implemented by the interrupt controller, task
2) STM32 package. Things which are available on each STM32 processor.
The GPIO framework, the hal_diag serial driver.
3) The target package. This contains things which are specific to your
target, eg control of the LEDS.
Some of the assembly language code needed at startup gets spread
around different packages. This is then included using macros.
The code is separated in an arch, var and target packages. But of
course, much work is done in any of the 3 packages right now.
The next step will be the implementation of IRQ handling and context
switching, which is not done yet, and will be rather tricky. During
development a few questions came up, which I hope some of you might
* In quite a few places I have to set and clear individual bits of
registers. With the normal HAL_WRITE/READ_UINT32 access macros this is
obviously a bit tedious sometimes. I didn't found any SET/CLEAR BIT
macros. Is there a good reason for this? I have now written my own
macros and added them to the hal_io.h headerfile. Any objections?
There was a discussion about this a while ago. The AT91 USB driver
wanted something similar. For some reason it was rejected, but i don't
remember why. Search the archive.
I'll check the archives then ...
* I currently have prefixed all my STM32 register macros (var_io.h) with
CYGARC_HAL_STM32_. I wonder if this is necessary, or the right way. It
seems that different ports don't follow the same guidelines here. I'd
much prefer to just prefix them with STM32_ as it would make the
definitions rather a bit simpler to read and type.
The important thing is that there is something consistent so that name
space pollution is not a problem. As you said, both naming schemes are
in use, so it does not really matter. STM32_ is O.K. for me.
Ok, i'll stick to STM32_ if nobody else is bothered.
* I have prefixed "functional macros" in var_io.h with
HAL_CORTEXM_STM32_. This seems to be the preferred way.
That is good.
var_io.h the right place for things like GPIO configuration and
manipulation, enabling/disabling clocks? As for example configuration of
GPIO ports is rather too complex to be done in a macro, I have
implemented a helper function in the stm32_misc.c of the variant. The
macro then points to this function. Is this OK, or should the complete
GPIO framework, as well as other helper for things like
enabling/disabling/reseting clocks be moved to stm32_misc?
This sounds O.K. Try to keep the SET/RESET/GET macros as macros not
function calls, since they want to be fast, but calling functions for
the less used things, like setting the direction, enabling interrupts
etc are O.K. as functions.
GET/SET etc. are normal macros. But GPIO configuration is currently done
in a function call, as using macros would inappropriately blow up code size.
* The architecture CDL (as copied from the ARM architecture) still
contains options for THUMB and THUMB interworking. I think these can be
completely removed, as THUMB-2 is the only instructions set for the
Cortex-M, and the defines should only be used in the ARM architecture.
Should we leave the big-endian options? The Cortex-M can access
data memory in big-endian format, but not the code.
I would probably take it out. Somebody can add it back if they need it
and have hardware to test it.
Ok, I'll take it out then.
* What about ARM-ICE Thread support? The ICE currently not supports
Cortex CPUs, but I guess they will in the future. I don't have an
ARM-ICE and will not be able to test.
This does not seem to get used much at all. Take it out.
These were just a few questions, I guess a lot more will arise sooner or
later. The code not nearly mature enough to post patches, but If anyone
is interested to help on the port, please let me know. I could also
setup SVN access for simpler development.
Please do post your code sooner rather than later. It is important to
get the basic structure right, right from the beginning.
Ok, I'll post the code as soon as the basics are there and I've done
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss