[PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework

[Prashanth S]

>On Tue, Nov 29, 2022 at 6:58 AM Prashanth S <fishesprashanth at gmail.com>
wrote:
>>
>> > On 29/11/2022 05:57, Gedare Bloom wrote:
>> > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument
data)
>> > >>
>> > >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);
>> > >>
>> > >> -    printf("calling write task = %u\n", task_num);
>> > >> +    CAN_DEBUG("calling write task = %u\n", task_num);
>> > > The general philosophy in our test suite is to only print something
if
>> > > there's a failure. So just remove these debug statements that are
>> > > leftover from your development approach.
>> >
>> > Another approach could be to use the RTEMS Test Framework in which the
>> > test verbosity is controlled by a configuration option.
>>
>> I will look into the RTEMS Test Framework.
>>
>> >
>> > >
>> > >>       count = write(fd, &msg, sizeof(msg));
>> > >>       rtems_test_assert(count == msg_size);
>> > >> -    printf("task = %u write count = %u\n", task_num, count);
>> > >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);
>> > >>
>> > >> -    printf("calling read task = %u\n", task_num);
>> > >> +    CAN_DEBUG("calling read task = %u\n", task_num);
>> > >>       count = read(fd, &msg, sizeof(msg));
>> > >>       rtems_test_assert(count > 0);
>> > > Since you send the messages, you know their sizes. You should be able
>> > > to assert the exact amount received?
>> > >
>> >
>> > Yes, and you probably know also the expected content of the message.
>> > This should be also checked. If there are ordering guarantees, then
each
>> > message should have a unique content and the ordering should be checked
>> > as well.
>>
>> The CAN framework has only minimal Rx support (CAN Framework sends the
latest received CAN message).
>> So only the read success is checked.
>>
>You should be able to structure your test to serialize the writes and
>reads in a predictable way, and then verify they are received as you
>expect.

Ok, I will serialize the write, read and verify the content.

It can be done in the test application, but from the CAN Framework I need
to find a way to uniquely identify an
open call (I tried looking for that, but the documentation for GSoC was
pending from my side), so that we can
create an Rx queue for each open call which will be the essential Rx
implementation. I will try to propose a design

within 1 or 2 weeks.

Regards
Prashanth S

On Wed, 30 Nov 2022 at 06:47, Gedare Bloom <gedare at rtems.org> wrote:

> On Tue, Nov 29, 2022 at 6:58 AM Prashanth S <fishesprashanth at gmail.com>
> wrote:
> >
> > > On 29/11/2022 05:57, Gedare Bloom wrote:
> > > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument
> data)
> > > >>
> > > >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);
> > > >>
> > > >> -    printf("calling write task = %u\n", task_num);
> > > >> +    CAN_DEBUG("calling write task = %u\n", task_num);
> > > > The general philosophy in our test suite is to only print something
> if
> > > > there's a failure. So just remove these debug statements that are
> > > > leftover from your development approach.
> > >
> > > Another approach could be to use the RTEMS Test Framework in which the
> > > test verbosity is controlled by a configuration option.
> >
> > I will look into the RTEMS Test Framework.
> >
> > >
> > > >
> > > >>       count = write(fd, &msg, sizeof(msg));
> > > >>       rtems_test_assert(count == msg_size);
> > > >> -    printf("task = %u write count = %u\n", task_num, count);
> > > >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);
> > > >>
> > > >> -    printf("calling read task = %u\n", task_num);
> > > >> +    CAN_DEBUG("calling read task = %u\n", task_num);
> > > >>       count = read(fd, &msg, sizeof(msg));
> > > >>       rtems_test_assert(count > 0);
> > > > Since you send the messages, you know their sizes. You should be able
> > > > to assert the exact amount received?
> > > >
> > >
> > > Yes, and you probably know also the expected content of the message.
> > > This should be also checked. If there are ordering guarantees, then
> each
> > > message should have a unique content and the ordering should be checked
> > > as well.
> >
> > The CAN framework has only minimal Rx support (CAN Framework sends the
> latest received CAN message).
> > So only the read success is checked.
> >
> You should be able to structure your test to serialize the writes and
> reads in a predictable way, and then verify they are received as you
> expect.
>
> >
> > Regards
> > Prashanth S
> >
> > On Tue, 29 Nov 2022 at 12:24, Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>
> >>
> >>
> >> On 29/11/2022 05:57, Gedare Bloom wrote:
> >> >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)
> >> >>
> >> >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);
> >> >>
> >> >> -    printf("calling write task = %u\n", task_num);
> >> >> +    CAN_DEBUG("calling write task = %u\n", task_num);
> >> > The general philosophy in our test suite is to only print something if
> >> > there's a failure. So just remove these debug statements that are
> >> > leftover from your development approach.
> >>
> >> Another approach could be to use the RTEMS Test Framework in which the
> >> test verbosity is controlled by a configuration option.
> >>
> >> >
> >> >>       count = write(fd, &msg, sizeof(msg));
> >> >>       rtems_test_assert(count == msg_size);
> >> >> -    printf("task = %u write count = %u\n", task_num, count);
> >> >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);
> >> >>
> >> >> -    printf("calling read task = %u\n", task_num);
> >> >> +    CAN_DEBUG("calling read task = %u\n", task_num);
> >> >>       count = read(fd, &msg, sizeof(msg));
> >> >>       rtems_test_assert(count > 0);
> >> > Since you send the messages, you know their sizes. You should be able
> >> > to assert the exact amount received?
> >> >
> >>
> >> Yes, and you probably know also the expected content of the message.
> >> This should be also checked. If there are ordering guarantees, then each
> >> message should have a unique content and the ordering should be checked
> >> as well.
> >>
> >> --
> >> embedded brains GmbH
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.huber at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221130/a9640141/attachment-0001.htm>