Re: GIT Issues?

[Cedric Berger]

Hello,

On 03.07.23 23:58, Joel Sherrill wrote:
On Mon, Jul 3, 2023 at 11:29 AM Christian Mauderer  
wrote:


Hello Cedric,

Am 03.07.23 um 08:47 schrieb Cedric Berger:
> Hello,
>
> Two issues here:
>
> 1) When looking at RTEMS on github, it seems everything stopped
being
> updated on March 23.
>  > 2) Then going to https://www.rtems.org, clicking "Git" yield
this page:
>
>      Trac Error
>      Page Developer/Git not found
>

Sounds like a broken link on the homepage. As a workaround, you can
reach https://git.rtems.org directly.


It was trying to guide you to what is now in the Users Guide somewhere
around here 
(https://docs.rtems.org/branches/master/user/start/sources.html)
but also that old content included some of the git instructions from 
the Software

Engineering Guide.

Anyway, I changed it to a direct link to git.rtems.org 
.


Thank you.

That doesn't resolve the issue of updating github but that's a 
different problem.


Do you think it will be resolved soon, or I should just stop forking 
from the github repo?


Cedric

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add currently best clang-format configuration to repository?

[Gedare Bloom]

OK I will prepare something soon. I have my WIP version at
https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat

I think the format file itself should be just about stable. I will
make one more test and check of it within the next few days, and then
send the patch hopefully early next week.

On Fri, Jun 30, 2023 at 1:44 AM Sebastian Huber
 wrote:
>
> Hello,
>
> even though the clang-format support for RTEMS is not yet perfect, I
> think it would still make sense to already add the clang format file to
> the RTEMS repository. This helps to get the currently best thing
> available and for example use it for new code (BSPs).
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs v3] c-user: Update references to rtems_task_wake_after

[Kinsey Moore]

rtems_task_wake_after takes a parameter in terms of a count of clock
ticks and not a measure in a subunit of seconds. This updates
documentation to reflect that. This also makes obvious the caveat about
the first tick wait not being a whole tick and points the user at a
replacement for better accuracy.

Updates #4772
---
 c-user/scheduling-concepts/background.rst |  8 +++
 c-user/task/directives.rst| 27 ++-
 c-user/task/introduction.rst  |  4 ++--
 c-user/task/operations.rst|  6 ++---
 4 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/c-user/scheduling-concepts/background.rst 
b/c-user/scheduling-concepts/background.rst
index 1fe7089..38b77ee 100644
--- a/c-user/scheduling-concepts/background.rst
+++ b/c-user/scheduling-concepts/background.rst
@@ -160,7 +160,7 @@ Manual Round-Robin
 
 The final mechanism for altering the RTEMS scheduling algorithm is called
 manual round-robin.  Manual round-robin is invoked by using
-the ``rtems_task_wake_after`` directive with a time interval of
+the ``rtems_task_wake_after`` directive with a ``ticks`` parameter of
 ``RTEMS_YIELD_PROCESSOR``.  This allows a task to give up the processor and be
 immediately returned to the ready chain at the end of its priority group.  If
 no other tasks of the same priority are ready to run, then the task does not
@@ -243,7 +243,7 @@ of the following conditions:
   option and the requested semaphore is unavailable.
 
 - The running task issues a ``rtems_task_wake_after`` directive which blocks
-  the task for the given time interval.  If the time interval specified is
+  the task for the given count of ticks.  If the count of ticks specified is
   zero, the task yields the processor and remains in the ready state.
 
 - The running task issues a ``rtems_task_wake_when`` directive which blocks the
@@ -280,8 +280,8 @@ conditions:
 - A running task issues a ``rtems_semaphore_release`` directive which releases
   the semaphore on which the blocked task is waiting.
 
-- A timeout interval expires for a task which was blocked by a call to the
-  ``rtems_task_wake_after`` directive.
+- The requested count of ticks has elapsed for a task which was blocked by a
+  call to the ``rtems_task_wake_after`` directive.
 
 - A timeout period expires for a task which blocked by a call to the
   ``rtems_task_wake_when`` directive.
diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
index c082b51..ea2337a 100644
--- a/c-user/task/directives.rst
+++ b/c-user/task/directives.rst
@@ -1475,16 +1475,16 @@ The following constraints apply to this directive:
 \clearpage
 
 .. index:: rtems_task_wake_after()
-.. index:: delay a task for an interval
-.. index:: wake up after an interval
+.. index:: delay a task for a count of clock ticks
+.. index:: wake up after a count of clock ticks
 
 .. _InterfaceRtemsTaskWakeAfter:
 
 rtems_task_wake_after()
 ---
 
-Wakes up after an interval in :term:`clock ticks ` or yields the
-processor.
+Wakes up after a count of :term:`clock ticks ` have occurred or
+yields the processor.
 
 .. rubric:: CALLING SEQUENCE:
 
