[rtems-docs 5.x] eng/vc-users.rst: Add commit message guidance

[Joel Sherrill]

Closes #4275.
---
 eng/vc-users.rst | 77 +++-
 1 file changed, 71 insertions(+), 6 deletions(-)

diff --git a/eng/vc-users.rst b/eng/vc-users.rst
index 31de516..5d2dfb4 100644
--- a/eng/vc-users.rst
+++ b/eng/vc-users.rst
@@ -422,20 +422,85 @@ then you rewrite those commits with ``git rebase`` and 
push them up again, the
 others will have to re-merge their work and trying to integrate their work
 into yours can become messy.
 
-Accessing a developer's repository
+Accessing a Developer's Repository
 --
 
 RTEMS developers with Git commit access have personal repositories
 on https://git.rtems.org/ that can be cloned to view cutting-edge
 development work shared there.
 
+Commit Message Guidance
+---
+
+The commit message associated with a change to any software project
+is of critical importance. It is the explanation of the change and the
+rationale for it. Future users looing back through the project history
+will rely on it. Even the author of the change will likely rely on it
+once they have forgotten the details of the change. It is important to
+make the message useful. Here are some guidelines followed by the RTEMS
+Project to help improve the quality of our commit messages.
+
+* When committing a change the first line is a summary. Please make it short
+  while hinting at the nature of the change. You can discuses the change
+  if you wish in a ticket that has a PR number which can be referenced in
+  the commit message. After the first line, leave an empty line and add
+  whatever required details you feel are needed.
+
+* Format the commit message so it is readable and clear. If you have
+  specific points related to the change make them with separate paragraphs
+  and if you wish you can optionally uses a `-` marker with suitable
+  indents and alignment to aid readability.
+
+* Limit the line length to less than 80 characters
+
+* Please use a real name with a valid email address. Please do not use
+  pseudonyms or provide anonymous contributions. 
+
+* Please do not use terms such as "Fix bug", "With this change it
+  works", or "Bump hash". If you fix a bug please state the nature of the
+  bug and why this change fixes it. If a change makes something work then
+  detail the reason. You do not need to explain the change line by line
+  as the commits diff and associated ticket will.
+
+* If you change the formatting of source code in a repository please
+  make that a separate patch and use "Formatting changes only" on the first
+  line. Please indicate the reason or process. For example to "Conforming
+  to code standing", "Reverting to upstream format", "Result of automatic
+  formatting".
+
+* Similarly, if addressing a spelling, grammar, or Doxygen issue, please
+  put that in a commit by itself separate from technical changes.
+
+An example commit message:
+
+.. code-block:: shell
+
+  test/change: Test message on formatting of commits
+
+  - Shows a simple single first line
+
+  - Has an empty second line
+
+  - Shows the specifics of adding separate points in the commit message as
+separate paragraphs. It also shows a `-` separator and multilines
+that are less than the 80 character width
+
+  - Show a ticket update and close
+
+  Updates #9876
+  Closes #8765
+
+The first line generally starts with a file or directory name which
+indicates the area in RTEMS to which the commit applies. For a patch
+series which impacts multiple BSPs, it is common to put each BSP into
+a separate patch. This improves the quality and specificity of the
+commit messages.
+
 Creating a Patch
-
+-
 
-Before submitting a patch read about `Contributing
-`_ to RTEMS and the
-`Commit Message `_
-formatting we require.
+Before submitting a patch, please read `Commit Message Guidance`_ to
+become familiar with the commit message formatting we require.
 
 The recommended way to create a patch is to branch the Git repository master
 and use one commit for each logical change. Then you can use
-- 
1.8.3.1

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

Re: [PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.

[Gedare Bloom]

How does this debugging get turned on/off?


On Sat, Dec 3, 2022 at 2:00 AM Prashanth S  wrote:
>
> ---
>  cpukit/include/dev/can/can.h | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
> index 9e55395039..4ee51ebc9d 100644
> --- a/cpukit/include/dev/can/can.h
> +++ b/cpukit/include/dev/can/can.h
> @@ -53,13 +53,28 @@
>printf(str, ##__VA_ARGS__);
>  \
>  } while (false);
>
> +#ifdef RTEMS_CAN_DEBUG
> +
>  #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__)
> +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */
> +
> +#else /* RTEMS_CAN_DEBUG */
> +
> +#define CAN_DEBUG(str, ...)
> +#define CAN_DEBUG_BUF(str, ...)
> +#define CAN_DEBUG_ISR(str, ...)
> +#define CAN_DEBUG_LOCK(str, ...)
> +#define CAN_DEBUG_RX(str, ...)
> +#define CAN_DEBUG_TX(str, ...)
> +#define CAN_DEBUG_REG(str, ...)
> +
> +#endif /* RTEMS_CAN_DEBUG */
> +
>  #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__)
>
maybe use CAN_ERROR? unless there's a reason not to.

>  #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg 
> *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg))
> --
> 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 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks

