[ECOS] Cortex port

["simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>]

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)

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?
* 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.
* I have prefixed "functional macros" in var_io.h with 
HAL_CORTEXM_STM32_. This seems to be the preferred way. 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?
* I have currently added quite a few CDL options for the clock 
configuration. Things like clock selections, prescalers, nominal clock 
speeds etc. are all available for editing or viewing. Also the 
configuration is checked with a few constraints, so that no invalid 
clock configurations can be made. As there are about 20 options (10 of 
them being read only, showing nominal clock frequencies), I wonder if 
this is too excessive? I also wonder if there should be an API for 
runtime clock reconfiguration?
* 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? Should we leave the big-endian options? The Cortex-M can access 
data memory in big-endian format, but not the code.
* 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.

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.

Best regards,
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