[PATCH rtems-docs] shell: Document i2c and spi commands.

[Christian Mauderer]

---
 shell/general_commands.rst | 200 +
 1 file changed, 200 insertions(+)

diff --git a/shell/general_commands.rst b/shell/general_commands.rst
index c74ae45..a6f7e18 100644
--- a/shell/general_commands.rst
+++ b/shell/general_commands.rst
@@ -44,6 +44,14 @@ The RTEMS shell has the following general commands:
 
 - rtc_ - RTC driver configuration
 
+- i2cdetect_ - detect I2C devices
+
+- i2cget_ - get data from an EEPROM like I2C device
+
+- i2cset_ - write data to an EEPROM like I2C device
+
+- spi_ - read and write simple data to an SPI bus
+
 - exit_ - alias for logoff command
 
 Commands
@@ -1179,6 +1187,198 @@ CONFIGURATION:
 
\clearpage
 
+.. _i2cdetect:
+
+i2cdetect - detect I2C devices
+--
+.. index:: i2cdetect
+
+SYNOPSYS:
+.. code-block:: shell
+
+i2cdetect 
+
+.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CDETECT
+.. index:: CONFIGURE_SHELL_COMMAND_I2CDETECT
+
+DESCRIPTION:
+Tries to detect I2C devices connected to the I2C bus. To do that, write
+requests with the length of 0 are used.
+
+WARNING: This might confuse some I2C devices, so please use it only if you
+know what you are doing.
+
+The command supports a ``-h`` option to get usage details.
+
+The command works only with I2C bus drivers that use the Linux-Style API.
+
+EXAMPLES:
+The following is an example where two I2C devices are detected. One on 0x1a
+and one on 0x1f:
+
+.. code-block:: shell
+
+SHLL [/] # i2cdetect /dev/i2c1
+x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
+0x -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+1x  -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- 1f
+2x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+3x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+4x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+5x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+6x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+7x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+SHLL [/] #
+
+CONFIGURATION:
+This command is included in the default shell command set.  When building a
+custom command set, define ``CONFIGURE_SHELL_COMMAND_I2CDETECT`` to have
+this command included.
+
+This command can be excluded from the shell command set by defining
+``CONFIGURE_SHELL_NO_COMMAND_I2CDETECT`` when all shell commands have been
+configured.
+
+.. raw:: latex
+
+   \clearpage
+
+.. _i2cget:
+
+i2cget - get data from an EEPROM like I2C device
+
+.. index:: i2cget
+
+SYNOPSYS:
+.. code-block:: shell
+
+i2cget[]
+
+.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CGET
+.. index:: CONFIGURE_SHELL_COMMAND_I2CGET
+
+DESCRIPTION:
+Get one or multiple bytes from an EEPROM like I2C device. If you read
+multiple bytes ( given and > 1) the read will be done in one
+single request. An auto incrementing register pointer is assumed.
+
+The command supports a ``-h`` option to get usage details.
+
+The command works only with I2C bus drivers that use the Linux-Style API.
+
+EXAMPLES:
+The following is an example how to read a one byte register at 0xd from the
+I2C device at 0x1f:
+
+.. code-block:: shell
+
+SHLL [/] # i2cget /dev/i2c1 0x1f 0x0d
+0xc7 
+SHLL [/] #
+
+CONFIGURATION:
+This command is included in the default shell command set.  When building a
+custom command set, define ``CONFIGURE_SHELL_COMMAND_I2CGET`` to have this
+command included.
+
+This command can be excluded from the shell command set by defining
+``CONFIGURE_SHELL_NO_COMMAND_I2CGET`` when all shell commands have been
+configured.
+
+.. raw:: latex
+
+   \clearpage
+
+.. _i2cset:
+
+i2cset - write data to an EEPROM like I2C device
+
+.. index:: i2cset
+
+SYNOPSYS:
+.. code-block:: shell
+
+i2cset [ [...]]
+
+.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CSET
+.. index:: CONFIGURE_SHELL_COMMAND_I2CSET
+
+DESCRIPTION:
+Write one or multiple bytes to an EEPROM like I2C device. If you write
+multiple bytes (multiple  given) the write will be done in one 
single
+request. An auto incrementing register pointer is assumed.
+
+The command supports a ``-h`` option to get usage details.
+
+The command works only with I2C bus drivers that use the Linux-Style API.
+
+EXAMPLES:
+The following is an example how to write one byte of 0x00 to the register 
at
+0x11 of the I2C device at 0x1f:
+
+.. code-block:: shell
+
+SHLL [/] # i2cset /dev/i2c1 0x1f 0x11 0x00
+SHLL [/] #
+
+CONFIGURATION:
+This command is included in the default shell command set.  When building a
+custom command set, define ``CONFIGURE_SHELL_COMMAND_I2CSET`` to have this
+command included.
+
+This command can be excluded from the shell command 

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Utkarsh Rai]

Hello,
Is there any update on this patch?

On Wed, Oct 28, 2020 at 7:04 PM Utkarsh Rai  wrote:

