Re: [ECOS] [eCos-discuss] Cortex-M arch questions

[Nick Garnett <nickg at ecoscentric dot com>]

Mike DeSimone <desimone@arlut.utexas.edu> writes:

> I'm trying to work through what is in the Cortex-M architecture
> already.  I've run into some things which are confusing me.
> 
> In packages/hal/cortexm/arch/current/include/hal_intr.h is the line:
> 
> #define CYGNUM_HAL_INTERRUPT_RTC        CYGNUM_HAL_INTERRUPT_SYS_TICK
> 
> The first Cortex-M supported, the STM32, doesn't have a real-time
> clock peripheral, just the SysTick peripheral that comes with the
> Cortex-M core, but the one I'm porting to, the Atmel ATSAM3U, has an
> RTC distinct from the SysTick peripheral.  Normally, I'd name its
> interrupt CYGNUM_HAL_INTERRUPT_RTC, but that's already defined in the
> architecture, so I'm wondering if CYGNUM_HAL_INTERRUPT_RTC has special
> meaning within eCos?  Is it required to be present?  And if so, what
> are its requirements (i.e. which "RTC" would be better to label as the
> RTC?)

When eCos was designed we chose RTC to mean a clock that ticked at
the same rate as the passage of real time and drove the real time
scheduling. We were also expecting to see other clocks that counted
things like execution time of threads, which didn't advance at the
same rate, although these have not materialized.

The name CYGNUM_HAL_INTERRUPT_RTC is special in that it is
used by portable code to refer to the interrupt for this clock and is
thus cast in stone. In hindsight the choice of RTC for this interrupt
was probably the wrong one.

For the RTC device I would suggest adding a postfix. The STM32 does
have an RTC with two interrupts, RTC_GLOBAL and RTC_ALARM. If the
ATSAM3U has only one RTC interrupt I would call it RTC_GLOBAL for
consistency.

> 
> Also, I think I found a bug elsewhere in the STM32 architecture
> files.  Is there a Bugzilla or equivalent for eCos?

There is, follow the links from here:

http://ecos.sourceware.org/problemreport.html


> 
> Finally, I saw some discussion of moving eCos to Subversion in the
> archives.  Did anything come of this? Subversion would be easier for
> me to interface with than CVS; right now, I've got the CVS checkout
> superimposed on a Subversion tree used for local development.

If we are going to move it will be to a distributed RCS system. There
have been some very long discussion threads here recently. It
basically comes down to Mercurial vs Git.


-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071


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