[ECOS] Cortex port

[simon.kallweit@intefo.ch]

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