Looking for BSP for Atmel AT91SAM7X-EK

[Joel Sherrill]

Kate Feng wrote:
> Joel Sherrill wrote:
>
>> Kate Feng wrote:
>>
>>> Till Straumann wrote:
>>>
>>>> Ralf Corsepius wrote:
>>>>  
>>>>
>>>>> On Wed, 2007-12-12 at 21:27 -0700, Andrei Chichak wrote:
>>>>>     
>>>>>> Thanks Joel,
>>>>>>
>>>>>> Are there any docs around dealing with putting together a new 
>>>>>> BSP? I have taken a look at the BSP and porting guides but there 
>>>>>> doesn't seem to be a section on which configuration files to 
>>>>>> munge to get the bootstrap procedure to pick up the new BSP.
>>>>>>           
>>>>>
>>>>> Well, actually, it's pretty simple.
>>>>>
>>>>> 1. cd <src>/c/src/lib/libbsp/<cpu>
>>>>> and copy over the BSP which resembles to your BSP most
>>>>> cp <bsp> <mybsp>
>>>>>
>>>>> 2. edit your bsp's files below <mybsp>/
>>>>> [The actual act of porting]
>>>>>
>>>>>       
>>>>
>>>>
>>>> If I may comment: that would be pretty bad practice.
>>>> A better way would be
>>>>  - make parts in <bsp> that are similar enough to what
>>>>    'mybsp' needs a library that supports both, <bsp> and
>>>>    <mybsp>. Try to make interfaces generic enough so that
>>>>    they could be useful to a yet more similar BSP that
>>>>    may be created in the future (but also: try to keep it simple).
>>>>  - modify <bsp> so it uses the (new) library
>>>>  - let <mybsp> use the library
>>>>  - only add new parts that are really specific to <mybsp>
>>>>
>>>> The myriad of powerpc BSPs are a painful example of
>>>> the result of the 'copy + edit' strategy when creating new
>>>> BSPs. It's maintenance hell.
>>>
>>> I somehow agree with what Ralf Corsepius wrote :
>>> > The poor shape the powerpc BSPs are in is a result of lack of RTEMS
>>> > internal APIs and structural defects of the source code (esp. the
>>> > "shared" dirs).
>>>
>>> Technically speaking, to reduce maintence effort effectively, one
>>> should start to think about C++ for Object Orient Programming.
>>>
>>>   
>>
>> If you want to write applications in C++, I am all for it
>> and do it myself.  But don't introduce it in the BSPs or
>> device drivers in RTEMS.
>>
>> It is appropriate to think about OO design techniques. 
>
> What's wrong with C++ in the BSPs or  device drivers in
> RTEMS if one felt the maintenance hell ?
You have very little control over when the language run-time
runs, what it does, or how it impacts you.  The C++ (or Ada)
compiler implicitly makes calls to routines you should not
be using in critical low level situations.  And these cases
are often difficult to predict and surprising.  Off the top
of my head, I can think of these implicitly generated things
that can nail you:

+ calls to malloc/delete
+ calls to other library routines that use mutexes
+ exceptions

In general, BSP, device driver, and OS code makes very strict
assumptions about what is going to happen and what will
get called and when.  Any time you use a language with a higher
level of "help", it can surprise you in the worst way at the
worst time.

For example, you can't even write a Timer Service Routine in
Ada because Ada code implicitly generates calls to lock
a priority ceiling pthread mutex. Priority ceiling can only be
used from the task level -- NOT ISR. 

C++ and Ada and Java and every other language has its place
and although I like C++, they are NOT the right choice when
you don't want to be surprised by implicit compiler actions.

I like C++ and Ada and am happy to write applications in either.
But I have seen too many cases where they cause problems when
you are doing low-level code to every choose them.

And this ignores the issue of how much of a run-time is assumed
to be working when they do certain things.  You can't call malloc()
until RTEMS is nearly completely initialized. 

--joel

>
> Kate
>
>>
>>
>> --joel
>>
>>> Kate
>>>  
>>>
>>>> T.
>>>>  
>>>>
>>>>> 3. cd <src>/c/src
>>>>> ../../bootstrap
>>>>>
>>>>>
>>>>> The next configure run should pick up <mybsp> automatically.
>>>>>
>>>>> Ralf
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.com
>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>       
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>   
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>
>>
>
>