Looking for BSP for Atmel AT91SAM7X-EK

[Andrei Chichak]

Since I started this thread, I guess I can have a say too...

Being a newbie to RTEMS I have a different perspective than the others who have
been doing this for a decade.

I have found that a bunch of the BSPs are for boards that aren't made any more
(CSB360, 336, 337), others have been deleted for various reasons (EFI332),
others have had BSPs written but apparently never submitted (AT91SAM7X-EK
http://www.rtems.com/ml/rtems-users/2007/august/msg00161.html).

As a newbie looking to use RTEMS, I can look for a board that matches an
existing BSP or roll my own. I have found that the deletion of BSPs (instead of
moving them to a grave yard) removes a bunch of information from the pool, such
as the proper boot sequence for a processor, that I need to roll my own.

Some of the boards use a boot monitor that takes care of things like starting
the processor and doing serial datacom (MRM332 using dbug32), so the code
doesn't follow the documentation in the BSP and Device Driver Development Guide.
There is also a large deviation in the style of the various BSPs.

Granted, the guide is 1) a guide, 2) generated for a specific processor, and 3)
done by someone as a "missing manual". I would have preferred a more generic
guide with pseudocode explaining the various layers. Perhaps a style guide as well.

In the current conversation there is talk of canning a BSP because it doesn't
conform to the current interrupt structure...where do I find out about the
interrupt structure so I don't, as a newbie, generate something that will be
shunned (but I don't want to change because it works)? Given that I am making a
derivative BSP and have to make a decision between switching to RTEMS and
coughing up for uC/OS-II in about a week?

Is there anybody at OAR looking at the current crop of processors and evaluation
boards and putting together BSPs speculatively? Are they relying on the newbies
to bring in the new blood? What is being done to grow the user and processor base?

On C++:
I realize that a lot of the users are in aerospace and have big memory budgets,
but for commodity embedded stuff I follow the MISRA guidelines and all of my
memory is statically allocated. I can't afford the call system bloat with 256K
of RAM (although with that little memory, leaks are found pretty early). Also I
found that C++ has crappy syntax and lots of theoretical features that can't be
explained past some fictitious graphics package where circles and squares are
interchangeable. I'm still waiting for something better than C for embedded
work, until then I vote for C.

I don't want to make this sound like a rant or a critical flame, what you have
looks great. 

Thanks for doing this,

Andrei

------------------------------
Andrei Chichak

Systems Developer
CBF Systems
Suite 4-038
11421 Saskatchewan Drive
Edmonton, Alberta
Canada T6G 2M9
V: (780) 628-2072
F: (780) 628-5542