Re: organizing drivers and tools into the platform builder tree

Hello Dean,

sorry for my late answer, I was not in the office!
Ok, I understand, it's up to me and I'm free to decide. So I'll try to find
a solution which fits
to my needs and which doesn't mix up the platform builder tree, especially
in the case of loading QFEs.

Thank you

Frank


"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> schrieb im Newsbeitrag
news:ePfH8RcVHHA.392@xxxxxxxxxxxxxxxxxxxxxxx
I don't think it really matters. The catalog supports all of these
options, so do what you wish. Some things to consider
- Platform\Common gets built all of the time
- Public only gets built on during Build and Sysgen (builddemo), which
users generally should not do. Could also be built manually
- ThirdParty doesn't get built unless you go manually build it

So put it wherever it makes sense to you.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"F.Reither" <rr.nospam@xxxxxxxxxx> wrote in message
news:OQNbExaVHHA.4404@xxxxxxxxxxxxxxxxxxxxxxx
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