Re: sysgen_capture and cloning questions.

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

Thanks Michael.

You know, in using the Clone-to-Platform paradigm, I realize the benefit
with that approach is that any changes to the cloned item are part of the
BSP, so it's easy to reuse those changes over and over in new designs (the
changes to the clone become templatized in this sense, in the BSP).

If one is doing testing where the OS Design gets deleted after a test, where
the person testing will restart with something different, where the same
cloned item is needed again, the clone-to-platform works well for that. It
just happens to be a nice byproduct of doing it that way. (Not to say that
making changes to the platform aren't ever the actual reason but in my case
they didn't have to logically fit there. I'm just testing.)

Putting a cloned item in the OS Design (_PROJECTROOT) would only be
advisable, it seems, in a case where either the design itself was never going
to be zapped in that it was in itself a lasting entity, or in a case where
one doesn't really care about the cloned changes such that, once the design
is deleted, it's okay for the cloned item (and any changes to it) to get
deleted.

Regards,
Tom

"Michel Verhagen (eMVP)" wrote:

My mistake, you're right!

Tom wrote:
Hi Michael,

BSP root == platform folder == %_TARGETPLATROOT% and
OS Design = PB Workspace = %_FLATRELEASEDIR%

I get the first "BSP root" above, but on the second, don't you mean
_PROJECTROOT instead of _FLATRELEASEDR? To me, _FLATRELEASEDIR is almost
like the output of the design itself. So, very loosely speaking, one has as a
foundation _TARGETPLATROOT, which can be thought of as very
board-chipset-device specific, and on top of that, one contructs a design,
largely within _PROJECTROOT, and upon a sysgen, you produce a runtime image
in _FLATRELEASEDIR.

What do you think? Thanks again.

Regards,
Tom

This article
"Michel Verhagen [eMVP]" wrote:

Hi Tom,

You are absolutely right. There's nothing stopping you from choosing
whatever you want. The article in MSDN just shows you how to do it for
one particular case (the case where you want to modify a driver to match
a specific BSP). The naming conventions have always been a bit confusing
in Windows CE and tend to change with every version (PBWorkspaces ->
OsDesign, etc). Normally, the BSP root == platform folder ==
%_TARGETPLATROOT% and OS Design = PB Workspace = %_FLATRELEASEDIR%.



Michel Verhagen, eMVP
EmbeddedFusion
www.EmbeddedFusion.com
mverhagen at embeddedfusion dot com

Tom wrote:
In this article: http://msdn2.microsoft.com/en-us/library/Aa459163.aspx
As well as in the PB docs for sysgen_capture, it discusses modifying public
source by first copying from public to a subdirectory within %_TARGETPLATROOT%

That's confusing to me. If the driver changes are not platform-specific, but
will be used regardless of the platform, wouldn't you want those within
_PROJECTROOT?

That brings me to another question: The term "OS Design Directory" seems
confusing to me in the way it's used within the PB docs. The PB docs say,
"... From a command prompt, in your OS design directory, create two
subdirectories for the driver..."

Once again, the docs are using %_TARGETPLATROOT% yet they are referring to
an OS Design Directory as if it's one and the same. Are they? My understand
is that the platform root is where platform BSPs are located, and I'm also
under the impression (not from any docs but common sense) that one should not
mess with those unless they make a copy (i.e., because you don't want to
botch the original platform files). Additionally, the "OS Design Directory"
seems as though it would be where any one particular design of an OS would be
located. Wouldn't that be the project root under pbworkspaces? It seems that
BSP-neutral driver modifications of public sources, changes that one wants to
have apply to any targeted platform, would go within the project root, not
under the original root of one of the many possible platforms.

Thanks. I want to make mods to a public driver, and while the mod will be
used on a CEPC build, and most likely not elsewhere, it's not really tied to
CEPC. My guess is that I need to either copy to the project root as I'm
thinking, or I need to copy the platform CEPC to something like MyCEPC, and
then copy the driver files there because that's "just the way it's done."

This isn't major but I'd like to gain any clarity so I do things the right
way. Am I under the wrong impression with any of the above, and/or can anyone
clarify anything here?

Regards,
Tom


--
Michel Verhagen, eMVP
EmbeddedFusion
www.EmbeddedFusion.com
mverhagen at embeddedfusion dot com

.

Relevant Pages

  • Re: This iPhone SDK thing is a pretty big deal...
    ... An extremely capable and flexible hardware platform (with tech specs ... Great marketing and amazing industrial design. ... On top of all of this, the iPhone and the iPod Touch are, of course, ...
    (comp.sys.mac.advocacy)
  • Re: dotnet speed
    ... see performance problems at the level that abandoning the .NET platform ... The best advice I can offer on the efficiency front is: ... everyone writing your kind of program is writing in C# or VB.NET, ... either by adjusting your design or improving your code. ...
    (microsoft.public.dotnet.csharp.general)
  • Re: Lets put this to rest
    ... OO Design is a mechanism to see how the snap-shot would work at some ... Im not keen on coupling on coupling of ... platform specific design and implementation as often happens in small ... In effect I think with MDA, one is really creating a software pattern ...
    (comp.object)
  • Re: google "top coder" contest = stacked against C++ coders
    ... >> In a well design OS you do not need all that. ... C++ does not define how dynamic linking OR multithreading works or does ... > work on a very widely deployed platform: ... I am not taking this personally, but facts are facts, ...
    (comp.lang.cpp)
  • Re: google "top coder" contest = stacked against C++ coders
    ... >> In a well design OS you do not need all that. ... C++ does not define how dynamic linking OR multithreading works or does ... > work on a very widely deployed platform: ... I am not taking this personally, but facts are facts, ...
    (alt.comp.lang.learn.c-cpp)