> Ping.
>
> On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai 
> wrote:
>
>> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
>> option.
>> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as
>> well as
>> for the effect on timeout delay when REALTIME clock is modified(no
>> effect).
>> The timing tests are the similar to that for the REALTIME option(yielding
>> and
>> blocking).
>>
>> Utkarsh Rai (1):
>>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
>>
>>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
>>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
>>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
>>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
>>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
>>  .../psxclocknanosleep01.doc   |  13 ++
>>  .../psxclocknanosleep01.scn   |  50 ++
>>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
>>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
>>  9 files changed, 455 insertions(+)
>>  create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml
>>  create mode 100644
>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
>>  create mode 100644
>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
>>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>>  create mode 100644
>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>>  create mode 100644
>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
>>
>> --
>> 2.25.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option

[Gedare Bloom]

I don't have time to try it out, if no one else gets back to you by early
January ping me on it. I'll have more time to look at it.

On Mon, Nov 30, 2020 at 8:40 AM Utkarsh Rai  wrote:

> Hello,
> Is there any update on this patch?
>
> On Wed, Oct 28, 2020 at 7:04 PM Utkarsh Rai 
> wrote:
>
>> Ping.
>>
>> On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai 
>> wrote:
>>
>>> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC
>>> option.
>>> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as
>>> well as
>>> for the effect on timeout delay when REALTIME clock is modified(no
>>> effect).
>>> The timing tests are the similar to that for the REALTIME
>>> option(yielding and
>>> blocking).
>>>
>>> Utkarsh Rai (1):
>>>   Test for clock_nanosleep() with CLOCK_MONOTONIC option
>>>
>>>  .../psxtests/psxclocknanosleep01.yml  |  19 +++
>>>  spec/build/testsuites/psxtmtests/grp.yml  |   4 +
>>>  .../psxtmtests/psxtmclocknanosleep04.yml  |  19 +++
>>>  .../psxtmtests/psxtmclocknanosleep05.yml  |  19 +++
>>>  .../psxtests/psxclocknanosleep01/init.c   | 145 ++
>>>  .../psxclocknanosleep01.doc   |  13 ++
>>>  .../psxclocknanosleep01.scn   |  50 ++
>>>  .../psxtmtests/psxtmclocknanosleep04/init.c   |  70 +
>>>  .../psxtmtests/psxtmclocknanosleep05/init.c   | 116 ++
>>>  9 files changed, 455 insertions(+)
>>>  create mode 100644
>>> spec/build/testsuites/psxtests/psxclocknanosleep01.yml
>>>  create mode 100644
>>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml
>>>  create mode 100644
>>> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml
>>>  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
>>>  create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
>>>  create mode 100644
>>> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn
>>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c
>>>  create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c
>>>
>>> --
>>> 2.25.1
>>>
>>> ___
> 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

Re: [PATCH rtems-docs] shell: Document i2c and spi commands.

[Gedare Bloom]

On Mon, Nov 30, 2020 at 7:14 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> ---
>  shell/general_commands.rst | 200 +
>  1 file changed, 200 insertions(+)
>
> diff --git a/shell/general_commands.rst b/shell/general_commands.rst
> index c74ae45..a6f7e18 100644
> --- a/shell/general_commands.rst
> +++ b/shell/general_commands.rst
> @@ -44,6 +44,14 @@ The RTEMS shell has the following general commands:
>
>  - rtc_ - RTC driver configuration
>
> +- i2cdetect_ - detect I2C devices
> +
> +- i2cget_ - get data from an EEPROM like I2C device
> +
> +- i2cset_ - write data to an EEPROM like I2C device
> +
> +- spi_ - read and write simple data to an SPI bus
> +
>  - exit_ - alias for logoff command
>
>  Commands
> @@ -1179,6 +1187,198 @@ CONFIGURATION:
>
> \clearpage
>
> +.. _i2cdetect:
> +
> +i2cdetect - detect I2C devices
> +--
> +.. index:: i2cdetect
> +
> +SYNOPSYS:
> +.. code-block:: shell
> +
> +i2cdetect 
> +
> +.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CDETECT
> +.. index:: CONFIGURE_SHELL_COMMAND_I2CDETECT
> +
> +DESCRIPTION:
> +Tries to detect I2C devices connected to the I2C bus. To do that,
> write
> +requests with the length of 0 are used.
> +
> +WARNING: This might confuse some I2C devices, so please use it only
> if you
> +know what you are doing.
> +
>
What happens for devices that don't know how to respond? is it any kind of
undefined behavior?


> +The command supports a ``-h`` option to get usage details.
> +
> +The command works only with I2C bus drivers that use the Linux-Style
> API.
> +
> +EXAMPLES:
> +The following is an example where two I2C devices are detected. One
> on 0x1a
> +and one on 0x1f:
> +
> +.. code-block:: shell
> +
> +SHLL [/] # i2cdetect /dev/i2c1
> +x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
> +0x -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +1x  -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- 1f
> +2x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +3x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +4x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +5x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +6x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +7x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> +SHLL [/] #
> +
> +CONFIGURATION:
> +This command is included in the default shell command set.  When
> building a
>

If this is unsafe to use when you don't know what you're doing, then maybe
it should not be available without explicitly turning it on?  (Safe
Defaults)


