[Bug 1001090] New: Added option to run system timer with internal clock

[Bug 1001090] New: Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

           Summary: Added option to run system timer with internal clock
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ecos@hotmail.co.uk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1040)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1040)
patch

For the Stellaris Cortex-M3 800 Series, it is mandatory to use internal clock
for the system timer. I have included a patch that does affect the default
behavior of the Cortex M HAL (use of external clock).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #2 from Christophe Coutand <ecos@hotmail.co.uk> 2010-12-18 11:21:28 GMT ---
CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
configuration. Is that ok or shall it be defined in the cortexm CDL?

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-16 17:08:10 GMT ---
(In reply to comment #2)
> CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
> configuration. Is that ok or shall it be defined in the cortexm CDL?

I downloaded your parch and produced a CDL bool option into LPC17xx port ( Bug
1001114 ). Needles to say, works fine. Of course there is (always) a question
of flavor: a bool as is now or data - CDL defines CYGARC_REG_SYSTICK_CLK_SRC as
a choice between Int/Ext (no need for CYGSEM_HAL_SYSTICK_CLK_INTERNAL ).

Regarding your question: IMO this bit is a part of the Cortex-M architecture
and it would be good if Cortex-M architecture CDL reflects it.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergei.gavrikov@gmail.com

--- Comment #4 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-17 13:17:56 GMT ---
(In reply to comment #3)
> (In reply to comment #2)
> > CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
> > configuration. Is that ok or shall it be defined in the cortexm CDL?
> 
> I downloaded your parch and produced a CDL bool option into LPC17xx port ( Bug
> 1001114 ). Needles to say, works fine. Of course there is (always) a question
> of flavor: a bool as is now or data - CDL defines CYGARC_REG_SYSTICK_CLK_SRC as
> a choice between Int/Ext (no need for CYGSEM_HAL_SYSTICK_CLK_INTERNAL ).
> 
> Regarding your question: IMO this bit is a part of the Cortex-M architecture
> and it would be good if Cortex-M architecture CDL reflects it.

IMO, yet another solution would be to move the clock management in the variant
HALs and in the architecture HAL to have those famous 'Clock control' macros:

#define HAL_CLOCK_INITIALIZE( _period_ )   hal_clock_initialize( _period_ )
#define HAL_CLOCK_RESET( _vec_, _period_ ) hal_clock_reset( _vec_, _period_ )
#define HAL_CLOCK_READ( _pvalue_ )         hal_clock_read( _pvalue_ )
...

It would be nice to know the opinion of Nick Garnett.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #5 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-17 16:37:20 GMT ---
The arch HAL could allow the variant to re-define the RTC clock macros (
similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 

Since most variant will use the current macros, we require an option to select
between internal and external clock source for the systick.

If required, when the discussion is settled I can generate a new patch.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-17 18:43:19 GMT ---
(In reply to comment #5)
> The arch HAL could allow the variant to re-define the RTC clock macros (
> similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 
> 
> Since most variant will use the current macros, we require an option to select
> between internal and external clock source for the systick.

Agreed. It is a good proposal.

> If required, when the discussion is settled I can generate a new patch.

OK. Thanks.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001114

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #7 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-19 19:06:33 GMT ---
Let's go ahead. Christophe, can you, please, submit a version with
CYGHWR_HAL_CLOCK_DEFINED protection?

Thanks.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-20 10:08:57 GMT ---
(In reply to comment #5)
> The arch HAL could allow the variant to re-define the RTC clock macros (
> similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 
> 
> Since most variant will use the current macros, we require an option to select
> between internal and external clock source for the systick.
> 
> If required, when the discussion is settled I can generate a new patch.
> 
> Christophe

Christophe

Could you consider some CDL interface for clock source selection?
Some controllers (STM32 / LPC17xx) have provision for both sources and it would
be good if user could choose in configtool.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Christophe Coutand <ecos@hotmail.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1040|0                           |1
        is obsolete|                            |

--- Comment #9 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-20 18:46:24 GMT ---
Created an attachment (id=1092)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1092)
Add SysTick clock source + allow RTC clock macro definition from
variant/platform

Hi,

Patch attached for your review. I have added the option to redefine the RTC in
the variant / platform HAL, not sure how useful that is.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #10 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-20 20:06:57 GMT ---
Christophe, thank you. The patch looks good for me, however, I was able to test
a build process only (having no real H/W). Ilija, does correspond the patch
your needs (BSP)?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-20 23:29:47 GMT ---
(In reply to comment #10)
> Christophe, thank you. The patch looks good for me, however, I was able to test
> a build process only (having no real H/W). Ilija, does correspond the patch
> your needs (BSP)?

Looks nicer than I required and compiles without warnings. I can't test runtime
at the moment as I am away. I am returning as Saturday so I can test during
weekend. I may also arrange remote testing for tomorrow but it's not sure.

cu.
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #12 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-21 20:29:25 GMT ---
Created an attachment (id=1093)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1093)
Support for STM32 internal SysTick clock source.

(In reply to comment #10)
> Christophe, thank you. The patch looks good for me, however, I was able to test
> a build process only (having no real H/W). Ilija, does correspond the patch
> your needs (BSP)?

Sergei

I have tested on both LPC-1766-STK and STM32 E Eval Board.

   - LPC 1766 STK board utilizes only Internal clock source and works fine.

   - STM 32 utilizes both sources on-chip. External works fine as before, but
support for Internal was missing (Internal clock is not an option without
Christophe's patch.) Now it is so I added support to STM32 variant.

The attached patch is tested with both Internal and External clock source.

Christophe, thanks for nice clock source selector.

// Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-22 21:21:04 GMT ---
Checked-in (both patches). Tnaks for your contribution.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-22 21:21:58 GMT ---
Mark the issue as RESOLVED.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001090] New: Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

           Summary: Added option to run system timer with internal clock
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ecos@hotmail.co.uk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1040)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1040)
patch

For the Stellaris Cortex-M3 800 Series, it is mandatory to use internal clock
for the system timer. I have included a patch that does affect the default
behavior of the Cortex M HAL (use of external clock).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #2 from Christophe Coutand <ecos@hotmail.co.uk> 2010-12-18 11:21:28 GMT ---
CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
configuration. Is that ok or shall it be defined in the cortexm CDL?

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-16 17:08:10 GMT ---
(In reply to comment #2)
> CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
> configuration. Is that ok or shall it be defined in the cortexm CDL?

I downloaded your parch and produced a CDL bool option into LPC17xx port ( Bug
1001114 ). Needles to say, works fine. Of course there is (always) a question
of flavor: a bool as is now or data - CDL defines CYGARC_REG_SYSTICK_CLK_SRC as
a choice between Int/Ext (no need for CYGSEM_HAL_SYSTICK_CLK_INTERNAL ).

Regarding your question: IMO this bit is a part of the Cortex-M architecture
and it would be good if Cortex-M architecture CDL reflects it.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergei.gavrikov@gmail.com

--- Comment #4 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-17 13:17:56 GMT ---
(In reply to comment #3)
> (In reply to comment #2)
> > CYGSEM_HAL_SYSTICK_CLK_INTERNAL is a CDL option to be defined in the variant
> > configuration. Is that ok or shall it be defined in the cortexm CDL?
> 
> I downloaded your parch and produced a CDL bool option into LPC17xx port ( Bug
> 1001114 ). Needles to say, works fine. Of course there is (always) a question
> of flavor: a bool as is now or data - CDL defines CYGARC_REG_SYSTICK_CLK_SRC as
> a choice between Int/Ext (no need for CYGSEM_HAL_SYSTICK_CLK_INTERNAL ).
> 
> Regarding your question: IMO this bit is a part of the Cortex-M architecture
> and it would be good if Cortex-M architecture CDL reflects it.

IMO, yet another solution would be to move the clock management in the variant
HALs and in the architecture HAL to have those famous 'Clock control' macros:

#define HAL_CLOCK_INITIALIZE( _period_ )   hal_clock_initialize( _period_ )
#define HAL_CLOCK_RESET( _vec_, _period_ ) hal_clock_reset( _vec_, _period_ )
#define HAL_CLOCK_READ( _pvalue_ )         hal_clock_read( _pvalue_ )
...

It would be nice to know the opinion of Nick Garnett.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #5 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-17 16:37:20 GMT ---
The arch HAL could allow the variant to re-define the RTC clock macros (
similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 

Since most variant will use the current macros, we require an option to select
between internal and external clock source for the systick.

If required, when the discussion is settled I can generate a new patch.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-17 18:43:19 GMT ---
(In reply to comment #5)
> The arch HAL could allow the variant to re-define the RTC clock macros (
> similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 
> 
> Since most variant will use the current macros, we require an option to select
> between internal and external clock source for the systick.

Agreed. It is a good proposal.

> If required, when the discussion is settled I can generate a new patch.

OK. Thanks.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001114

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #7 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-19 19:06:33 GMT ---
Let's go ahead. Christophe, can you, please, submit a version with
CYGHWR_HAL_CLOCK_DEFINED protection?

Thanks.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-20 10:08:57 GMT ---
(In reply to comment #5)
> The arch HAL could allow the variant to re-define the RTC clock macros (
> similar as the PPC HAL for instance with CYGHWR_HAL_CLOCK_DEFINED ). 
> 
> Since most variant will use the current macros, we require an option to select
> between internal and external clock source for the systick.
> 
> If required, when the discussion is settled I can generate a new patch.
> 
> Christophe

Christophe

Could you consider some CDL interface for clock source selection?
Some controllers (STM32 / LPC17xx) have provision for both sources and it would
be good if user could choose in configtool.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Christophe Coutand <ecos@hotmail.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1040|0                           |1
        is obsolete|                            |

--- Comment #9 from Christophe Coutand <ecos@hotmail.co.uk> 2011-01-20 18:46:24 GMT ---
Created an attachment (id=1092)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1092)
Add SysTick clock source + allow RTC clock macro definition from
variant/platform

Hi,

Patch attached for your review. I have added the option to redefine the RTC in
the variant / platform HAL, not sure how useful that is.

Christophe

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #10 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-20 20:06:57 GMT ---
Christophe, thank you. The patch looks good for me, however, I was able to test
a build process only (having no real H/W). Ilija, does correspond the patch
your needs (BSP)?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-20 23:29:47 GMT ---
(In reply to comment #10)
> Christophe, thank you. The patch looks good for me, however, I was able to test
> a build process only (having no real H/W). Ilija, does correspond the patch
> your needs (BSP)?

Looks nicer than I required and compiles without warnings. I can't test runtime
at the moment as I am away. I am returning as Saturday so I can test during
weekend. I may also arrange remote testing for tomorrow but it's not sure.

cu.
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #12 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-21 20:29:25 GMT ---
Created an attachment (id=1093)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1093)
Support for STM32 internal SysTick clock source.

(In reply to comment #10)
> Christophe, thank you. The patch looks good for me, however, I was able to test
> a build process only (having no real H/W). Ilija, does correspond the patch
> your needs (BSP)?

Sergei

I have tested on both LPC-1766-STK and STM32 E Eval Board.

   - LPC 1766 STK board utilizes only Internal clock source and works fine.

   - STM 32 utilizes both sources on-chip. External works fine as before, but
support for Internal was missing (Internal clock is not an option without
Christophe's patch.) Now it is so I added support to STM32 variant.

The attached patch is tested with both Internal and External clock source.

Christophe, thanks for nice clock source selector.

// Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-22 21:21:04 GMT ---
Checked-in (both patches). Tnaks for your contribution.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001090] Added option to run system timer with internal clock

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-22 21:21:58 GMT ---
Mark the issue as RESOLVED.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.