Re: Request for feedback for CAN message structure
Hello Prashanth S and others, excuse me for lower activity last weeks. We have exams period and I have lot of other duties and was even ill. I am at Embedded World in Nuremberg now, so may it be there is some chance to meet somebody other from RTEMS community. As for the e-mail it is better to add one of my personal e-mails (p...@cmp.felk.cvut.cz or pp...@pikron.com) to notice me for something important, I do not check every message comming through my list subscription. I go through RTEMS, NuttX, CAN, etc. forums only when I have spare time. On Monday 20 of June 2022 18:37:38 Prashanth S wrote: > This is a request for suggestions and feedback for the CAN message > structure. > > *CAN message structure that represents the can messages from application to > driver:* > > struct can_message { > uint32_t timestamp; > uint32_t id; // 32 bits to support extended id (29 bits) > uint16_t flags;// RTR | BRS | EXT ... > uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64 > uint8_t res; // reserved for alignment. > uint8_t data[64]; // For supporting data transfer up to 64 bytes. > }; > > This is the CAN messages structure created based on the suggestions in the > mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN). Yes I like solution with explicit and aligned fields. I confirm that I think that length representing real data length is better and it has been chosen for CAN FD by SocketCAN. I confirm that flags implemented with explicit sized field seem to be more safe to me. Bitfields are tricky due to endianing and have problem with initialization and copying when new field is added. I am not sure if the field name "dlc" (data length code) is right when the field represents real length, may be "len" is a better match. I think that fields order makes sense as well (alignment, purpose etc..). Only think to consider is possibility to swap uint32_t timestamp; uint32_t id; because id is the first and the most important and accessed field, so when the pointer to structure is give it can be small win on some targets that it can be accessed without offset addition. But that is probably neglectable and there can be arguments against. Another think to consider is a size of "dlc" and or "len" code. There is ongoing standardization process for CAN XL and it would allow CAN frames up to 2kB and the length will be with byte granularity. But CAN XL adds datatype filed and much more options so it is probably out of the actual RTEMS scope and would require variable length read and write systemcalls because 2kB overhead for some 1 or 2 byte message is too high. So even 8 bit length field is OK for now and may be res field can solve CAN XL compatibility one day. So generally I agree with the message structure, I declare minor weight vote to switch from "dlc" to "len". I think that switch to common message structure based API on RTEMS would be big win and that (at least for now) keeping character device like API with IOCTLs is simpler and matches better actual RTEMS CAN implementations. Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Request for feedback for CAN message structure
IIRC Pavel asked to always being on cc to get CAN related email right to his inbox instead of email list boxes... On 6/20/22 18:37, Prashanth S wrote: Hi All, This is a request for suggestions and feedback for the CAN message structure. *CAN message structure that represents the can messages from application to driver:* struct can_message { uint32_t timestamp; uint32_t id; // 32 bits to support extended id (29 bits) uint16_t flags; // RTR | BRS | EXT ... uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64 uint8_t res; // reserved for alignment. uint8_t data[64]; // For supporting data transfer up to 64 bytes. }; This is the CAN messages structure created based on the suggestions in the mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN). Regards Prashanth S ___ 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
Request for feedback for CAN message structure
Hi All, This is a request for suggestions and feedback for the CAN message structure. *CAN message structure that represents the can messages from application to driver:* struct can_message { uint32_t timestamp; uint32_t id; // 32 bits to support extended id (29 bits) uint16_t flags;// RTR | BRS | EXT ... uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64 uint8_t res; // reserved for alignment. uint8_t data[64]; // For supporting data transfer up to 64 bytes. }; This is the CAN messages structure created based on the suggestions in the mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN). Regards Prashanth S ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] testsuite: Fix gcc 12 warnings
Ok On Sun, Jun 19, 2022, 9:10 PM wrote: > From: Chris Johns > > --- > testsuites/libtests/POSIX/readv.c | 2 +- > testsuites/libtests/POSIX/sigismember.c | 2 +- > testsuites/libtests/POSIX/sigprocmask.c | 3 ++- > testsuites/libtests/POSIX/writev.c| 2 +- > testsuites/psxtests/psxhdrs/arpa/inet/inet_ntop.c | 2 +- > testsuites/psxtests/psxhdrs/fcntl/openat.c| 4 ++-- > testsuites/psxtests/psxhdrs/netdb/gethostbyaddr.c | 2 +- > .../psxhdrs/pthread/pthread_attr_getdetachstate.c | 4 ++-- > .../psxtests/psxhdrs/pthread/pthread_attr_getguardsize.c | 4 ++-- > .../psxhdrs/pthread/pthread_attr_getinheritsched.c| 4 ++-- > .../psxtests/psxhdrs/pthread/pthread_attr_getschedparam.c | 4 ++-- > .../psxhdrs/pthread/pthread_attr_getschedpolicy.c | 4 ++-- > .../psxtests/psxhdrs/pthread/pthread_attr_getscope.c | 4 ++-- > .../psxtests/psxhdrs/pthread/pthread_attr_getstack.c | 2 +- > .../psxtests/psxhdrs/pthread/pthread_attr_getstackaddr.c | 2 +- > .../psxtests/psxhdrs/pthread/pthread_attr_getstacksize.c | 4 ++-- > .../psxtests/psxhdrs/pthread/pthread_attr_setschedparam.c | 4 ++-- > testsuites/psxtests/psxhdrs/pthread/pthread_cond_init.c | 2 +- > .../psxtests/psxhdrs/pthread/pthread_cond_timedwait.c | 2 +- > .../psxhdrs/pthread/pthread_condattr_getpshared.c | 2 +- > testsuites/psxtests/psxhdrs/pthread/pthread_create.c | 2 +- > .../psxhdrs/pthread/pthread_mutex_getprioceiling.c| 4 ++-- > testsuites/psxtests/psxhdrs/pthread/pthread_mutex_init.c | 2 +- > .../psxtests/psxhdrs/pthread/pthread_mutex_timedlock.c| 2 +- > .../psxhdrs/pthread/pthread_mutexattr_getprioceiling.c| 2 +- > .../psxhdrs/pthread/pthread_mutexattr_getprotocol.c | 4 ++-- > .../psxhdrs/pthread/pthread_mutexattr_getpshared.c| 4 ++-- > testsuites/psxtests/psxhdrs/sys/select/pselect.c | 4 ++-- > testsuites/psxtests/psxhdrs/sys/socket/bind.c | 2 +- > testsuites/psxtests/psxhdrs/sys/socket/connect.c | 6 +++--- > testsuites/psxtests/psxhdrs/sys/socket/getsockopt.c | 2 +- > testsuites/psxtests/psxhdrs/sys/socket/send.c | 2 +- > testsuites/psxtests/psxhdrs/sys/socket/sendmsg.c | 2 +- > testsuites/psxtests/psxhdrs/sys/socket/sendto.c | 4 ++-- > testsuites/psxtests/psxhdrs/sys/socket/setsockopt.c | 2 +- > testsuites/psxtests/psxhdrs/sys/stat/futimens.c | 4 ++-- > testsuites/psxtests/psxhdrs/sys/stat/utimensat.c | 4 ++-- > testsuites/psxtests/psxhdrs/sys/time/utimes.c | 8 > testsuites/psxtests/psxhdrs/termios/cfgetispeed.c | 4 ++-- > testsuites/psxtests/psxhdrs/termios/cfgetospeed.c | 4 ++-- > testsuites/psxtests/psxhdrs/termios/cfsetispeed.c | 4 ++-- > testsuites/psxtests/psxhdrs/termios/cfsetospeed.c | 4 ++-- > testsuites/psxtests/psxhdrs/termios/tcgetattr.c | 4 ++-- > testsuites/psxtests/psxhdrs/termios/tcsetattr.c | 4 ++-- > testsuites/psxtests/psxhdrs/time/asctime.c| 2 +- > testsuites/psxtests/psxhdrs/time/asctime_r.c | 2 +- > testsuites/psxtests/psxhdrs/time/clock_settime.c | 2 +- > testsuites/psxtests/psxhdrs/time/ctime.c | 2 +- > testsuites/psxtests/psxhdrs/time/ctime_r.c| 2 +- > testsuites/psxtests/psxhdrs/time/gmtime.c | 2 +- > testsuites/psxtests/psxhdrs/time/gmtime_r.c | 2 +- > testsuites/psxtests/psxhdrs/time/localtime.c | 2 +- > testsuites/psxtests/psxhdrs/time/localtime_r.c| 2 +- > testsuites/psxtests/psxhdrs/time/strftime.c | 2 +- > testsuites/psxtests/psxhdrs/unistd/setgroups.c| 2 +- > testsuites/psxtests/psxhdrs/utime/utime.c | 2 +- > testsuites/psxtests/psxhdrs/wchar/mbsinit.c | 4 ++-- > testsuites/psxtests/psxkey07/init.c | 3 ++- > testsuites/psxtests/psxkey08/init.c | 2 +- > testsuites/psxtests/psxmsgq01/init.c | 2 +- > testsuites/sptests/sp68/init.c| 2 +- > testsuites/sptests/spfatal32/init.c | 5 + > 62 files changed, 96 insertions(+), 89 deletions(-) > > diff --git a/testsuites/libtests/POSIX/readv.c > b/testsuites/libtests/POSIX/readv.c > index a980e9468c..6b0bf63f94 100644 > --- a/testsuites/libtests/POSIX/readv.c > +++ b/testsuites/libtests/POSIX/readv.c > @@ -14,7 +14,7 @@ > > int main(void) > { > - struct iovec iov; > + struct iovec iov = { 0 }; >int count = 4; >ssize_t ret; > > diff --git a/testsuites/libtests/POSIX/sigismember.c > b/testsuites/libtests/POSIX/sigismember.c > index ed980b70f0..f4c7d37cb2 100644 > --- a/testsuites/libtests/POSIX/sigismember.c > +++ b/testsuites/libtests/POSIX/sigismember.c > @@ -14,7
Re: [PATCH 13/13] jffs2: Update baseline version to Linux v5.9
On 20/06/2022 09:46, Chris Johns wrote: On 20/6/22 4:06 pm, Sebastian Huber wrote: On 11/06/2022 03:57, Chris Johns wrote: I will take a look at the heap fragmentation under large block writes as a background task. I have openedhttps://devel.rtems.org/ticket/4664 to track this issue. In 2018 I replaced the first fit allocator with TLSF due to heap fragmentation issues in combination with JFFS2 in an RTEMS application operating 24/7. Since then we no longer observed heap fragmentation issues. I am sure it would make a difference. Is the change available? I added the corresponding tickets in 2018, but had no time to work on it. -- 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 13/13] jffs2: Update baseline version to Linux v5.9
On 20/6/22 4:06 pm, Sebastian Huber wrote: > On 11/06/2022 03:57, Chris Johns wrote: >> I will take a look at the heap fragmentation under large block writes as a >> background task. I have openedhttps://devel.rtems.org/ticket/4664 to track >> this >> issue. > > In 2018 I replaced the first fit allocator with TLSF due to heap fragmentation > issues in combination with JFFS2 in an RTEMS application operating 24/7. Since > then we no longer observed heap fragmentation issues. I am sure it would make a difference. Is the change available? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] freebsd/nfsv4: Fix misaligned 64bit user dirent write
On 20/6/22 4:14 pm, Sebastian Huber wrote: > On 20/06/2022 04:57, Chris Johns wrote: >> Module: rtems-libbsd >> Branch: 6-freebsd-12 >> Commit: c56a34f54767decf3e398651c30bea9ebbd9572a >> Changeset:http://git.rtems.org/rtems-libbsd/commit/?id=c56a34f54767decf3e398651c30bea9ebbd9572a >> >> >> Author: Chris Johns >> Date: Mon Jun 20 12:44:41 2022 +1000 >> >> freebsd/nfsv4: Fix misaligned 64bit user dirent write > > The tl2 is a pointer to uint32_t. On which platform did this case a problem? > Platforms should support misaligned load/store operations to normal memory. Ah OK and thanks. It may be the cookie access. I will have to look again. The exe it LTO optimized without rtems or libbsd having fat object files. The one change fixed stopped the crash but I will take a close look. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] freebsd/nfsv4: Fix misaligned 64bit user dirent write
On 20/06/2022 04:57, Chris Johns wrote: Module:rtems-libbsd Branch:6-freebsd-12 Commit:c56a34f54767decf3e398651c30bea9ebbd9572a Changeset:http://git.rtems.org/rtems-libbsd/commit/?id=c56a34f54767decf3e398651c30bea9ebbd9572a Author:Chris Johns Date: Mon Jun 20 12:44:41 2022 +1000 freebsd/nfsv4: Fix misaligned 64bit user dirent write The tl2 is a pointer to uint32_t. On which platform did this case a problem? Platforms should support misaligned load/store operations to normal memory. -- 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 13/13] jffs2: Update baseline version to Linux v5.9
On 11/06/2022 03:57, Chris Johns wrote: I will take a look at the heap fragmentation under large block writes as a background task. I have openedhttps://devel.rtems.org/ticket/4664 to track this issue. In 2018 I replaced the first fit allocator with TLSF due to heap fragmentation issues in combination with JFFS2 in an RTEMS application operating 24/7. Since then we no longer observed heap fragmentation issues. -- 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