Re: organizing drivers and tools into the platform builder tree

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

As an aside, thanks for describing this problem. It is a known issue and will be fixed in the next version of Platform Builder.

--
// StdDisclaimer.h
// This posting is provided "AS IS" with no warranties, and confers no rights.
//
"F.Reither" <rr.nospam@xxxxxxxxxx> wrote in message news:uTJyA6wWHHA.4860@xxxxxxxxxxxxxxxxxxxxxxx
Hello Dean,

I have spent some time to investigate the first option with WindowsCE 6.0 but I ran into some trouble.
The problem seems to be the DIRS file in the directory ...\platform\common\src\soc where I put my
own stuff. The * says, that all subdirectories have to be considered during the build process. That's working fine.
One problem is, that these subdirectories are not shown in the solution explorer. So double clicking on this
directory, opening a driver for editing and debugging is not possible. It works only if you replace this * by the
concrete subdirectory names. In this case all subdirectories are shown.
Another issue: If you leave this * (with the idea: never change MS code) and write into the catalog the source path to
one of these directories (especially mine), the platform builder crashes as soon as you double click into this source path
in the catalog items view. The same as above, by replacing the * by the concrete names everything is fine.
I didn't test what happens with breakpoints but I have seen what happens in the case of debugchecks: PB
crashes too.
Now, what am I doing wrong? What about this "*"? Or is this a bug and ...\platform\common\src\soc\... is not
an option for now?

Thanks for your patience

Frank


"F.Reither" <ttt> schrieb im Newsbeitrag news:OqESy8%23VHHA.4180@xxxxxxxxxxxxxxxxxxxxxxx
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

  • Re: organizing drivers and tools into the platform builder tree
    ... Public only gets built on during Build and Sysgen, ... Another interesting point are platform independant drivers, ... public tree or 3rdparty ...
    (microsoft.public.windowsce.platbuilder)
  • organizing drivers and tools into the platform builder tree
    ... tree of the platform builder? ... drivers and tools for SuperH and ARM9 ... We have put the BSP specific code into the different platform ... which is common for all BSPs are located in this directory. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: organizing drivers and tools into the platform builder tree
    ... tree of the platform builder? ... drivers and tools for SuperH and ARM9 ... which is common for all BSPs are located in this directory. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: legacy platform drivers and hotplugging
    ... Userspace will not code around your very personal idea of hotplug. ... My patch fixes all these issues, and make platform behave like a nice ... You disabled uevents which breaks udev and HAL setups, ... The basic problem with such legacy drivers is that they ...
    (Linux-Kernel)
  • Re: organizing drivers and tools into the platform builder tree
    ... one of these directories, the platform builder crashes as ... Another interesting point are platform independant drivers, ... public tree or 3rdparty ... which is common for all BSPs are located in this directory. ...
    (microsoft.public.windowsce.platbuilder)