Per-BSP confdefs (or resource allocation)

Joel Sherrill joel.sherrill at oarcorp.com
Thu Oct 22 14:30:36 UTC 2015



On 10/22/2015 8:55 AM, Isaac Gutekunst wrote:
> On 10/22/2015 01:33 AM, Sebastian Huber wrote:
>>
>>
>> On 21/10/15 21:53, Isaac Gutekunst wrote:
>>> Hi Devel,
>>>
>>> I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks,
>>> etc) a BSP requires for an empty project (empty Init function).
>>
>> There is no useful support for this and this is a constant source of problems.
>>
>> One way out of this situation would be to use self-contained objects for the drivers.
>>
>>>
>>> I took a look at this page:
>>> https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html
>>> but couldn't glean the correct method.
>>>
>>> What is the preferred way to do so?
>>>
>>> Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and
>>> Ethernet.
>>>
>>>
>>
>> In case an empty project includes all these drivers, then something is wrong with this BSP.
>>
> That's good to know. Is it advisable to have all the drivers disabled by default? Of course, at
> minimum a BSP needs a console driver.

Technically a BSP doesn't even need that. Many applications field without one.
The clock tick is technically also optional but that is almost universally required
by applications. The minimum BSP technically only needs to startup and shutdown.

But if you want to link/run all the tests, you need a console, clock tick, and
benchmark timer driver.

I have seen bspstart.c or other initialization files pull in more than minimum
required. I have also seen bugs in Makefile.am that result in the entire BSP
being a binary blob always linked in.

> Our console driver does use one task, and one or more mutexes. Is this something we should try
> hard to change?

Why does it use so many resources? The termios framework provides all the
buffering internally and confdefs.h accounts for them.

--joel



More information about the devel mailing list