@@ -1495,16 +1495,16 @@ processor.
 .. rubric:: PARAMETERS:
 
 ``ticks``
-This parameter is the interval in :term:`clock ticks ` to delay
+This parameter is the count of :term:`clock ticks ` to delay
 the task or :c:macro:`RTEMS_YIELD_PROCESSOR` to yield the processor.
 
 .. rubric:: DESCRIPTION:
 
-This directive blocks the calling task for the specified ``ticks`` of clock
-ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.  When the
-requested interval has elapsed, the task is made ready.  The clock tick
-directives automatically updates the delay period.  The calling task may give
-up the processor and remain in the ready state by specifying a value of
+This directive blocks the calling task for the specified ``ticks`` count of
+clock ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`. When
+the requested count of ticks have occurred, the task is made ready.  The clock
+tick directives automatically update the delay period.  The calling task may
+give up the processor and remain in the ready state by specifying a value of
 :c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
 
 .. rubric:: RETURN VALUES:
@@ -1516,7 +1516,12 @@ up the processor and remain in the ready state by 
specifying a value of
 
 Setting the system date and time with the :ref:`InterfaceRtemsClockSet`
 directive and similar directives which set :term:`CLOCK_REALTIME` have no
-effect on a :ref:`InterfaceRtemsTaskWakeAfter` blocked task.
+effect on a :ref:`InterfaceRtemsTaskWakeAfter` blocked task.  The delay until
+first clock tick will never be a whole clock tick interval since this directive
+will never excute exactly on a clock tick.  Applications requiring use of a
+clock (CLOCK_REALTIME or CLOCK_MONOTONIC) instead of clock ticks should make
+use of `clock_nanosleep()
+

rtems_waf Include File Detection Question

[Joel Sherrill]

Hi

I have a case for an addition to rtems-examples where I want to know if a
particular header file is installed before enabling the example. How does
one do that in rtems_waf/wscripts?

Thanks.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v3] c-user: Update references to rtems_task_wake_after

[Gedare Bloom]

This looks good to me. The only other thing worth mentioning, that is
not mentioned, is that this directive provides an "upper bound"
(maximum sleeping time) on how long a task might be non-schedulable,
whereas other sleep directives tend to provide a "lower bound"
(minimum sleeping time). At any rate, you've captured the main point.