[Gedare Bloom]

On Sat, Dec 3, 2022 at 2:02 AM Prashanth S  wrote:
>
> The CAN framework has minimal Rx implementation, so to test loopback
> driver the test application is modified to write and read atomically
> ---
>  testsuites/libtests/can01/init.c | 71 ++--
>  1 file changed, 31 insertions(+), 40 deletions(-)
>
> diff --git a/testsuites/libtests/can01/init.c 
> b/testsuites/libtests/can01/init.c
> index 0675fe606f..f70e68fb51 100644
> --- a/testsuites/libtests/can01/init.c
> +++ b/testsuites/libtests/can01/init.c
> @@ -48,7 +48,7 @@
> if (c3 == '9') { \
>   if (c2 == 'z') {   \
> if (c1 == 'z') { \
> - printf("not enough task letters for names !!!\n"); \
> + CAN_ERR("not enough task letters for names !!!\n"); 
> \

I don't think the print statements need to be macro'd in your test, so
long as they only get printed when the test fails. When it's passing,
then we would prefer it be quiet.

>   exit( 1 ); \
> } else   \
>   c1++;  \
> @@ -63,6 +63,10 @@
>   else   \
> c4++ \
>
> +struct test_thread {
> +  rtems_mutex mutex;
> +};
> +
>  static void test_task(rtems_task_argument);
>  int can_loopback_init(const char *);
>  int create_task(int);
> @@ -70,60 +74,54 @@ int create_task(int);
>  static rtems_id task_id[TASKS];
>  static rtems_id task_test_status[TASKS] = {[0 ... (TASKS - 1)] = false};
>
> +static struct test_thread thread;
> +
>  const char rtems_test_name[] = "CAN test TX, RX with CAN loopback driver";
>
> -/*FIXME: Should Implement one more test application for the
> - * RTR support
> - *
> - * For testing, the number of successful read and write
> - * count is verified.
> - */
>  static void test_task(rtems_task_argument data)
>  {
> -  //sleep so that other tasks will be created.
>sleep(1);
>
>int fd, task_num = (uint32_t)data;
>uint32_t count = 0, msg_size;
>
> -  struct can_msg msg;
> +  struct can_msg send_msg, recv_msg;
>
>printf("CAN tx and rx for %s\n", CAN_DEV_FILE);
>
>fd = open(CAN_DEV_FILE, O_RDWR);
>if (fd < 0) {
> -printf("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE, 
> strerror(errno));
> +CAN_ERR("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE, 
> strerror(errno));
>}
>
>rtems_test_assert(fd >= 0);
>
>for (int i = 0; i < NUM_TEST_MSGS; i++) {
> -printf("test_task %u\n", task_num);
> -
> -msg.id = task_num;
> -//FIXME: Implement Test cases for other flags also.
> -msg.flags = 0;
> -msg.len = (i + 1) % 9;
> +send_msg.id = task_num;
> +send_msg.flags = 0;
> +send_msg.len = (i + 1) % 9;
>
> -for (int j = 0; j < msg.len; j++) {
> -  msg.data[j] = 'a' + j;
> +for (int j = 0; j < send_msg.len; j++) {
> +  send_msg.data[j] = 'a' + j;
>  }
>
> -msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);
> +msg_size = ((char *)&send_msg.data[send_msg.len] - (char *)&send_msg);
>
> -printf("calling write task = %u\n", task_num);
> +rtems_mutex_lock(&thread.mutex);
>
> -count = write(fd, &msg, sizeof(msg));
> +count = write(fd, &send_msg, sizeof(send_msg));
>  rtems_test_assert(count == msg_size);
> -printf("task = %u write count = %u\n", task_num, count);
>
> -printf("calling read task = %u\n", task_num);
> -count = read(fd, &msg, sizeof(msg));
> -rtems_test_assert(count > 0);
> -printf("task = %u read count = %u\n", task_num, count);
> +count = read(fd, &recv_msg, sizeof(recv_msg));
> +rtems_test_assert(send_msg.len == recv_msg.len);
> +
> +for (int i = 0; i < recv_msg.len; i++) {
> +  rtems_test_assert(send_msg.data[i] == recv_msg.data[i]);
> +}
>
> -printf("received message\n");
> -can_print_msg(&msg);
> +rtems_mutex_unlock(&thread.mutex);
> +
> +can_print_msg(&recv_msg);
>
>  sleep(1);
>}
> @@ -131,14 +129,11 @@ static void test_task(rtems_task_argument data)
>
>task_test_status[task_num] = true;
>
> -  printf("task exited = %u\n", task_num);
>rtems_task_exit();
>  }
>
>  int create_task(int i)
>  {
> -  printf("Creating task %d\n", i);
> -
>rtems_status_code result;
>rtems_name name;
>
> @@ -156,21 +151,18 @@ int create_task(int i)
>   RTEMS_FIFO | RTEMS_FLOATING_POINT,
>   &task_id[i]);
>if (result != RTEMS_SUCCESSFUL) {
> -printf("rtems_task_create error: %s\n", rtems_status_text(result));
> +CAN_ERR("rtems_task_create error: %s\n", rtems_status_text(result));
>  rtems_test_assert(result == RTEMS_SUCCESSFUL);
>}
>
> -  printf("number = %3" PRIi32 ", id = %08" PRIxrtems_id ", starting, ", i, 
> task_id[i]);
> -
>fflush(stdout);
>
> -  printf("starting task\n");
>result = rtems_task_start(task_id[i],

Re: [PATCH 2/2] cpukit/dev/can: Fix 64 bit build compilation warnings

[Gedare Bloom]

On Sat, Dec 3, 2022 at 2:02 AM Prashanth S  wrote:
>
> ---
>  cpukit/dev/can/can.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
> index 7098ce16c2..2462df7e25 100644
> --- a/cpukit/dev/can/can.c
> +++ b/cpukit/dev/can/can.c
> @@ -204,7 +204,7 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void 
> *buffer, size_t count)
>
>if (count < len) {
>  CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) 
> = %u\n",
> -sizeof(struct can_msg));
> +(uint32_t)sizeof(struct can_msg));

