Information Needed

[Chris Johns]

williamssimonp at gmail.com wrote:
>  From my point of view (and I completely appreciate that this may differ
> radically from what others are looking for) I am really looking for
> documentation on the glue between the actual hardware drivers and the
> hardware abstraction layer. The README that Alan pointed me at is a
> somewhat terse, but usable example of the sort of thing I was trying to
> find and I guess that the answer to finding the rest of the information
> is going to be to search for other documentation files in the hardware
> abstraction layer part of the tree. I must confess that I had been
> looking on the internet rather than in the source tree as I hoped to
> avoid having to understand the code except where I had a specific need
> to know. It appears I was neglecting a potentially rich source of
> information.

RTEMS is a kernel and your application links to the kernel. This model 
is different to using Windows or Unix where your application operates in 
a secure isolated environment and you are not let anywhere near the 
hardware. Some types of devices have specific interfaces and map into 
the support RTEMS has. Custom hardware or configurations do not and your 
application needs to provide the support. In this case you can use 
threads, the heap or what ever else works for you.

RTEMS is an real-time kernel and an application frame work. We provide 
some high level user abstractions for things like files and file 
systems, sockets and threading, eg pthread, however the driver side is 
varied and specific to each type of hardware being interfaced. For 
example the network drivers are specific to RTEMS and use tasks. Each 
driver is defined by the architectures, buses and targets they support 
as well as the specifics of the device. With networking there is a wide 
variation. USB (when it arrives in RTEMS) is defined by the host device 
standard and the USB stack provides a mapping to those devices. There is 
no correlation between the network driver interfaces and the USB host 
driver interfaces and what you learn doing one does not necessarily 
translate to next. You need to look into the specific of each. This is 
no different with a Linux or FreeBSD kernel. Having said all this RTEMS 
could do a lot more and be better at providing documentation in this 
area. As you are finding there is not a great deal of it.

> Having said that, if there are any general design principle documents
> around this area, they would be useful, but I haven’t managed to find
> any. Something that would be very nice would be if someone could
> recommend a single, mature example BSP that could be held up as ‘a
> perfect example of how to do it right’ that I could use as a template. I
> just want to avoid redoing work that’s already been done and making
> mistakes that have already been made!

Recent ARM bsps tend to show how to shared code. I am not sure a single 
BSP can be called "golden". I do not know what that would mean. Maybe 
this is something we need to start considering and presenting in a user 
friendly way. This has been brought to my attention recently and there 
is real merit in it. If a web site listed the features supported and not 
supported you would be able to select a BSP closest. We could also 
highlight BSPs to avoid following.

> For my project, I really just need I2C and SD Card, but I’ll probably
> also have a bash at the framebuffer and basic USB so that I can attach a
> monitor and keyboard for convenience. Once I have something usable, I
> will publish them for the community to look at and use if they wish. I
> plan to publish the entire application and avionics design once it works
> as I’m sure there will be at least one other person out there interested.
> My other need is documentation for the class library.

If this is rtems++ I suggest you considering something else. These days 
templates and generic programming models provide a much cleaner 
abstraction of the threading services.

> I want to write my
> application level code in C++, personal preference, I like OO
> development for applications. I have worked some of it out and my test
> application flashes an LED using a C++ task, but mapping the C++ class
> library code onto the C Application Developers Guide is hard work!

I use C++ for applications when I can and have for a rather long time.

Chris