RTEMS | cpukit/confdefs: Add CAN stack resource calculation (!1097)

Tue Mar 3 20:04:23 UTC 2026

Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1097 was reviewed by Michal Lenc

--

Michal Lenc started a new discussion on cpukit/include/rtems/confdefs/threads.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1097#note_144189

 > -  ( CONFIGURE_MAXIMUM_TASKS + _CONFIGURE_LIBBLOCK_TASKS )
 > +#ifdef CONFIGURE_MAXIMUM_CAN_QUEUES
 > +  #define _CONFIGURE_CAN_TASKS CONFIGURE_MAXIMUM_CAN_QUEUES

Number of CAN tasks should not depend on number of queues though. There is no upper limit for number of queues between the controller and application - every `open` creates two new unique queues (one TX, one RX) plus the user can create ad lib number of his own queues. Also new queue doesn't mean another task - there one garbage collector task per registered controller.

In general, every initialized CAN controller has one worker thread task and queue garbage collector task. So I would vote for renaming `CONFIGURE_MAXIMUM_CAN_QUEUES` to something like `CONFIGURE_MAXIMUM_CAN_CONTROLLERS` or maybe better `CONFIGURE_MAXIMUM_CAN_CHIPS` since we use `_chip` naming convention in the code. And make it `*2` automatically for garbage collector tasks.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1097
You're receiving this email because of your account on gitlab.rtems.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260303/ec149aac/attachment.htm>