If you use the uint32_t, then you should also use the PRIu32 macro instead of %u

>  return -RTEMS_INVALID_SIZE;
>}
>
> --
> 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: Moving ticket milestones to a different RTEMS version

[Gedare Bloom]

That makes sense to me too, with a backward pointer (dependency) to
the previous release's ticket.

On Thu, Dec 1, 2022 at 9:35 PM Chris Johns  wrote:
>
> Hi,
>
> Joel and I have been cleaning up the 6 tickets and some have been moved to 7
> (thanks) which may be appropriate however I am wondering about open ended
> tickets for a specific set of work and release notes. These tickets are really
> great for collecting commits for a specific change.
>
> The release notes are based on the tickets for a release and milestone. An 
> open
> ended ticket for a specific task when part of release collects the related
> commits however moving that ticket to the next release moves the commits to 
> that
> release's release notes and the current release does not see the commits in 
> its
> release notes?
>
> Should the ticket be cloned (without comments?) to the next release and the 
> one
> on the current release closed. It seems to make sense to me. The work is
> continuing however it is closed for the branch being release?
>
> Thanks
> Chris
> ___
> 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

[rtems-docs 5.x v2] eng/vc-users.rst: Add commit message guidance

[Joel Sherrill]

Closes #4274.
---
 eng/vc-users.rst | 83 
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/eng/vc-users.rst b/eng/vc-users.rst
index 680c004..fcb7ce6 100644
--- a/eng/vc-users.rst
+++ b/eng/vc-users.rst
@@ -422,20 +422,91 @@ then you rewrite those commits with ``git rebase`` and 
push them up again, the
 others will have to re-merge their work and trying to integrate their work
 into yours can become messy.
 
-Accessing a developer's repository
+Accessing a Developer's Repository
 --
 
 RTEMS developers with Git commit access have personal repositories
 on https://git.rtems.org/ that can be cloned to view cutting-edge
 development work shared there.
 
