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

Gedare Bloom gedare at rtems.org
Wed Nov 30 01:17:19 UTC 2022


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/


More information about the devel mailing list