Re: [ECOS] Cortex port

[Andrew Lunn <andrew at lunn dot ch>]

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

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

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

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

    Andrew

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