+Commit Message Guidance
+---
+
+The commit message associated with a change to any software project
+is of critical importance. It is the explanation of the change and the
+rationale for it. Future users looing back through the project history
+will rely on it. Even the author of the change will likely rely on it
+once they have forgotten the details of the change. It is important to
+make the message useful. Here are some guidelines followed by the RTEMS
+Project to help improve the quality of our commit messages.
+
+* When committing a change the first line is a summary. Please make it short
+  while hinting at the nature of the change. You can discuses the change
+  if you wish in a ticket that has a PR number which can be referenced in
+  the commit message. After the first line, leave an empty line and add
+  whatever required details you feel are needed.
+
+* Patches should be as single purpose as possible. This is reflected in
+  the first line summary message. If you find yourself writing something
+  like "Fixed X and Y", "Updated A and B", or similar, then evaluate
+  whether the patch should really be a patch series rather than a single
+  larger patch.
+
+* Format the commit message so it is readable and clear. If you have
+  specific points related to the change make them with separate paragraphs
+  and if you wish you can optionally uses a `-` marker with suitable
+  indents and alignment to aid readability.
+
+* Limit the line length to less than 80 characters
+
+* Please use a real name with a valid email address. Please do not use
+  pseudonyms or provide anonymous contributions.
+
+* Please do not use terms such as "Fix bug", "With this change it
+  works", or "Bump hash". If you fix a bug please state the nature of the
+  bug and why this change fixes it. If a change makes something work then
+  detail the reason. You do not need to explain the change line by line
+  as the commits diff and associated ticket will.
+
+* If you change the formatting of source code in a repository please
+  make that a separate patch and use "Formatting changes only" on the first
+  line. Please indicate the reason or process. For example to "Conforming
+  to code standing", "Reverting to upstream format", "Result of automatic
+  formatting".
+
+* Similarly, if addressing a spelling, grammar, or Doxygen issue, please
+  put that in a commit by itself separate from technical changes.
+
+An example commit message:
+
+.. code-block:: shell
+
+  test/change: Test message on formatting of commits
+
+  - Shows a simple single first line
+
+  - Has an empty second line
+
+  - Shows the specifics of adding separate points in the commit message as
+separate paragraphs. It also shows a `-` separator and multilines
+that are less than the 80 character width
+
+  - Show a ticket update and close
+
+  Updates #9876
+  Closes #8765
+
+The first line generally starts with a file or directory name which
+indicates the area in RTEMS to which the commit applies. For a patch
+series which impacts multiple BSPs, it is common to put each BSP into
+a separate patch. This improves the quality and specificity of the
+commit messages.
+
 Creating a Patch
-
+-
 
-Before submitting a patch read about `Contributing
-`_ to RTEMS and the
-`Commit Message `_
-formatting we require.
+Before submitting a patch, please read `Commit Message Guidance`_ to
+become familiar with the commit message formatting we require.
 
 The recommended way to create a patch is to branch the Git repository master
 and use one commit for each logical change. Then you can use
-- 
1.8.3.1

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

[rtems-docs 5.x v2] eng/vc-users.rst: Add commit message guidance

[Joel Sherrill]

Closes #4275.
---
 eng/vc-users.rst | 83 
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/eng/vc-users.rst b/eng/vc-users.rst
index 31de516..0ef7a66 100644
--- a/eng/vc-users.rst
+++ b/eng/vc-users.rst
@@ -422,20 +422,91 @@ then you rewrite those commits with ``git rebase`` and 
push them up again, the
 others will have to re-merge their work and trying to integrate their work
 into yours can become messy.
 
-Accessing a developer's repository
+Accessing a Developer's Repository
 --
 
 RTEMS developers with Git commit access have personal repositories
 on https://git.rtems.org/ that can be cloned to view cutting-edge
 development work shared there.
 