> +custom command set, define ``CONFIGURE_SHELL_COMMAND_I2CDETECT`` to
> have
> +this command included.
> +
> +This command can be excluded from the shell command set by defining
> +``CONFIGURE_SHELL_NO_COMMAND_I2CDETECT`` when all shell commands have
> been
> +configured.
> +
> +.. raw:: latex
> +
> +   \clearpage
> +
> +.. _i2cget:
> +
> +i2cget - get data from an EEPROM like I2C device
> +
> +.. index:: i2cget
> +
> +SYNOPSYS:
> +.. code-block:: shell
> +
> +i2cget[]
> +
> +.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CGET
> +.. index:: CONFIGURE_SHELL_COMMAND_I2CGET
> +
> +DESCRIPTION:
> +Get one or multiple bytes from an EEPROM like I2C device. If you read
> +multiple bytes ( given and > 1) the read will be done in one
>

Default is 1 byte? Please clarify


> +single request. An auto incrementing register pointer is assumed.
> +
> +The command supports a ``-h`` option to get usage details.
> +
> +The command works only with I2C bus drivers that use the Linux-Style
> API.
>

Would it make more sense to include all these under an
CONFIGURE_SHELL_COMMAND_I2CLINUX or something?

I don't use the shell though so take everything I say with a bit of
skepticism.


> +
> +EXAMPLES:
> +The following is an example how to read a one byte register at 0xd
> from the
> +I2C device at 0x1f:
> +
> +.. code-block:: shell
> +
> +SHLL [/] # i2cget /dev/i2c1 0x1f 0x0d
>

Again, my shell ignorance: do the addresses need to be specified as Hex in
0x format?


> +0xc7
> +SHLL [/] #
> +
> +CONFIGURATION:
> +This command is included in the default shell command set.  When
> building a
> +custom command set, define ``CONFIGURE_SHELL_COMMAND_I2CGET`` to have
> this
> +command included.
> +
> +This command can be excluded from the shell command set by defining
> +``CONFIGURE_SHELL_NO_COMMAND_I2CGET`` when all shell commands have
> been
> +configured.
> +
> +.. raw:: latex
> +
> +   \clearpage
> +
> +.. _i2cset:
> +
> +i2cset - write data to an EEPROM like I2C device
> +
> +.. index:: i2cset
> +
> +SYNOPSYS:
> +.. code-block:: shell
> +
> +i2cset [
> [...]]

Re: [PATCH] sapi: Remove obsolete README file

[Gedare Bloom]

ok with me.

