Determining resource usage for BSP drivers

[Sebastian Huber]

On 10.02.23 14:53, Jan.Sommer at dlr.de wrote:
> 
>> -----Original Message-----
>> From: users<users-bounces at rtems.org>  On Behalf Of Sebastian Huber
>> Sent: Freitag, 10. Februar 2023 14:23
>> To:martinerikwerner.aac at gmail.com;users at rtems.org
>> Subject: Re: Determining resource usage for BSP drivers
>>
>> On 10.02.23 14:19,martinerikwerner.aac at gmail.com  wrote:
>>> Some BSP drivers use rtems objects in their implementation, for
>>> example GRCAN creating semaphores in bsps/shared/grlib/can/grcan.c.
>>>
> [...]
>>> Or is it assumed that the system will be configured with unlimited
>>> resources instead in most cases where this could become an issue?
>> Yes, it is quite difficult to do the resource accounting for the Classic API
>> objects. We rewrote a lot of drivers to use the self-contained
>> synchronization objects:
>>
>> https://docs.rtems.org/branches/master/c-user/self_contained_objects.html
>>
> Ah, very interesting and well explained.
> Can one use it as a general rule of thumb for new applications to prefer those self-contained objects instead of the classic rtems_semaphore_create() objects?
> And are there any pitfalls when mixing those two APIs or is it safe to do so?

You can mix the APIs as you like.  For applications, I would use a 
standard API such as POSIX or the C++ library. The POSIX objects perform 
a bit more error checking. The self-contained objects mentioned above 
are performance optimized.

-- 
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/