This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cortex port


Andrew Lunn wrote:
On Wed, Sep 10, 2008 at 03:36:18PM +0200, simon.kallweit@intefo.ch wrote:
Hi

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, relocation etc.)
* 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
packages....

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


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 comment on:

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


Anyway, is 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. Right?

Right.


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.

Fine :)


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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]