Re: organizing drivers and tools into the platform builder tree

Hello Dean,

I see, this is a good way for SOC or CPU specific code so that it can be
reused for different platforms.
How would you handle OAL code which is hardware independant?
Another interesting point are platform independant drivers, which can be
configured by registry entries,
or even tools. Which is the best location, public tree or 3rdparty directory
or....?
Well, my intention is to see how other people handle alls these things and
maybe to learn more about
the philosophy of Microsoft about this.

Thanks for your answers

Frank


"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> schrieb im Newsbeitrag
news:uzzHuMRVHHA.1552@xxxxxxxxxxxxxxxxxxxxxxx
The intent is that you can put your own common code into the common area
if you wish. Notice that the naming convention used there (most places
anyway) includes the chip name, vendor name, and version number. You
should be able to follow this, and not have any namespace collisions.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"F.Reither" <rr.nospam@xxxxxxxxxx> wrote in message
news:eXF7S%23LVHHA.3332@xxxxxxxxxxxxxxxxxxxxxxx
Hello everybody,

what is the best practice to organize drivers and tools into the
directory tree of the platform builder?

The big picture: During the last years we have developed BSPs and a lot
of drivers and tools for SuperH and ARM9
architectures. We have put the BSP specific code into the different
platform directories and the drivers and
tools which are board independant into an own directory into the public
tree. Even parts of the OAL code
which is common for all BSPs are located in this directory. Makefile and
batch files make sure that the correct
drivers and tools are filtered during the sysgen phase and are compiled
during the build phase according the
entries of the catalog.
The main idea was to have only one location for the source code of the
drivers and tools and in the case of
changes or bug fixes, these fixes are valid for all OSDesigns at the same
time (I know there are some disadvantages
as well. ALL OSDesigns have to be tested again).
With Windows Embedded CE 6.0 some mechanisms of the sysgen process have
slightly changed and some CPU specific
directories have been moved to the platform directory. Considering some
other disadvantages of our structure,
I'm planning to reorganize our code. Now, what is the best way to do
that. The online help and the sample BSPs
don't give concrete hints. So my questions are, is it ok to move all the
common OAL code and all the CPU specific
drivers into the common directory within the platform tree. Maybe by
creating an own "common" directory
and on own "soc" directory. Is it ok to locate everything in the public
tree or am I forced to put everything
into the "3rdparty" tree.

Thanks and best regards


Frank





.

Relevant Pages