<div dir="ltr">>On Tue, Nov 29, 2022 at 6:58 AM Prashanth S <<a href="mailto:fishesprashanth@gmail.com">fishesprashanth@gmail.com</a>> wrote:<br>>><br>>> > On 29/11/2022 05:57, Gedare Bloom wrote:<br>>> > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)<br>>> > >><br>>> > >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);<br>>> > >><br>>> > >> -    printf("calling write task = %u\n", task_num);<br>>> > >> +    CAN_DEBUG("calling write task = %u\n", task_num);<br>>> > > The general philosophy in our test suite is to only print something if<br>>> > > there's a failure. So just remove these debug statements that are<br>>> > > leftover from your development approach.<br>>> ><br>>> > Another approach could be to use the RTEMS Test Framework in which the<br>>> > test verbosity is controlled by a configuration option.<br>>><br>>> I will look into the RTEMS Test Framework.<br>>><br>>> ><br>>> > ><br>>> > >>       count = write(fd, &msg, sizeof(msg));<br>>> > >>       rtems_test_assert(count == msg_size);<br>>> > >> -    printf("task = %u write count = %u\n", task_num, count);<br>>> > >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);<br>>> > >><br>>> > >> -    printf("calling read task = %u\n", task_num);<br>>> > >> +    CAN_DEBUG("calling read task = %u\n", task_num);<br>>> > >>       count = read(fd, &msg, sizeof(msg));<br>>> > >>       rtems_test_assert(count > 0);<br>>> > > Since you send the messages, you know their sizes. You should be able<br>>> > > to assert the exact amount received?<br>>> > ><br>>> ><br>>> > Yes, and you probably know also the expected content of the message.<br>>> > This should be also checked. If there are ordering guarantees, then each<br>>> > message should have a unique content and the ordering should be checked<br>>> > as well.<br>>><br>>> The CAN framework has only minimal Rx support (CAN Framework sends the latest received CAN message).<br>>> So only the read success is checked.<br>>><br>>You should be able to structure your test to serialize the writes and<br>>reads in a predictable way, and then verify they are received as you<br>>expect.<br><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Ok, I will serialize the write, read and verify the content.</div><div><br></div><div>It can be done in the test application, but from the CAN Framework I need to find a way to uniquely identify an </div><div>open call (I tried looking for that, but the documentation for GSoC was pending from my side), so that we can </div><div>create an Rx queue for each open call which will be the essential Rx implementation. I will try to propose a design</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>within 1 or 2 weeks.</div><div><br></div></blockquote>Regards</div><div>Prashanth S</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Nov 2022 at 06:47, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Nov 29, 2022 at 6:58 AM Prashanth S <<a href="mailto:fishesprashanth@gmail.com" target="_blank">fishesprashanth@gmail.com</a>> wrote:<br>
><br>
> > On 29/11/2022 05:57, Gedare Bloom wrote:<br>
> > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)<br>
> > >><br>
> > >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);<br>
> > >><br>
> > >> -    printf("calling write task = %u\n", task_num);<br>
> > >> +    CAN_DEBUG("calling write task = %u\n", task_num);<br>
> > > The general philosophy in our test suite is to only print something if<br>
> > > there's a failure. So just remove these debug statements that are<br>
> > > leftover from your development approach.<br>
> ><br>
> > Another approach could be to use the RTEMS Test Framework in which the<br>
> > test verbosity is controlled by a configuration option.<br>
><br>
> I will look into the RTEMS Test Framework.<br>
><br>
> ><br>
> > ><br>
> > >>       count = write(fd, &msg, sizeof(msg));<br>
> > >>       rtems_test_assert(count == msg_size);<br>
> > >> -    printf("task = %u write count = %u\n", task_num, count);<br>
> > >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);<br>
> > >><br>
> > >> -    printf("calling read task = %u\n", task_num);<br>
> > >> +    CAN_DEBUG("calling read task = %u\n", task_num);<br>
> > >>       count = read(fd, &msg, sizeof(msg));<br>
> > >>       rtems_test_assert(count > 0);<br>
> > > Since you send the messages, you know their sizes. You should be able<br>
> > > to assert the exact amount received?<br>
> > ><br>
> ><br>
> > Yes, and you probably know also the expected content of the message.<br>
> > This should be also checked. If there are ordering guarantees, then each<br>
> > message should have a unique content and the ordering should be checked<br>
> > as well.<br>
><br>
> The CAN framework has only minimal Rx support (CAN Framework sends the latest received CAN message).<br>
> So only the read success is checked.<br>
><br>
You should be able to structure your test to serialize the writes and<br>
reads in a predictable way, and then verify they are received as you<br>
expect.<br>
<br>
><br>
> Regards<br>
> Prashanth S<br>
><br>
> On Tue, 29 Nov 2022 at 12:24, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On 29/11/2022 05:57, Gedare Bloom wrote:<br>
>> >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)<br>
>> >><br>
>> >>       msg_size = ((char *)&msg.data[msg.len] - (char *)&msg);<br>
>> >><br>
>> >> -    printf("calling write task = %u\n", task_num);<br>
>> >> +    CAN_DEBUG("calling write task = %u\n", task_num);<br>
>> > The general philosophy in our test suite is to only print something if<br>
>> > there's a failure. So just remove these debug statements that are<br>
>> > leftover from your development approach.<br>
>><br>
>> Another approach could be to use the RTEMS Test Framework in which the<br>
>> test verbosity is controlled by a configuration option.<br>
>><br>
>> ><br>
>> >>       count = write(fd, &msg, sizeof(msg));<br>
>> >>       rtems_test_assert(count == msg_size);<br>
>> >> -    printf("task = %u write count = %u\n", task_num, count);<br>
>> >> +    CAN_DEBUG("task = %u write count = %u\n", task_num, count);<br>
>> >><br>
>> >> -    printf("calling read task = %u\n", task_num);<br>
>> >> +    CAN_DEBUG("calling read task = %u\n", task_num);<br>
>> >>       count = read(fd, &msg, sizeof(msg));<br>
>> >>       rtems_test_assert(count > 0);<br>
>> > Since you send the messages, you know their sizes. You should be able<br>
>> > to assert the exact amount received?<br>
>> ><br>
>><br>
>> Yes, and you probably know also the expected content of the message.<br>
>> This should be also checked. If there are ordering guarantees, then each<br>
>> message should have a unique content and the ordering should be checked<br>
>> as well.<br>
>><br>
>> --<br>
>> embedded brains GmbH<br>
>> Herr Sebastian HUBER<br>
>> Dornierstr. 4<br>
>> 82178 Puchheim<br>
>> Germany<br>
>> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> phone: +49-89-18 94 741 - 16<br>
>> fax:   +49-89-18 94 741 - 08<br>
>><br>
>> Registergericht: Amtsgericht München<br>
>> Registernummer: HRB 157899<br>
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
>> Unsere Datenschutzerklärung finden Sie hier:<br>
>> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
</blockquote></div>