+Commit Message Guidance
+---
+
+The commit message associated with a change to any software project
+is of critical importance. It is the explanation of the change and the
+rationale for it. Future users looing back through the project history
+will rely on it. Even the author of the change will likely rely on it
+once they have forgotten the details of the change. It is important to
+make the message useful. Here are some guidelines followed by the RTEMS
+Project to help improve the quality of our commit messages.
+
+* When committing a change the first line is a summary. Please make it short
+  while hinting at the nature of the change. You can discuses the change
+  if you wish in a ticket that has a PR number which can be referenced in
+  the commit message. After the first line, leave an empty line and add
+  whatever required details you feel are needed.
+
+* Patches should be as single purpose as possible. This is reflected in
+  the first line summary message. If you find yourself writing something
+  like "Fixed X and Y", "Updated A and B", or similar, then evaluate
+  whether the patch should really be a patch series rather than a single
+  larger patch.
+
+* Format the commit message so it is readable and clear. If you have
+  specific points related to the change make them with separate paragraphs
+  and if you wish you can optionally uses a `-` marker with suitable
+  indents and alignment to aid readability.
+
+* Limit the line length to less than 80 characters
+
+* Please use a real name with a valid email address. Please do not use
+  pseudonyms or provide anonymous contributions.
+
+* Please do not use terms such as "Fix bug", "With this change it
+  works", or "Bump hash". If you fix a bug please state the nature of the
+  bug and why this change fixes it. If a change makes something work then
+  detail the reason. You do not need to explain the change line by line
+  as the commits diff and associated ticket will.
+
+* If you change the formatting of source code in a repository please
+  make that a separate patch and use "Formatting changes only" on the first
+  line. Please indicate the reason or process. For example to "Conforming
+  to code standing", "Reverting to upstream format", "Result of automatic
+  formatting".
+
+* Similarly, if addressing a spelling, grammar, or Doxygen issue, please
+  put that in a commit by itself separate from technical changes.
+
+An example commit message:
+
+.. code-block:: shell
+
+  test/change: Test message on formatting of commits
+
+  - Shows a simple single first line
+
+  - Has an empty second line
+
+  - Shows the specifics of adding separate points in the commit message as
+separate paragraphs. It also shows a `-` separator and multilines
+that are less than the 80 character width
+
+  - Show a ticket update and close
+
+  Updates #9876
+  Closes #8765
+
+The first line generally starts with a file or directory name which
+indicates the area in RTEMS to which the commit applies. For a patch
+series which impacts multiple BSPs, it is common to put each BSP into
+a separate patch. This improves the quality and specificity of the
+commit messages.
+
 Creating a Patch
-
+-
 
-Before submitting a patch read about `Contributing
-`_ to RTEMS and the
-`Commit Message `_
-formatting we require.
+Before submitting a patch, please read `Commit Message Guidance`_ to
+become familiar with the commit message formatting we require.
 
 The recommended way to create a patch is to branch the Git repository master
 and use one commit for each logical change. Then you can use
-- 
1.8.3.1

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

[PATCH] rtems_shell_main_mmove problem

[zack leung]

Closes #4556
---
 cpukit/libmisc/shell/main_mmove.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_mmove.c
b/cpukit/libmisc/shell/main_mmove.c
index 38731b10a2..0029882d62 100644
--- a/cpukit/libmisc/shell/main_mmove.c
+++ b/cpukit/libmisc/shell/main_mmove.c
@@ -62,7 +62,7 @@ static int rtems_shell_main_mmove(
   /*
*  Now copy the memory.
*/
-  memcpy(dst, src, length);
+  memmove(dst, src, length);

  return 0;
 }
-- 
2.38.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks

[Prashanth S]