On Thu, Nov 26, 2020 at 3:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  cpukit/sapi/include/rtems/README | 129 ---
>  1 file changed, 129 deletions(-)
>  delete mode 100644 cpukit/sapi/include/rtems/README
>
> diff --git a/cpukit/sapi/include/rtems/README
> b/cpukit/sapi/include/rtems/README
> deleted file mode 100644
> index 1b6dd77619..00
> --- a/cpukit/sapi/include/rtems/README
> +++ /dev/null
> @@ -1,129 +0,0 @@
> -Configuring a System Using the Template in confdefs.h
> -=
> -
> -The file confdefs.h is a Configuration Template file which can be
> -used to greatly simplify the creation and maintenance of RTEMS
> -Configuration Tables.  The basic concepts are:
> -
> -   + confdefs.h provides defaults for all configuration parameters
> -
> -   + applications specify only those values they wish to override
> -
> -   + confdefs.h can be the only file which knows the precise layout
> - of the RTEMS Configuration Tables.
> -
> -The Configuration Template setup is used by all RTEMS tests to
> -simplify the maintenance of the tests.
> -
> -Here is the section from the system.h file from test tm21 from
> -the Timing Test Suite:
> -
> -   /* configuration information */
> -
> -   #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> -   #define CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER
> -
> -   #define CONFIGURE_MAXIMUM_TASKS  102
> -   #define CONFIGURE_MAXIMUM_TIMERS 100
> -   #define CONFIGURE_MAXIMUM_SEMAPHORES 100
> -   #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 100
> -   #define CONFIGURE_MAXIMUM_PARTITIONS 100
> -   #define CONFIGURE_MAXIMUM_REGIONS100
> -   #define CONFIGURE_MAXIMUM_PORTS  100
> -   #define CONFIGURE_MAXIMUM_PERIODS100
> -
> -   #define CONFIGURE_TICKS_PER_TIMESLICE0
> -
> -   #include 
> -
> -
> -The above example overrides a number of the configuration parameters.
> -It informs the template that it is a member of the Timing Suite,
> -requires a console and timer driver, and that it needs 102 tasks,
> -100 timers, 100 semaphores, 100 message queues, 100 partitions,
> -100 regions, 100 ports, and 100 periods.   By default, the test
> -would have gotten no drivers, 10 tasks, and no other RTEMS objects.
> -
> -The following shows the configuration tables generated by the
> -template by default.
> -
> -
> -#include 
> -
> -#define NULL_DRIVER_TABLE_ENTRY \
> - { NULL, NULL, NULL, NULL, NULL, NULL }
> -
> -rtems_driver_address_table Device_drivers[] = {
> -#ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> -  CONSOLE_DRIVER_TABLE_ENTRY,
> -#endif
> -#ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> -  CLOCK_DRIVER_TABLE_ENTRY,
> -#endif
> -#ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
> -  STUB_DRIVER_TABLE_ENTRY,
> -#endif
> -  NULL_DRIVER_TABLE_ENTRY,
> -};
> -
> -rtems_initialization_tasks_table Initialization_tasks[] = {
> -  { rtems_build_name( 'U', 'I', '1', ' ' ), /* init task name */
> -RTEMS_MINIMUM_STACK_SIZE,   /* init task stack size */
> -1,  /* init task priority */
> -RTEMS_DEFAULT_ATTRIBUTES,   /* init task attributes */
> -Init,   /* init task entry point */
> -RTEMS_NO_PREEMPT,   /* init task initial mode */
> -0   /* init task argument list */
> -  }
> -};
> -
> -#ifdef CONFIGURE_MP_APPLICATION
> -/*
> - *  NODE_NUMBER is assumed to be set on the compile line.
> - */
> -
> -rtems_multiprocessing_table Multiprocessing_configuration = {
> -  NODE_NUMBER,   /* local node number */
> -  2, /* maximum # nodes in system */
> -  32,/* maximum # global objects */
> -  32,/* maximum # proxies */
> -  &MPCI_table/* pointer to MPCI config table
> */
> -};
> -#endif
> -
> -/*
> - *  CONFIGURE_EXECUTIVE_RAM_SIZE is a rough guess based on the number of
> - *  tasks in the system plus enough extra to get a whole 64K extra.
> - *
> - *  The NULL address for the workspace area is assumed to be assigned
> - *  at startup time by the BSP.
> - */
> -
> -rtems_configuration_table Configuration = {
> -  NULL,  /* executive RAM work area */
> -  CONFIGURE_EXECUTIVE_RAM_SIZE, /* executive RAM size */
> -  10,/* maximum # tasks */
> -  0, /* maximum # timers */
> -  0, /* maximum # semaphores */
> -  0, /* maximum # message queues */
> -  0, /* maximum # messages */
> -  0, /* maximum # partitions */
> -  0, /* maximum # regions */
> -  0, /* max

Re: [PATCH] sapi: Remove obsolete README file

[Gedare Bloom]

I see it already went through ;)

On Mon, Nov 30, 2020 at 10:51 AM Gedare Bloom  wrote:

> ok with me.
>
> On Thu, Nov 26, 2020 at 3:29 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> ---
>>  cpukit/sapi/include/rtems/README | 129 ---
>>  1 file changed, 129 deletions(-)
>>  delete mode 100644 cpukit/sapi/include/rtems/README
>>
>> diff --git a/cpukit/sapi/include/rtems/README
>> b/cpukit/sapi/include/rtems/README
>> deleted file mode 100644
>> index 1b6dd77619..00
>> --- a/cpukit/sapi/include/rtems/README
>> +++ /dev/null
>> @@ -1,129 +0,0 @@
>> -Configuring a System Using the Template in confdefs.h
>> -=
>> -
>> -The file confdefs.h is a Configuration Template file which can be
>> -used to greatly simplify the creation and maintenance of RTEMS
>> -Configuration Tables.  The basic concepts are:
>> -
>> -   + confdefs.h provides defaults for all configuration parameters
>> -
>> -   + applications specify only those values they wish to override
>> -
>> -   + confdefs.h can be the only file which knows the precise layout
>> - of the RTEMS Configuration Tables.
>> -
>> -The Configuration Template setup is used by all RTEMS tests to
>> -simplify the maintenance of the tests.
>> -
>> -Here is the section from the system.h file from test tm21 from
>> -the Timing Test Suite:
>> -
>> -   /* configuration information */
>> -
>> -   #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>> -   #define CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER
>> -
>> -   #define CONFIGURE_MAXIMUM_TASKS  102
>> -   #define CONFIGURE_MAXIMUM_TIMERS 100
>> -   #define CONFIGURE_MAXIMUM_SEMAPHORES 100
>> -   #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 100
>> -   #define CONFIGURE_MAXIMUM_PARTITIONS 100
>> -   #define CONFIGURE_MAXIMUM_REGIONS100
>> -   #define CONFIGURE_MAXIMUM_PORTS  100
>> -   #define CONFIGURE_MAXIMUM_PERIODS100
>> -
>> -   #define CONFIGURE_TICKS_PER_TIMESLICE0
>> -
>> -   #include 
>> -
>> -
>> -The above example overrides a number of the configuration parameters.
>> -It informs the template that it is a member of the Timing Suite,
>> -requires a console and timer driver, and that it needs 102 tasks,
>> -100 timers, 100 semaphores, 100 message queues, 100 partitions,
>> -100 regions, 100 ports, and 100 periods.   By default, the test
>> -would have gotten no drivers, 10 tasks, and no other RTEMS objects.
>> -
>> -The following shows the configuration tables generated by the
>> -template by default.
>> -
>> -
>> -#include 
>> -
>> -#define NULL_DRIVER_TABLE_ENTRY \
>> - { NULL, NULL, NULL, NULL, NULL, NULL }
>> -
>> -rtems_driver_address_table Device_drivers[] = {
>> -#ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>> -  CONSOLE_DRIVER_TABLE_ENTRY,
>> -#endif
>> -#ifdef CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>> -  CLOCK_DRIVER_TABLE_ENTRY,
>> -#endif
>> -#ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
>> -  STUB_DRIVER_TABLE_ENTRY,
>> -#endif
>> -  NULL_DRIVER_TABLE_ENTRY,
>> -};
>> -
>> -rtems_initialization_tasks_table Initialization_tasks[] = {
>> -  { rtems_build_name( 'U', 'I', '1', ' ' ), /* init task name */
>> -RTEMS_MINIMUM_STACK_SIZE,   /* init task stack size */
>> -1,  /* init task priority */
>> -RTEMS_DEFAULT_ATTRIBUTES,   /* init task attributes */
>> -Init,   /* init task entry point */
>> -RTEMS_NO_PREEMPT,   /* init task initial mode */
>> -0   /* init task argument list */
>> -  }
>> -};
>> -
>> -#ifdef CONFIGURE_MP_APPLICATION
>> -/*
>> - *  NODE_NUMBER is assumed to be set on the compile line.
>> - */
>> -
>> -rtems_multiprocessing_table Multiprocessing_configuration = {
>> -  NODE_NUMBER,   /* local node number */
>> -  2, /* maximum # nodes in system */
>> -  32,/* maximum # global objects */
>> -  32,/* maximum # proxies */
>> -  &MPCI_table/* pointer to MPCI config table
>> */
>> -};
>> -#endif
>> -
>> -/*
>> - *  CONFIGURE_EXECUTIVE_RAM_SIZE is a rough guess based on the number of
>> - *  tasks in the system plus enough extra to get a whole 64K extra.
>> - *
>> - *  The NULL address for the workspace area is assumed to be assigned
>> - *  at startup time by the BSP.
>> - */
>> -
>> -rtems_configuration_table Configuration = {
>> -  NULL,  /* executive RAM work area */
>> -  CONFIGURE_EXECUTIVE_RAM_SIZE, /* executive RAM size */
>> -  10,/* maximum # tasks */
>> -  0, /* maximum # timers */
>> -  0, /* maximum # semaphores */
>> -  0, /* maximum # message qu

rtems waf, examples, and RTEMS_POSIX_API

[Joel Sherrill]

Hi

With more POSIX enabled by default, the RTEMS_POSIX_API flag has changed
meanings and this has broken the meaning of checking for POSIX in
rtems_waf. The rtems-examples use code like this which now turns off all
POSIX examples because POSIX signals are disabled.

if rtems.check_posix(bld):
bld.recurse('posix_hello_world')
bld.recurse('both_hello')


I suspect rtems_check_posix() should always return true now and another
method named rtems_check_posix_signals() should be added based on the flag.

Similarly, RTEMS_POSIX_API should probably always be set and another macro
provided for POSIX signals.

The meaning changed without considering the impact. We need to account for
this.

I think this was also present in 5 but I am not sure how to deal with it
there. My proposed change may be too much for the feature macro.

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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

Hello Joel,

On 30/11/2020 19:40, Joel Sherrill wrote:

    if rtems.check_posix(bld):
        bld.recurse('posix_hello_world')
        bld.recurse('both_hello')

if these examples don't use signals, I would just remove the check.



I suspect rtems_check_posix() should always return true now and 
another method named rtems_check_posix_signals() should be added based 
on the flag.


Similarly, RTEMS_POSIX_API should probably always be set and another 
macro provided for POSIX signals.


The meaning changed without considering the impact. We need to account 
for this.


If RTEMS_POSIX_API is defined, then all POSIX APIs supported by RTEMS 
are enabled. If you always define it, then this is no longer true.


Applications can use something like:

#if __RTEMS_MAJOR__ >= 5

POSIX threads are always enabled ...

#endif

I don't think we need new or changed defines.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Joel Sherrill]

On Mon, Nov 30, 2020, 12:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 30/11/2020 19:40, Joel Sherrill wrote:
> > if rtems.check_posix(bld):
> > bld.recurse('posix_hello_world')
> > bld.recurse('both_hello')
> if these examples don't use signals, I would just remove the check.
> >
> >
> > I suspect rtems_check_posix() should always return true now and
> > another method named rtems_check_posix_signals() should be added based
> > on the flag.
> >
> > Similarly, RTEMS_POSIX_API should probably always be set and another
> > macro provided for POSIX signals.
> >
> > The meaning changed without considering the impact. We need to account
> > for this.
>
> If RTEMS_POSIX_API is defined, then all POSIX APIs supported by RTEMS
> are enabled. If you always define it, then this is no longer true.
>

It is now not defined. It's meaning has been perverted a sinus confusing.



> Applications can use something like:
>
> #if __RTEMS_MAJOR__ >= 5
>
> POSIX threads are always enabled ...
>
> #endif
>

This is a change to our public API that was completely unnecessary.

We do not require changes to application code when it can be avoided.


> I don't think we need new or changed define


> I disagree


>
>
>
>
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

On 30/11/2020 20:00, Joel Sherrill wrote:


> Similarly, RTEMS_POSIX_API should probably always be set and
another
> macro provided for POSIX signals.
>
> The meaning changed without considering the impact. We need to
account
> for this.

If RTEMS_POSIX_API is defined, then all POSIX APIs supported by RTEMS
are enabled. If you always define it, then this is no longer true.


It is now not defined. It's meaning has been perverted a sinus confusing.
If you use --enable-posix it is defined. Also if you use 
"RTEMS_POSIX_API = True" in the config.ini of the new build system it is 
defined.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

On 30/11/2020 20:00, Joel Sherrill wrote:


Applications can use something like:

#if __RTEMS_MAJOR__ >= 5

POSIX threads are always enabled ...

#endif


This is a change to our public API that was completely unnecessary.

We do not require changes to application code when it can be avoided.
If you enable the POSIX API, then you don't have to change anything in 
your application. You can use now more of the POSIX API without having 
to enable it explicitly. It is up to you if you want to rely on this or not.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

Re: [PATCH rtems-docs] shell: Document i2c and spi commands.

[Christian Mauderer]

Hello Gedare,

thanks for the review.

On 30/11/2020 18:43, Gedare Bloom wrote:



On Mon, Nov 30, 2020 at 7:14 AM Christian Mauderer 
> wrote:


---
  shell/general_commands.rst | 200 +
  1 file changed, 200 insertions(+)

diff --git a/shell/general_commands.rst b/shell/general_commands.rst
index c74ae45..a6f7e18 100644
--- a/shell/general_commands.rst
+++ b/shell/general_commands.rst
@@ -44,6 +44,14 @@ The RTEMS shell has the following general commands:

  - rtc_ - RTC driver configuration

+- i2cdetect_ - detect I2C devices
+
+- i2cget_ - get data from an EEPROM like I2C device
+
+- i2cset_ - write data to an EEPROM like I2C device
+
+- spi_ - read and write simple data to an SPI bus
+
  - exit_ - alias for logoff command

  Commands
@@ -1179,6 +1187,198 @@ CONFIGURATION:

     \clearpage

+.. _i2cdetect:
+
+i2cdetect - detect I2C devices
+--
+.. index:: i2cdetect
+
+SYNOPSYS:
+    .. code-block:: shell
+
+        i2cdetect 
+
+.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CDETECT
+.. index:: CONFIGURE_SHELL_COMMAND_I2CDETECT
+
+DESCRIPTION:
+    Tries to detect I2C devices connected to the I2C bus. To do
that, write
+    requests with the length of 0 are used.
+
+    WARNING: This might confuse some I2C devices, so please use it
only if you
+    know what you are doing.
+

What happens for devices that don't know how to respond? is it any kind 
of undefined behavior?


That depends on the devices. Basically everything can happen. For example:

- device is just not detected
- I2C bus hangs
- some random undefined behavior

The command uses the same method that is used by the Linux i2cdetect 
command and therefore I added a similar warning:


   https://linux.die.net/man/8/i2cdetect



+    The command supports a ``-h`` option to get usage details.
+
+    The command works only with I2C bus drivers that use the
Linux-Style API.
+
+EXAMPLES:
+    The following is an example where two I2C devices are detected.
One on 0x1a
+    and one on 0x1f:
+
+    .. code-block:: shell
+
+        SHLL [/] # i2cdetect /dev/i2c1
+            x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
+        0x     -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        1x  -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- 1f
+        2x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        3x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        4x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        5x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        6x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        7x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+        SHLL [/] #
+
+CONFIGURATION:
+    This command is included in the default shell command set. 
When building a


If this is unsafe to use when you don't know what you're doing, then 
maybe it should not be available without explicitly turning it on?  
(Safe Defaults)


I can do that if you want. It's more or less a diagnostic command (just 
like the others here). But note that we have a lot of "unsafe if you 
don't know what you are doing" commands. Like dd, mkrfs, mmove, fdisk, 
and even exit can crash some systems ...


Aren't nearly all shell commands at least a bit unsafe? And we don't 
have a lot of commands that have to be explicitly turned on if 
CONFIGURE_SHELL_COMMANDS_ALL is already set. I found only networking 
commands.




+    custom command set, define
``CONFIGURE_SHELL_COMMAND_I2CDETECT`` to have
+    this command included.
+
+    This command can be excluded from the shell command set by defining
+    ``CONFIGURE_SHELL_NO_COMMAND_I2CDETECT`` when all shell
commands have been
+    configured.
+
+.. raw:: latex
+
+   \clearpage
+
+.. _i2cget:
+
+i2cget - get data from an EEPROM like I2C device
+
+.. index:: i2cget
+
+SYNOPSYS:
+    .. code-block:: shell
+
+        i2cget[]
+
+.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CGET
+.. index:: CONFIGURE_SHELL_COMMAND_I2CGET
+
+DESCRIPTION:
+    Get one or multiple bytes from an EEPROM like I2C device. If
you read
+    multiple bytes ( given and > 1) the read will be done
in one


Default is 1 byte? Please clarify


OK.



+    single request. An auto incrementing register pointer is assumed.
+
+    The command supports a ``-h`` option to get usage details.
+
+    The command works only with I2C bus drivers that use the
Linux-Style API.


Would it make more sense to include all these under an 
CONFIGURE_SHELL_COMMAND_

Re: rtems waf, examples, and RTEMS_POSIX_API

[Joel Sherrill]

On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/11/2020 20:00, Joel Sherrill wrote:
>
> > Applications can use something like:
> >
> > #if __RTEMS_MAJOR__ >= 5
> >
> > POSIX threads are always enabled ...
> >
> > #endif
> >
> >
> > This is a change to our public API that was completely unnecessary.
> >
> > We do not require changes to application code when it can be avoided.
> If you enable the POSIX API, then you don't have to change anything in
> your application. You can use now more of the POSIX API without having
> to enable it explicitly. It is up to you if you want to rely on this or
> not.
>

What about rtems-libbsd? It fails to build because of this flag having
changed
meaning.

I think we broke a contract on what the meaning of a published
feature macro means.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@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

Re: [PATCH rtems-docs] shell: Document i2c and spi commands.

[Gedare Bloom]

On Mon, Nov 30, 2020 at 12:14 PM Christian Mauderer 
wrote:

> Hello Gedare,
>
> thanks for the review.
>
> On 30/11/2020 18:43, Gedare Bloom wrote:
> >
> >
> > On Mon, Nov 30, 2020 at 7:14 AM Christian Mauderer
> >  > > wrote:
> >
> > ---
> >   shell/general_commands.rst | 200
> +
> >   1 file changed, 200 insertions(+)
> >
> > diff --git a/shell/general_commands.rst b/shell/general_commands.rst
> > index c74ae45..a6f7e18 100644
> > --- a/shell/general_commands.rst
> > +++ b/shell/general_commands.rst
> > @@ -44,6 +44,14 @@ The RTEMS shell has the following general
> commands:
> >
> >   - rtc_ - RTC driver configuration
> >
> > +- i2cdetect_ - detect I2C devices
> > +
> > +- i2cget_ - get data from an EEPROM like I2C device
> > +
> > +- i2cset_ - write data to an EEPROM like I2C device
> > +
> > +- spi_ - read and write simple data to an SPI bus
> > +
> >   - exit_ - alias for logoff command
> >
> >   Commands
> > @@ -1179,6 +1187,198 @@ CONFIGURATION:
> >
> >  \clearpage
> >
> > +.. _i2cdetect:
> > +
> > +i2cdetect - detect I2C devices
> > +--
> > +.. index:: i2cdetect
> > +
> > +SYNOPSYS:
> > +.. code-block:: shell
> > +
> > +i2cdetect 
> > +
> > +.. index:: CONFIGURE_SHELL_NO_COMMAND_I2CDETECT
> > +.. index:: CONFIGURE_SHELL_COMMAND_I2CDETECT
> > +
> > +DESCRIPTION:
> > +Tries to detect I2C devices connected to the I2C bus. To do
> > that, write
> > +requests with the length of 0 are used.
> > +
> > +WARNING: This might confuse some I2C devices, so please use it
> > only if you
> > +know what you are doing.
> > +
> >
> > What happens for devices that don't know how to respond? is it any kind
> > of undefined behavior?
>
> That depends on the devices. Basically everything can happen. For example:
>
> - device is just not detected
> - I2C bus hangs
> - some random undefined behavior
>
> The command uses the same method that is used by the Linux i2cdetect
> command and therefore I added a similar warning:
>
> https://linux.die.net/man/8/i2cdetect
>
> >
> > +The command supports a ``-h`` option to get usage details.
> > +
> > +The command works only with I2C bus drivers that use the
> > Linux-Style API.
> > +
> > +EXAMPLES:
> > +The following is an example where two I2C devices are detected.
> > One on 0x1a
> > +and one on 0x1f:
> > +
> > +.. code-block:: shell
> > +
> > +SHLL [/] # i2cdetect /dev/i2c1
> > +x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
> > +0x -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +1x  -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- 1f
> > +2x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +3x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +4x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +5x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +6x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +7x  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > +SHLL [/] #
> > +
> > +CONFIGURATION:
> > +This command is included in the default shell command set.
> > When building a
> >
> > If this is unsafe to use when you don't know what you're doing, then
> > maybe it should not be available without explicitly turning it on?
> > (Safe Defaults)
>
> I can do that if you want. It's more or less a diagnostic command (just
> like the others here). But note that we have a lot of "unsafe if you
> don't know what you are doing" commands. Like dd, mkrfs, mmove, fdisk,
> and even exit can crash some systems ...
>
> Aren't nearly all shell commands at least a bit unsafe? And we don't
> have a lot of commands that have to be explicitly turned on if
> CONFIGURE_SHELL_COMMANDS_ALL is already set. I found only networking
> commands.
>
> That seems accurate, you can go ahead with the approach you took then. It
seems to be mostly consistent with the state of practice.


> >
> > +custom command set, define
> > ``CONFIGURE_SHELL_COMMAND_I2CDETECT`` to have
> > +this command included.
> > +
> > +This command can be excluded from the shell command set by
> defining
> > +``CONFIGURE_SHELL_NO_COMMAND_I2CDETECT`` when all shell
> > commands have been
> > +configured.
> > +
> > +.. raw:: latex
> > +
> > +   \clearpage
> > +
> > +.. _i2cget:
> > +
> > +i2cget - get data from an EEPROM like I2C device
> > +
> > +.. index:: i2cget
> > +
> > +SYNOPSYS:
> > +.. code-block:: shell
> > +
> > +  

qemu5 and zynq console input

[Joel Sherrill]

Hi

Does this combination work for anyone? I am suspicious that this broke with
the qemu version bump in the RSB.

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

Re: qemu5 and zynq console input

[Chris Johns]

On 1/12/20 10:25 am, Joel Sherrill wrote:
> Does this combination work for anyone? I am suspicious that this broke with 
> the
> qemu version bump in the RSB.

I did not test input. The tester does not have the ability to test input.

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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

On 30/11/2020 21:43, Joel Sherrill wrote:




On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber 
> wrote:


On 30/11/2020 20:00, Joel Sherrill wrote:

>     Applications can use something like:
>
>     #if __RTEMS_MAJOR__ >= 5
>
>     POSIX threads are always enabled ...
>
>     #endif
>
>
> This is a change to our public API that was completely unnecessary.
>
> We do not require changes to application code when it can be
avoided.
If you enable the POSIX API, then you don't have to change
anything in
your application. You can use now more of the POSIX API without
having
to enable it explicitly. It is up to you if you want to rely on
this or not.


What about rtems-libbsd? It fails to build because of this flag having 
changed

meaning.

I think we broke a contract on what the meaning of a published
feature macro means.


Sorry, I still don't understand the problem. You always had to build 
libbsd with a BSP which was configured with --enable-posix.


Since now more POSIX APIs are enabled by default, we may remove this 
check from libbsd. However, this requires someone with enough time to 
implement and test this.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

Re: qemu5 and zynq console input

[Sebastian Huber]

On 01/12/2020 00:25, Joel Sherrill wrote:



Does this combination work for anyone? I am suspicious that this broke 
with the qemu version bump in the RSB.
I built Qemu using the master branch last week and also had the problem 
that the console input didn't work.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Chris Johns]

On 1/12/20 5:31 pm, Sebastian Huber wrote:
> On 30/11/2020 21:43, Joel Sherrill wrote:
>> On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber
>> > > wrote:
>>     On 30/11/2020 20:00, Joel Sherrill wrote:
>>     >     Applications can use something like:
>>     >
>>     >     #if __RTEMS_MAJOR__ >= 5
>>     >
>>     >     POSIX threads are always enabled ...
>>     >
>>     >     #endif
>>     >
>>     > This is a change to our public API that was completely unnecessary.
>>     >
>>     > We do not require changes to application code when it can be
>>     avoided.
>>     If you enable the POSIX API, then you don't have to change
>>     anything in
>>     your application. You can use now more of the POSIX API without
>>     having
>>     to enable it explicitly. It is up to you if you want to rely on
>>     this or not.
>>
>>
>> What about rtems-libbsd? It fails to build because of this flag having 
>> changed
>> meaning.
>>
>> I think we broke a contract on what the meaning of a published
>> feature macro means.
> 
> Sorry, I still don't understand the problem. You always had to build libbsd 
> with
> a BSP which was configured with --enable-posix.
> 
> Since now more POSIX APIs are enabled by default, we may remove this check 
> from
> libbsd. However, this requires someone with enough time to implement and test 
> this.

The semantics of what is being offered by the option has changed. Yes adding the
option does make things build but it is now inconsistent in what it covers and
how it is being detected and used. Papering over this only delays the point in
time we need to address it

Can the enable-posix option be removed and always enabled? We minimise the
executable size automatically. Always being enabled means the option in the
header is always true and any dependent package or build system can happily
continue and be updated when it suites.

Failing that can the default always be true?

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

Re: rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

On 01/12/2020 07:49, Chris Johns wrote:


On 1/12/20 5:31 pm, Sebastian Huber wrote:

On 30/11/2020 21:43, Joel Sherrill wrote:

On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:
     On 30/11/2020 20:00, Joel Sherrill wrote:
     >     Applications can use something like:
     >
     >     #if __RTEMS_MAJOR__ >= 5
     >
     >     POSIX threads are always enabled ...
     >
     >     #endif
     >
     > This is a change to our public API that was completely unnecessary.
     >
     > We do not require changes to application code when it can be
     avoided.
     If you enable the POSIX API, then you don't have to change
     anything in
     your application. You can use now more of the POSIX API without
     having
     to enable it explicitly. It is up to you if you want to rely on
     this or not.


What about rtems-libbsd? It fails to build because of this flag having changed
meaning.

I think we broke a contract on what the meaning of a published
feature macro means.

Sorry, I still don't understand the problem. You always had to build libbsd with
a BSP which was configured with --enable-posix.

Since now more POSIX APIs are enabled by default, we may remove this check from
libbsd. However, this requires someone with enough time to implement and test 
this.

The semantics of what is being offered by the option has changed. Yes adding the
option does make things build but it is now inconsistent in what it covers and
how it is being detected and used. Papering over this only delays the point in
time we need to address it


What is offered by default changed. What didn't change is the meaning of 
RTEMS_POSIX_API define. What you want to do now is making use of the 
additional POSIX features enabled by default in RTEMS 5 and later. This 
is the problem we have to address. I suggested to use the 
__RTEMS_MAJOR__ to figure out what is enabled by default.




Can the enable-posix option be removed and always enabled? We minimise the
executable size automatically. Always being enabled means the option in the
header is always true and any dependent package or build system can happily
continue and be updated when it suites.
I didn't remove the RTEMS_POSIX_API completely, since the signals have 
an impact on the size of the Thread_Control and may pull in some extra 
code which is probably very seldom used (e.g. the sporadic server 
stuff). I tried hard to make sure that the additional POSIX features 
enabled now by default don't add an overhead to applications which don't 
use them. An increased Thread_Control size affects all applications.


Failing that can the default always be true?
Yes, this would be an option, but if we do this, then we make a change 
which impacts existing application configurations.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@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