On Wed, Jul 5, 2023 at 2:48 PM Kinsey Moore  wrote:
>
> rtems_task_wake_after takes a parameter in terms of a count of clock
> ticks and not a measure in a subunit of seconds. This updates
> documentation to reflect that. This also makes obvious the caveat about
> the first tick wait not being a whole tick and points the user at a
> replacement for better accuracy.
>
> Updates #4772
> ---
>  c-user/scheduling-concepts/background.rst |  8 +++
>  c-user/task/directives.rst| 27 ++-
>  c-user/task/introduction.rst  |  4 ++--
>  c-user/task/operations.rst|  6 ++---
>  4 files changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/c-user/scheduling-concepts/background.rst 
> b/c-user/scheduling-concepts/background.rst
> index 1fe7089..38b77ee 100644
> --- a/c-user/scheduling-concepts/background.rst
> +++ b/c-user/scheduling-concepts/background.rst
> @@ -160,7 +160,7 @@ Manual Round-Robin
>
>  The final mechanism for altering the RTEMS scheduling algorithm is called
>  manual round-robin.  Manual round-robin is invoked by using
> -the ``rtems_task_wake_after`` directive with a time interval of
> +the ``rtems_task_wake_after`` directive with a ``ticks`` parameter of
>  ``RTEMS_YIELD_PROCESSOR``.  This allows a task to give up the processor and 
> be
>  immediately returned to the ready chain at the end of its priority group.  If
>  no other tasks of the same priority are ready to run, then the task does not
> @@ -243,7 +243,7 @@ of the following conditions:
>option and the requested semaphore is unavailable.
>
>  - The running task issues a ``rtems_task_wake_after`` directive which blocks
> -  the task for the given time interval.  If the time interval specified is
> +  the task for the given count of ticks.  If the count of ticks specified is
>zero, the task yields the processor and remains in the ready state.
>
>  - The running task issues a ``rtems_task_wake_when`` directive which blocks 
> the
> @@ -280,8 +280,8 @@ conditions:
>  - A running task issues a ``rtems_semaphore_release`` directive which 
> releases
>the semaphore on which the blocked task is waiting.
>
> -- A timeout interval expires for a task which was blocked by a call to the
> -  ``rtems_task_wake_after`` directive.
> +- The requested count of ticks has elapsed for a task which was blocked by a
> +  call to the ``rtems_task_wake_after`` directive.
>
>  - A timeout period expires for a task which blocked by a call to the
>``rtems_task_wake_when`` directive.
> diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> index c082b51..ea2337a 100644
> --- a/c-user/task/directives.rst
> +++ b/c-user/task/directives.rst
> @@ -1475,16 +1475,16 @@ The following constraints apply to this directive:
>  \clearpage
>
>  .. index:: rtems_task_wake_after()
> -.. index:: delay a task for an interval
> -.. index:: wake up after an interval
> +.. index:: delay a task for a count of clock ticks
> +.. index:: wake up after a count of clock ticks
>
>  .. _InterfaceRtemsTaskWakeAfter:
>
>  rtems_task_wake_after()
>  ---
>
> -Wakes up after an interval in :term:`clock ticks ` or yields the
> -processor.
> +Wakes up after a count of :term:`clock ticks ` have occurred or
> +yields the processor.
>
>  .. rubric:: CALLING SEQUENCE:
>
> @@ -1495,16 +1495,16 @@ processor.
>  .. rubric:: PARAMETERS:
>
>  ``ticks``
> -This parameter is the interval in :term:`clock ticks ` to 
> delay
> +This parameter is the count of :term:`clock ticks ` to delay
>  the task or :c:macro:`RTEMS_YIELD_PROCESSOR` to yield the processor.
>
>  .. rubric:: DESCRIPTION:
>
> -This directive blocks the calling task for the specified ``ticks`` of clock
> -ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.  When 
> the
> -requested interval has elapsed, the task is made ready.  The clock tick
> -directives automatically updates the delay period.  The calling task may give
> -up the processor and remain in the ready state by specifying a value of
> +This directive blocks the calling task for the specified ``ticks`` count of
> +clock ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`. 
> When
> +the requested count of ticks have occurred, the task is made ready.  The 
> clock
> +tick directives automatically update the delay period.  The calling task may
> +give up the processor and remain in the ready state by specifying a value of
>  :c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
>
>  .. rubric:: RETURN VALUES:
> @@ -1516,7 +1516,12 @@ up the processor and remain in the ready state by 
> specifying a v

Re: rtems_waf Include File Detection Question

[Chris Johns]

On 6/7/2023 8:24 am, Joel Sherrill wrote:
> I have a case for an addition to rtems-examples where I want to know if a
> particular header file is installed before enabling the example. How does one 
> do
> that in rtems_waf/wscripts?

https://git.rtems.org/rtems_waf/tree/rtems_bsd.py#n65 ...

  conf.check(header_name='dlfcn.h', features='c')

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add currently best clang-format configuration to repository?

[Chris Johns]

On 6/7/2023 4:21 am, Gedare Bloom wrote:
> OK I will prepare something soon. I have my WIP version at
> https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
> 
> I think the format file itself should be just about stable. I will
> make one more test and check of it within the next few days, and then
> send the patch hopefully early next week.

How will the version of clang-format we need be handled?

Will an older version complain if our style is used with it? I am concerned I
use and trust the output however I make a mistake and use an old clang-format
that does not generate the correct format. I doubt I would spot that happening
when reviewing the output.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add currently best clang-format configuration to repository?

[Gedare Bloom]

On Wed, Jul 5, 2023 at 5:27 PM Chris Johns  wrote:
>
> On 6/7/2023 4:21 am, Gedare Bloom wrote:
> > OK I will prepare something soon. I have my WIP version at
> > https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
> >
> > I think the format file itself should be just about stable. I will
> > make one more test and check of it within the next few days, and then
> > send the patch hopefully early next week.
>
> How will the version of clang-format we need be handled?
>
> Will an older version complain if our style is used with it? I am concerned I
> use and trust the output however I make a mistake and use an old clang-format
> that does not generate the correct format. I doubt I would spot that happening
> when reviewing the output.
>
Certain (new) options in the style file will/can trigger an error that
terminates the reformatting in (older) versions of clang-format that
don't support the given option. I think we would be in that territory
with our style.

> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add currently best clang-format configuration to repository?

[Chris Johns]

On 6/7/2023 11:59 am, Gedare Bloom wrote:
> On Wed, Jul 5, 2023 at 5:27 PM Chris Johns  wrote:
>>
>> On 6/7/2023 4:21 am, Gedare Bloom wrote:
>>> OK I will prepare something soon. I have my WIP version at
>>> https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
>>>
>>> I think the format file itself should be just about stable. I will
>>> make one more test and check of it within the next few days, and then
>>> send the patch hopefully early next week.
>>
>> How will the version of clang-format we need be handled?
>>
>> Will an older version complain if our style is used with it? I am concerned I
>> use and trust the output however I make a mistake and use an old clang-format
>> that does not generate the correct format. I doubt I would spot that 
>> happening
>> when reviewing the output.
>>
> Certain (new) options in the style file will/can trigger an error that
> terminates the reformatting in (older) versions of clang-format that
> don't support the given option. I think we would be in that territory
> with our style.

Sounds good.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel