eXP Component Documentation Sources

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm coming to the eXP world with an electronic engineers mindset.
You know the type; we want everything arranged in neat little boxes and
compartments.
Although eXP contains literally thousands of individual components, thus far
I've been unable to find any meaningful reference documentation - as books,
web resources or read-me material - that gives more than a very superficial
treatment to odd bits and pieces of componentry. It seems that one is either
born with a complete understanding of each component or one is destined to
spend ones life using "wet finger" (as in which way is the wind blowing?)
design methods.

Please tell me I'm wrong and that I'm just looking in the wrong places.

Many thanks
 
Hello Slobodan,

Many thanks for your response, it was quite helpful but I do need more.
I'd like to clarify the following;

1 I can happily handle the hardware related components using TAP, .ini
files, manufacturers doco and the like.
2 What I'm seeking is a detailed listing and functional description of
the "OS" components and how they fit into the big XP jigsaw. Maybe there is
a book out there somewhere that gets right into the bowels of XP and that
could give me the information I need
2 After checking the reviews I did order Sean's book but don't expect to
receive it for some time yet (No stocks in Oz)
3 I've clipped the complete eXP help pages/tutorials/MSDN stuff into a
(370 page) Word document because, being of the old school, I find fiddling
round with 10~20 line help pages frustrating. They are also hard to read
whilst sitting on the dunny.
4 I've also spent considerable time roaming around the web and, although
I've found an occasional diamond, there's an enormous amount of sand to sift.
5 So if I'm to avoid the "brave amateur" syndrome I need to achieve a
solid understanding of the core XP system components prior to launching my
efforts on the world. And I haven't even started thinking about testing.
Gulp!

Sorry this became so wordy

Best wishes
Argus
 
Hi Argus,

I can't imagine how you feel, since I only needed to get accustomed to the tools not the OS itself.

Basically you should know what things your target application will need like: "DirectX, Sound, Printer, Network, .NET, update way,
etc" and from this you can figure out what to add so you can have all these things.
Now when you do have them and if there are problem then you treat and solve each problem separately.

I do not know what else to say.

Regards,
Slobodan
 
Hello again Slobodan,

I guess there is a philosophical difference in so much as some of us need to
know that something works and some of us also need to know why it works.
I guess it is, in part, the difference between the software and hardware
engineering mindsets.

However, I do appreciate your assistance
Many thanks.

Argus
 
Hi Argus,
I guess there is a philosophical difference in so much as some of us need to
know that something works and some of us also need to know why it works.
I guess it is, in part, the difference between the software and hardware
engineering mindsets.
Click to expand...

For this I know how you feel. I also need to know how each piece of my hardware works and how each piece of software is working.
If you are looking for big picture here then you will need to do heavy research on system internals, drivers, services and other
cool low level stuff along with high level APIs. I do not know you level of expertise so I don't know what kind of information's do
you seek.

I'm writing firmware for microcontroller devices, and also I'm in charge for driver writing and all other low level windows
programming stuff. So I'm stuck in both hardware and software worlds.

What part of documentation do you need?
- Low level like how to write install and use drivers?
- How to use native api.
- How to program in Win32 subsystem.
- How to use .NET
- DirectX
- Network related stuff.
- Boot related information's.

XP Embedded is what you make it to be by using XPe tools. All information's relevant to OS itself are contained in various articles,
XP Pro books. DDK, IFS, various SDKs.

If you want engineer point of view on things you should forget about XPe component and look at what each component will bring into
your image.
First thing that you should look is direct files and registry entries that this component will bring to your image. Concentrate on
figuring out if this is driver, service or application like component.
Then look at other components that this component depend on and analyze them. For most files you can search trough net and news
groups so you can see what they are used for and how to use them.

Download tools from this site and read articles you will find some useful info there about XP.
http://www.systeminternals.com/

Regards,
Slobodan
 
Hello Slobodan

I believe we've made good progress.

In respect of my original question it seems that there's no one-stop-shop
for the type of information we need so we best get off our botts and start
serious sorting and reading. However, we really do appreciate your
assistance and discussion, it's helped us to define and clarify what it is we
are trying to do.

FYI, our principal strengths lie in component level electronic design. As a
result of doing this for many years this we've developed strong assembler and
C/C++ (software or firmware?) skills as appropriate to 8 and 16bit
microcontrollers. We seem to know intuitively what is happening right down
to machine level.
But also over the years we've learnt to rush in slowly hence our nervousness
as we step up to eXP
 
Hi Argus,

What is the purpose for XP Embedded usage in your company?
Do you need more powerful alternative to your current devices? Or do you want to communicate with them trough RS-232, USB, etc?

Anyhow if you want to remain in control of PC you can create minlogon image that contain few hundred components that you can easily
master and know what and how they work.
Or even better you can base your device on kernel alone and few drivers including your own driver. In this case you would have only
few components and your research would fall completely in researching driver writing.

So what is that you need to do?

Regards,
Slobodan
 
Hello Slobodan.

Thanks for the suggestions, they are very useful and will help us.

The product we are currently working on is an "interactive mobile passenger
terminal" used in the taxi industry. We've piloted 100 sets and are now
moving to manufacture.

The system uses a fanless Celeron processor, TFT LCD LVDS display, thermal
docket printer, miniPCI 802.11g slot, 100BASE-T port, GPRS data/voice
telephony communication , SSD slot, wide control range backlight controller
and a decent audio system. I guess it has a small degree of complexity.

We've designed it as two functional sections, Control and Content, to let us
remove most of the system management overhead from the processor. This
leaves the processor substantially free for our graphics-intensive
application and also lessens the propensity for management processes to
become "broken" when the application is being worked on. This has the
secondary benefit of simplifying code testing.

The Control sub-system includes all user interfaces (brightness, volume,
language and content selection buttons) plus GPRS initialisation and
management, power control, and housekeeping functions. These are managed by
a microController and firmware through an I2C bus. Because the system is
split across two mechanical modules all intermodule (I2C and serial)
communications use high speed (1M+) opto isolation to eliminate real world
nasties.

The Control and Content systems communicate through a serial port.

The Content system uses a C++ application running on eXP on the Celeron.
The application respons to passenger inputs to display a library of still
graphics and multi-media material, provide scrolling information bars,
initiate voice telephony calls, automatically synchronise content with a
server and provide useage and hardware health statistics for back-office
analysis. The application also auto updates when appropriate.

Although the eXP image we put together has now been proven to be stable in
our field testing and handles all our peripheral devices correctly, there
wasn't as much science as I would have liked so we want to refine it and more
fully understand what it's doing behind the pretty screens. (It's that
hardware engineer bit again).

I will let you know how we get on

Best wishes

Argus
 
Hi Argus,

Thanks for providing us with these info, but they were not required in such amount.

It would suffice that you said something like.
- We already made our image and program. And we do not use .NET, DirectX, Various networking services etc. Or you could tell us what
services and heavy components do you need and use.
Also do you use minlogon or winlogon?

Basically all hardware that you have mentioned can be used directly by your application trough drivers without any additional MS or
third party services programs.

If you manage to do that then you will know that you are safe. Since drivers are almost atomic units on XP systems since they either
work or do not work. If driver is working then you know that all what it required is in your image.
Only you might want to tweak some drivers behavior trough registry settings in case that it does not work as you expect it or if you
want to change its default behavior.

As long as you make your image with small amount of services you will know what it work in background since it is equal nothing.

Regards,
Slobodan
 
Hello Slobodan

I think we now have sufficient information to run with it so it's probably
time to close off. Again, many thanks for your help.

Best wishes

Argus
 
Back
Top