>>
>> The CAN framework has minimal Rx implementation, so to test loopback
>> driver the test application is modified to write and read atomically
>> ---
>>  testsuites/libtests/can01/init.c | 71 ++--
>>  1 file changed, 31 insertions(+), 40 deletions(-)
>>
>> diff --git a/testsuites/libtests/can01/init.c
b/testsuites/libtests/can01/init.c
>> index 0675fe606f..f70e68fb51 100644
>> --- a/testsuites/libtests/can01/init.c
>> +++ b/testsuites/libtests/can01/init.c
>> @@ -48,7 +48,7 @@
>> if (c3 == '9') { \
>>   if (c2 == 'z') {   \
>> if (c1 == 'z') { \
>> - printf("not enough task letters for names
!!!\n"); \
>> + CAN_ERR("not enough task letters for names
!!!\n"); \
>
>I don't think the print statements need to be macro'd in your test, so
>long as they only get printed when the test fails. When it's passing,
>then we would prefer it be quiet.

The CAN_ERR expands to printing the file name, line number, thread id and
error message.

Can we have this information printed by expanded macro or change to printf?

On Thu, 15 Dec 2022 at 02:57, Gedare Bloom  wrote:

> On Sat, Dec 3, 2022 at 2:02 AM Prashanth S 
> wrote:
> >
> > The CAN framework has minimal Rx implementation, so to test loopback
> > driver the test application is modified to write and read atomically
> > ---
> >  testsuites/libtests/can01/init.c | 71 ++--
> >  1 file changed, 31 insertions(+), 40 deletions(-)
> >
> > diff --git a/testsuites/libtests/can01/init.c
> b/testsuites/libtests/can01/init.c
> > index 0675fe606f..f70e68fb51 100644
> > --- a/testsuites/libtests/can01/init.c
> > +++ b/testsuites/libtests/can01/init.c
> > @@ -48,7 +48,7 @@
> > if (c3 == '9') { \
> >   if (c2 == 'z') {   \
> > if (c1 == 'z') { \
> > - printf("not enough task letters for names
> !!!\n"); \
> > + CAN_ERR("not enough task letters for names
> !!!\n"); \
>
> I don't think the print statements need to be macro'd in your test, so
> long as they only get printed when the test fails. When it's passing,
> then we would prefer it be quiet.
>
> >   exit( 1 ); \
> > } else   \
> >   c1++;  \
> > @@ -63,6 +63,10 @@
> >   else   \
> > c4++ \
> >
> > +struct test_thread {
> > +  rtems_mutex mutex;
> > +};
> > +
> >  static void test_task(rtems_task_argument);
> >  int can_loopback_init(const char *);
> >  int create_task(int);
> > @@ -70,60 +74,54 @@ int create_task(int);
> >  static rtems_id task_id[TASKS];
> >  static rtems_id task_test_status[TASKS] = {[0 ... (TASKS - 1)] = false};
> >
> > +static struct test_thread thread;
> > +
> >  const char rtems_test_name[] = "CAN test TX, RX with CAN loopback
> driver";
> >
> > -/*FIXME: Should Implement one more test application for the
> > - * RTR support
> > - *
> > - * For testing, the number of successful read and write
> > - * count is verified.
> > - */
> >  static void test_task(rtems_task_argument data)
> >  {
> > -  //sleep so that other tasks will be created.
> >sleep(1);
> >
> >int fd, task_num = (uint32_t)data;
> >uint32_t count = 0, msg_size;
> >
> > -  struct can_msg msg;
> > +  struct can_msg send_msg, recv_msg;
> >
> >printf("CAN tx and rx for %s\n", CAN_DEV_FILE);
> >
> >fd = open(CAN_DEV_FILE, O_RDWR);
> >if (fd < 0) {
> > -printf("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
> strerror(errno));
> > +CAN_ERR("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
> strerror(errno));
> >}
> >
> >rtems_test_assert(fd >= 0);
> >
> >for (int i = 0; i < NUM_TEST_MSGS; i++) {
> > -printf("test_task %u\n", task_num);
> > -
> > -msg.id = task_num;
> > -//FIXME: Implement Test cases for other flags also.
> > -msg.flags = 0;
> > -msg.len = (i + 1) % 9;
> > +send_msg.id = task_num;
> > +send_msg.flags = 0;
> > +send_msg.len = (i + 1) % 9;
> >
> > -for (int j = 0; j < msg.len; j++) {
> > -  msg.data[j] = 'a' + j;
> > +for (int j = 0; j < send_msg.len; j++) {
> > +  send_msg.data[j] = 'a' + j;
> >  }
> >
> > -msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);
> > +msg_size = ((char *)&send_msg.data[send_msg.len] - (char
> *)&send_msg);
> >
> > -printf("calling write task = %u\n", task_num);
> > +rtems_mutex_lock(&thread.mutex);
> >
> > -count = write(fd, &msg, sizeof(msg));
> > +count = write(fd, &send_msg, sizeof(send_msg));
> >  rtems_test_assert(count == msg_size);
> > -printf("task = %u write count = %u\n", task_num, count);
> >
> > -printf("calling read task = %u\n", task_num);
> > -count = read(fd, &msg, sizeof(msg));
> > -rtems

Re: [PATCH 2/2] cpukit/dev/can: Fix 64 bit build compilation warnings

[Sebastian Huber]

On 14/12/2022 22:29, Gedare Bloom wrote:

On Sat, Dec 3, 2022 at 2:02 AM Prashanth S  wrote:

---
  cpukit/dev/can/can.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 7098ce16c2..2462df7e25 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -204,7 +204,7 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void 
*buffer, size_t count)

if (count < len) {
  CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) = 
%u\n",
-sizeof(struct can_msg));
+(uint32_t)sizeof(struct can_msg));

If you use the uint32_t, then you should also use the PRIu32 macro instead of %u


Yes, or just use %zu without the cast.

--
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

Re: [PATCH 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks

[Sebastian Huber]

On 15/12/2022 08:19, Prashanth S wrote:

 >> +++ b/testsuites/libtests/can01/init.c
 >> @@ -48,7 +48,7 @@
 >>                     if (c3 == '9') {     \
 >>                       if (c2 == 'z') {   \
 >>                         if (c1 == 'z') { \
 >> -                         printf("not enough task letters for names 
!!!\n"); \
 >> +                         CAN_ERR("not enough task letters for names 
!!!\n"); \

 >
 >I don't think the print statements need to be macro'd in your test, so
 >long as they only get printed when the test fails. When it's passing,
 >then we would prefer it be quiet.

The CAN_ERR expands to printing the file name, line number, thread
id and error message.

Can we have this information printed by expanded macro or change to
printf?


The RTEMS Test Framework does all this. Why do we have to implement 
things specifically for this test?


--
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

Re: [PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.

[Prashanth S]

>How does this debugging get turned on/off?

-DRTEMS_CAN_DEBUG as a Compiler Flag will enable the debug prints.

>
>maybe use CAN_ERROR? unless there's a reason not to.

The debug #defines helps us to have control over the debug prints based on
the entity (isr, locks, rx, tx).
This helps the BSP CAN driver development to have debug prints based on the
entity (isr, locks, rx, tx).
Can we have this feature?

>
>>  #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg
*)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg))

On Thu, 15 Dec 2022 at 02:55, Gedare Bloom  wrote:

> How does this debugging get turned on/off?
>
>
> On Sat, Dec 3, 2022 at 2:00 AM Prashanth S 
> wrote:
> >
> > ---
> >  cpukit/include/dev/can/can.h | 27 +--
> >  1 file changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
> > index 9e55395039..4ee51ebc9d 100644
> > --- a/cpukit/include/dev/can/can.h
> > +++ b/cpukit/include/dev/can/can.h
> > @@ -53,13 +53,28 @@
> >printf(str, ##__VA_ARGS__);
>\
> >  } while (false);
> >
> > +#ifdef RTEMS_CAN_DEBUG
> > +
> >  #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
> > -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */
> > +
> > +#else /* RTEMS_CAN_DEBUG */
> > +
> > +#define CAN_DEBUG(str, ...)
> > +#define CAN_DEBUG_BUF(str, ...)
> > +#define CAN_DEBUG_ISR(str, ...)
> > +#define CAN_DEBUG_LOCK(str, ...)
> > +#define CAN_DEBUG_RX(str, ...)
> > +#define CAN_DEBUG_TX(str, ...)
> > +#define CAN_DEBUG_REG(str, ...)
> > +
> > +#endif /* RTEMS_CAN_DEBUG */
> > +
> >  #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__)
> >
> maybe use CAN_ERROR? unless there's a reason not to.
>
> >  #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg
> *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg))
> > --
> > 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 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks

[Prashanth S]

>>  >> +++ b/testsuites/libtests/can01/init.c
>>  >> @@ -48,7 +48,7 @@
>>  >> if (c3 == '9') { \
>>  >>   if (c2 == 'z') {   \
>>  >> if (c1 == 'z') { \
>>  >> - printf("not enough task letters for names
>> !!!\n"); \
>>  >> + CAN_ERR("not enough task letters for names
>> !!!\n"); \
>>  >
>>  >I don't think the print statements need to be macro'd in your test, so
>>  >long as they only get printed when the test fails. When it's passing,
>>  >then we would prefer it be quiet.
>>
>> The CAN_ERR expands to printing the file name, line number, thread
>> id and error message.
>>
>> Can we have this information printed by expanded macro or change to
>> printf?
>
>The RTEMS Test Framework does all this. Why do we have to implement
>things specifically for this test?

Ok, updating CAN_ERR to printf.

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