Thursday 31 July 2008

Certification for Windows Embedded Standard will be available soon

Hi folks,

the Windows Embedded Standard team has announced the certification exam for Windows Embedded Standard developers. There is already a certification exam for Windows CE developers(http://msdn.microsoft.com/en-us/embedded/cc294468.aspx) so this is the next logical step.
MSFT is looking for experts in device development to influence the scope and direction of this exam to make sure it is not a certification you might as well draw from a box of Kellogs Cornflakes.
If you are interessted contact the Windows Embedded Partner Team at mswepp@microsoft.com

If you are interessed in general information on the Microsoft Certification Program, then visit the following website:
http://www.microsoft.com/learning/mcp/
Read more! Post this to a friend!

Wednesday 30 July 2008

Microsoft Technical Chat on August 26, 2008

Hi Folks,

if you missed the live chat yesterday, then don't be sad. The next chance to chat with MSFT, on Windows Embedded CE and Windows Mobile is coming soon: August 26th

So don't forget to put the date in your schedule and join it.

Title: Windows Embedded CE and Windows Mobile Live Chat!
Date: Tuesday, August 26, 2008 9:00 - 10:00 A.M. Pacific time (additional time zones)

Description:
Do you have tough technical questions regarding Windows Embedded CE or Windows Mobile for which you're seeking answers? Do you want to tap into the deep knowledge of the talented Microsoft Embedded Devices Group members? If so, please join us for a live chat and bring on the questions! Windows Embedded CE is the operating system that is powering the next generation of 32-bit, small-footprint and mobile devices. This chat will cover the tools and technologies used to develop devices using the CE operating system.

To join this chat, please log on via the main MSDN chat page at:
http://www.microsoft.com/communities/chats/default.mspx

There is also an archive of previous chats available at:
http://msdn.microsoft.com/en-us/chats/aa497439.aspx

Have fun!
Read more! Post this to a friend!

Pssst ...

Microsoft hasn't officially anounced the 2008 Windows Embedded Partner Excellence Award Winners for EMEA yet, but the word has it that among the partners honored, the following can soon be gratulated:

2008 Excellence Award - EMEA:
Keith & Koep GmbH - Independent Hardware Vendor
MPC Data Limited - System Integrator
BEPS Engineering - Official Training Partner

2008 Consumer Partner Excellence Award - EMEA:

Beckhoff Automation GmbH - Independent Software Vendor

2008 Registered Partner Excellence Award - EMEA:

Wechsler Consulting GmbH & Co. KG

So long and thanks for all the fish!
Read more! Post this to a friend!

Tuesday 29 July 2008

Having trouble finding Windows Embedded CE 6.0 info in MSDN?

Well here is something Olivier posted in his Blog which will make life easier for you.

As you know Live search engine enables building macros to customize search. Try this one out:
http://search.live.com/macros/windows_embedded/ce6/?FORM=OIJG

So long and thanks for all the fish!
Read more! Post this to a friend!

Monday 28 July 2008

.NET Micro Framework V3.0 SDK Beta available

The guys from the .NET Micro Framework Team have just made the Beta for the V3.0 SDK available through the Microsoft Connect Website: http://connect.microsoft.com/netmf.

They are also giving away a RicaVision VAVE100 universal remote control (running SideShow and .NET Micro Framework) as part of the beta! So be sure to check it out!

And if you would like to see the new features, check out Jan Kučera's site.

The .NET MF SDK V3.0 is planned to ship later this calendar year.

So long and thanks for all the fish!
Read more! Post this to a friend!

Microsoft Technical Chat on July 29, 2008

Hi Folks,

MS is hosting a live chat tomorrow, July 29th, regarding Windows Embedded CE and Windows Mobile.

Title: Windows Embedded CE and Windows Mobile Live Chat!
Date: Tuesday, July 29, 2008 9:00 - 10:00 A.M. Pacific time (additional time zones)

Description:
Do you have tough technical questions regarding Windows Embedded CE or Windows Mobile for which you're seeking answers? Do you want to tap into the deep knowledge of the talented Microsoft Embedded Devices Group members? If so, please join us for a live chat and bring on the questions! Windows Embedded CE is the operating system that is powering the next generation of 32-bit, small-footprint and mobile devices. This chat will cover the tools and technologies used to develop devices using the CE operating system.

To join this chat, please log on via the main MSDN chat page at:
http://www.microsoft.com/communities/chats/default.mspx

There is also an archive of previous chats available at:
http://msdn.microsoft.com/en-us/chats/aa497439.aspx

Have fun!
Read more! Post this to a friend!

Behind the scenes of KB953311

You may think there is not alot to investigate on a simple WaitForSingleObject (W4SO) call. Millions of lines of code with this API lead us to a test coverage of 100 percent. But out of the blue it happens: W4SO doesn't do what is expected. And it's easy to prove.

If you read the description of KB953311 you may wonder what strange things a programmer must do to get into this trouble. If you read again carefully you will find out.

Any Windows CE driver contains the described code:
· You set up an event,
· You initialize an interrupt with this event
· You create an interrupt service thread
· and you wait for your event

But your event will (nearly) never be signaled, e. g. it's the power button or an overcurrent interrupt. You may wait an INFINITE timeout and everything is fine. Or you set up a timeout and check the return value of W4SO. Then you meet the first condition for this problem.
The second condition is very easy to achieve: Your system is simply at it's limits.

The online help says W4SO returns WAIT_OBJECT_0 or WAIT_TIMEOUT and you believe it. But sometimes it returns WAIT_FAILED which means invalid handle. After hours of perfect working your handle is now invalid? How long do you think you will need to find this bug?
Let's have a look at the interrupt processing.
If you call InterruptInitialize your event will be a special event which is handled in a different way. The scheduler must consider the change of the event's state after each interrupt. You have to wait with W4SO on an interrupt event, you cannot use WaitForMultipleObjects instead.

But what went wrong?
A thread with higher priority than our interrupt service thread blocks the system for more then your W4SO timeout time. This circumstances may lead your W4SO to return WAIT_FAILED and never come back to normal WAIT_TIMEOUT operation. But if you trigger the interrupt your interrupt service thread returns back to life. Microsoft was able to fix the problem with 6 lines of code.
With shared source installed we are very lucky to have the opportunity to look into the file schedule.c (WinCE500/Private/Winceos/Coreos/Nk/Kernel).
You may try to understand how the scheduler works. To be honest, it isn't trivial.
But you may use a driver and a stress test program to see the problem.
And what do we learn: There is never 100 percent test coverage, even in such a central OS component like the scheduler.

Read more! Post this to a friend!

Thursday 24 July 2008

So you've had a hard time finding a book on Windows Embedded CE, have you?

In that case I've got good news for you!

In addition to Doug Bolings book Programming Windows® Embedded CE 6.0 Developer Reference, which focuses on application development, Microsoft Press has just released Windows Embedded CE 6.0 Fundamentals by Stanislav Pavlov and Pavel Belevsky. In contrast to Doug's book, Windows Embedded CE 6.0 focuses more on BSP development.
And if that isn't enough WROX Press are planning to bring out a book in autumn: Professional Microsoft Windows Embedded CE 6.0 by Samuel Phung.

And this is what the publisher has to say:
With today’s current fast paced, unforgiving technology market, rapid application
development, fast time-to-market, manageable development risk and cost are key factors contributing to the success of any project. With its long successful track record as the leading software development tool of choice for many developers, Visual Studio has a huge existing user base and growing. By using the Visual Studio 2008 development environment, programmers can accomplish development tasks for Windows CE 6.0 projects rapidly. Existing Visual Studio developers can leverage the skills they already have and adapt them to develop applications for Windows Embedded CE in a short amount of time. Windows Embedded CE provides one of the best embedded development environments from the overall cost, risk, and time-to-market perspectives. As key companies adapt and use Windows Embedded CE as their choice of platform for product development, the need for developers with Windows Embedded CE knowledge will rapidly increase.

The primary objective for this book is to provide how-to information with working examples so developers can learn the overall Windows Embedded CE development environment quickly and effectively. This book will show how different pieces of Windows Embedded CE components come together to help programmers develop and build devices.

So long and thanks for all the fish!
Read more! Post this to a friend!

Wednesday 23 July 2008

Support of hardware variants with one BSP

Sometimes you have one BSP that has to support slightly different hardware due to adaptions for end customers. Usually, there is a globlal compiler define which is set in sources.cmn (or somewhere in sources files) and if you later add a new variant, you have to go through all those files and add the support for the new variant.

A really simple solution which only requires re-linking of executables followed by makeimg is to build variants of a library where each variant follows a defined naming scheme. And even better, for a new variant you just add the catalog feature, add the sources/makefile for the component variant and that's it.


Let's see how that could work with a concrete example:

In my case, the BSP had to support different PCI configurations because the PCI arbiter had a bug and during data transfer to a S-ATA harddisk, the USB controller on the same bus starved. Fortunately, the use cases of the device required either S-ATA or USB and not both of them at the same time (and if USB was required, too, we did not include the EHCI driver, USB1.0 still worked fine in that configuration). So, I have two variants:

  • conservative: The PCI setup is performed carefully - slow transfer rates to S-ATA HD, but reliable USB 2.0
  • optimized: In case the S-ATA transfer rate is very important and the PCI setup is tuned for that use case

The kernel has to link either the optimized or the conservative variant of the pci library. And therefore the catalog file offers the features "PCI optimized" and "PCI conservative". The features either set the environment variable PCI_CTRL_CONSERVATIVE (or don't).

Now, sources.cmn sets a makefile variable depending on that user-selected catalog feature:

!IF "$(PCI_CTRL_CONSERVATIVE)"=="1"
PCI_KERNEL_LIBRARY_SUFFIX=conservative
!ELSE
PCI_KERNEL_LIBRARY_SUFFIX=optimised
!ENDIF

The two libraries (one compiled with defines for optimised and one for conservative behaviour) are built by two source/makefile projects:

TARGETNAME=oal_pcidevicecfg_conservative
CDEFINES=$(CDEFINES) -DPCI_CTRL_CONSERVATIVE=1
SOURCES= \ ..\pcidevicecfg.c

and

TARGETNAME=oal_pcidevicecfg_optimised
SOURCES= \ ..\pcidevicecfg.c

As you can see, the file name of the library variants has an extension which is used by sources.cmn.

Now, the executable which calls functions in that library (here the kernel itself, because it configures the PCI bus during boot time) just links the library using a makefile variable:

TARGETNAME=kern
TARGETTYPE=PROGRAM
... snip ...
TARGETLIBS= $(TARGETLIBS)\
$(TARGETPATH)\oal_pcidevicecfg_$(PCI_KERNEL_LIBRARY_SUFFIX).lib


The other advantage of this mechanism is that there's not need to re-compile the whole project. Just link and run makeimg. That's all.

Read more! Post this to a friend!

Friday 18 July 2008

.NET Micro Framework 3.0 and native code

hey guys, if you're interested in news about the upcomming .NET Micro Framework release. So take a look at the following article: http://www.sdtimes.com/content/article.aspx?ArticleID=32341
And don't forget to sign up for the .NET Micro Framework newsletter. Sign up here.
Read more! Post this to a friend!

Thursday 17 July 2008

Windows CE 6.0: GWES Exception during Shell startup

To ease issue tracking in my recent projects we added resource information (short description, build number/date and a small icon) to all dlls and executables provided by us.
Formerly, we did this in a CE5.0 project and simply took over the stuff to integrate the resources also into the components of our CE6.0 BSP - never expecting that this would cause such trouble...

Unfortunately, we got an exception in GWES when the shell started up and I myself spent quite a lot time to trace down the root of the problem.

The exception occurred in the coredll function FindTypeByName (). A closer look at the function parameters and the call stack (unfortunately, most of the functions are private-private code) indicated, that there is a misinterpretation of a resource item.

K.COREDLL!FindTypeByName(unsigned long 0x00016000, unsigned long 0x00016000, const unsigned short * 0xc02b91e4)
K.COREDLL!FindType(unsigned long 0x00016000, unsigned long 0x00016000, const unsigned short * 0xc02b91e4)
K.COREDLL!DoFindResource(const info * 0x8126ab1c, const unsigned short * 0xc02b91c8, const unsigned short * 0xc02b91e4)
K.COREDLL!FindResourceW(HINSTANCE__ * 0x00400002, const unsigned short * 0xc02b91c8, const unsigned short * 0xc02b91e4)
GWES!IsForcePixelDoublingFromManifest(HINSTANCE__ * 0x00400002)
GWES!MsgQueue::NeedsPixelDoubling()
GWES!MsgQueueMgr::GetCreateMQ(unsigned long 0x00000000)
GWES!MsgQueue::SendMessageWithOptions(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490, unsigned int 0x08000002)
GWES!MsgQueue::SendNotifyMessageW_I(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
GWES!MsgQueue::SendNotifyMessageW_IW(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
K.COREDLL!SendNotifyMessageW(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
DEVMGR!BroadcastDeviceChange(unsigned short * 0xd0a0d078, int 0x00000001)
DEVMGR!DeviceNotifyThread(void * 0xc05056c0)
K.COREDLL!ThreadBaseFunc(unsigned long (void *)* 0xc04f7e68, void * 0xc05056c0)

Nevertheless, we did not know, in which executable the resource lookup failed. In a next step, we removed the resource information (strings and icons) from the oal.exe and – behold – this exception was never seen again :-}

Read more! Post this to a friend!

How to reanimate a bricked iMXS Micro Framework reference board..

..or simply how to use JTAG. In Visual Studio it’s only one click to deploy your application to the USB connected Micro Framework board. But at some point this might not work for whatever reason. Maybe you tried to update the booter or TinyCLR using FlashLiteClient or MFDeploy and something went wrong during flashing. These deployment tools need some kind of software running on the target board to talk to. But what if this software gets corrupted? How can we re-establish the factory state of the board?



Fortunately the latest iMXS Development Kit contains beside the two available booters the original binary image of the shipped sideshow application. There is also a document with the flashing instructions included: “Software Used: ARM Developer Suite V1.2, Hardware Used: ARM Multi-ICE debug unit.” This doesn't sound very cheap. And in fact you have to spend several thousand dollars to get this. But do we really need this equipment just for flashing?

The answer is No!

If you look around you will find some really low-priced JTAG adapters, which can be used to access the hardware as well. In the following we’ll use the USB JTAG debugger “ARM-USB-OCD” from Olimex (about 70$) and the software OpenOCD (it’s free like free beer).





  • First of all we have to install the drivers for the JTAG adapter and OpenOCD

  • OpenOCD needs some information about the connected device to talk to. For example what type of cpu and flash is used. This is provided by a simple configuration file. For the iMXS board it looks like this (save it as imxs.cfg):


  • #daemon configuration
    telnet_port 4444
    gdb_port 3333

    #interface
    interface ft2232
    ft2232_device_desc "Olimex OpenOCD JTAG A"
    ft2232_layout "olimex-jtag"
    ft2232_vid_pid 0x15BA 0x0003
    jtag_speed 0

    #use combined on interfaces or targets that can't set TRST/SRST separately
    reset_config trst_and_srst

    #jtag scan chain
    #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
    jtag_device 4 0x1 0xf 0xe

    #target configuration
    daemon_startup reset

    #target type endianess reset mode
    target arm9tdmi little reset_halt 0 arm920t

    working_area 0 0x09FF0000 0x4000 nobackup
    #run_and_halt_time 0 5000

    #flash configuration
    #flash bank driver base size chip_width bus_width
    flash bank cfi 0x10000000 0x800000 2 2 0


  • Now we connect the JTAG adapter with the board (check the JTAG wiring!) and run OpenOCD with our configuration file as a parameter:
    "C:\Program Files\openocd\bin\openocd-ftd2xx.exe" -f imxs.cfg



    No, that’s not an error message! Everything went well when this command window appears. There is no nice GUI and you can not even type in anything. How does it work? OpenOCD runs as a server, waiting for connections from clients like telnet or GDB. In the configuration file we specified the telnet port as 4444.

  • Let’s try to connect: telnet 127.0.0.1 4444



    As a warm up we first should try some easy commands without any risk to harm someone. For example "help". (Also take a look at the quick reference card.)

    • The command "mdb address count" displays count bytes at the specified address. The flash memory of our iMXS board starts at address 0x10000000. Let's dump the first 64 bytes:
      mdb 0x10000000 64


      (very interesting..)

    • Of course it's also possible to dump the content of the whole 8mb flash memory to a file:
      dump_image MyDump.bin 0x10000000 0x800000

    • Before we can write to the flash, we have to probe it (0 is the flash bank):
      flash probe 0




    • Some more information provides the command:
      flash info 0

    • Now we can erase the flash (bank 0, starting at sector 0, including last sector 63):
      flash erase 0 0 63

    • Again we take a look at the beginning of the flash:
      mdb 0x10000000 64



      voilá, only ffffffffffffffffff... The flash is erased.

    • To write the data, we use the command "flash write_binary bank file offset"
      flash write_binary 0 FSL_MXSdevkitImage_Flash8MB_RTM.bin 0
      (Now it's time to get some coffee, this takes some time..)

    • Finally we take again a look at the flash:
      mdb 0x10000000 64



      This looks good! There seems to be something usefull in flash and with some luck the device will be alive again :)

Read more! Post this to a friend!

Wednesday 16 July 2008

And the winners are ...

Team Trail Blazers from Singapore! Congratulations!

More about the winning Teams and the runners up of the Imagine Cup 2008 and how to participate in the Imagine Cup 2009 in Egypt can be found at http://imaginecup.com.

So long and thanks for all the fish!
Read more! Post this to a friend!

Finding the cause of a Data Abort or Crash

If you’re looking for the reason of a data abort or an exception which occurs during application execution on CE 5.0 or 6.0.
Then take a deep look into Bruce Eitman’s following blog entries (http://geekswithblogs.net/BruceEitman/archive/2008/05/19/windows-ce--finding-the-cause-of-a-data-abort.aspx and http://geekswithblogs.net/BruceEitman/archive/2008/06/02/platform-builder-find-the-source-of-a-data-abort-an.aspx).
They provide a very simple explanation about usage of MAP and COD files for crash investigation on Windows CE based systems.

Another useful source about this is the following article:
http://codeproject.com/KB/debug/mapfile.aspx

Creation of MAP files with Platform Builder depends on the value of the WINCEMAP macro in your SOURCES files. With IDE you should set the “\Fm” linker option.
For creation of COD files with PB set the environment variable WINCECOD to 1 and rebuild. When using IDE (e.g. Visual Studio) you should add the compiler option “\FAcs” or set the correct entry in the IDE (C/C++ --> Listing file type --> Assembly, Machine Code, and Source).

Read more! Post this to a friend!

Tuesday 15 July 2008

How To enable Monte Carlo Profiler on a CE 5 to CE 6 Port

For the Monte Carlo Profiler, you need to implement a Timer Interrupt Handler.
To start/stop the Monte Carlo Profiler, the Kernel calls OEMProfileTimerEnable() and OEMProfileTimerDisable(). You can find the implementation of these Functions as well as the ISR for the PXA27x platform in CE 6 under
PLATFORM\COMMON\SRC\SOC PXA27X_MS_V1\OAL\PROFILER.


WinCE600 calls the OEMXxx functions in a different way than WinCE500. This might be the cause of a problem when porting the profiler from WinCE500 to WinCE600.


On CE5 everything was built into one module: nk.exe. In CE6 this has been changed. The Kernel is split up into the Kernel code (Kernel.dll) and the OEM code (OAL.exe). The Kernel uses the structure OEMGlobal to get the addresses of the OEMXxx functions in OAL.exe. See the definition of the OEMGlobal structure in
PUBLIC\COMMON\OAK\INC\oemglobal.h. By default, the function addresses of the non optional components will be saved automatically. But optional components like OEMProfileTimerEnable() are not included in the OEMGlobal structure, so the Kernel can't call this function.


The OEMGlobal structure is accessed via the global variable g_pOemGlobal. To set the addresses for your OEMProfileTimerXx() functions set the members of OEMGlobal in your OEMInit() Function as follows:


g_pOemGlobal->pfnProfileTimerEnable = OEMProfileTimerEnable;
g_pOemGlobal->pfnProfileTimerDisable = OEMProfileTimerDisable;

Read more! Post this to a friend!

Talking about .NET Micro Framework ...

check out the .Net Micro Framework Team Blog for news on what the guys are working on for .NET MF 3.0.

Great stuff! Keep on the good work lads - which reminds me I still owe them a pint!

So long and thanks for all the fish!
Read more! Post this to a friend!

Will the future see more .NET Micro Framework?

A couple of weeks ago I was - at last - able to show off one of the smart watches we had been working on; running .NET Micro Framework. "Well, that's nothing new!", you might say.

But, how about having map data on that watch and being able to zoom in and out and move around on that map - and all of that with good graphics and good performance!

Picture this: After arriving here in Erlangen you download a map of Erlangen into your watch and that directs you directly to the "Bergkirchweih" - Assuming you visit Erlangen between May 28 and June 8, 2009.

So to answer my question: I'm absolutely sure we will see more .NET Micro Framework in the future.

So long and thanks for all the fish!
Read more! Post this to a friend!

Friday 11 July 2008

Windows CE: USB: Considerations when using EHCI and OHCI in the same image

If your device has a USB host controller with both EHCI (USB 2.0 host controller) and OHCI (USB 1.1 host controller) components (e.g. NEC 720101), communication always starts with EHCI and is handed over to OHCI if an OHCI device is detected.

Since the standard EHCI and the OHCI drivers both have the same load order in the registry, either one of them can load first. Both, EHCI and OHCI drivers have their own HubStatusChangeThread, which is responsible for detecting insertion and removal of USB devices. Normally, every attach (or detach) is handled by the EHCI driver. If the EHCI driver detects that the attached device is an OHCI device it hands it over to the OHCI driver to handle the attach.

A problem occurs when the OHCI driver loads before the EHCI driver. In that case the OHCI HubStatusChangeThread will also start first. If a device is attached to the USB host controller port before the EHCI HubStatusChangeThread is loaded, the OHCI driver will handle the attach. This behavior results in a slower boot time of the device or even a crash or freeze of the device while booting depending on whether the EHCI HubStatusChangeThread is loaded during the OHCI attach or after.

One approach to solve this dilemma is to stall the start of the OHCI HubStatusChangeThread until the EHCI HubStatusChangeThread is loaded. This can be done using a named event:

1. In the OHCI CHub::HubStatusChangeThreadStub create a named, non-signaled event and wait for that event with WaitForSingleObject right before the
return ((CHub*)context)->HubStatusChangeThread(); statement.
2. In the EHCI CHub::HubStatusChangeThreadStub create the same named, non-signaled event and signal the event with SetEvent right before the
return ((CHub*)context)->HubStatusChangeThread(); statement.


Have fun!
Read more! Post this to a friend!

tech·ed 2008 - Super Early Bird Offer

Don't forget to register on/before 31 July 2008 to qualify for the Super Early Bird Offer!
There will be a brand new Windows Embedded Track with over 22 Sessions and hey - You never know who you might meet :-)
http://www.microsoft.com/emea/teched2008/developer/registration/superearlybird.aspx
Read more! Post this to a friend!

Wednesday 9 July 2008

Windows CE QFEs for month of June 2008 arrived

The following updates for Windows CE have been recently released and are available for download. More information for each update is provided in the Readme document available after the individual update(s) has been installed.

Windows CE 5.0Update name: Windows CE 5.0 Platform Builder Monthly Update (June 2008)
Download link: http://www.microsoft.com/downloads/details.aspx?FamilyId=048D6D61-7D69-4E72-93EF-DEA63D28DF42&displaylang=en
Description: This is a set of updates for Windows CE Platform Builder released during the period of June 1 – June 30, 2008.
These Microsoft Windows CE updates are fixes for Windows CE operating system problems you run into during the development and maintenance of your custom platform.

Windows CE 6.0Update name: Windows CE 6.0 Platform Builder Monthly Update (June 2008)
Download link: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF595F00-FAE0-4537-A074-1DE3C2C01EF1&displaylang=en
Description: This is a set of updates for Windows CE Platform Builder released during the period of June 1 – June 30, 2008.
These Microsoft Windows CE updates are fixes for Windows CE operating system problems you run into during the development and maintenance of your custom platform.
Read more! Post this to a friend!

Tuesday 8 July 2008

Introduction

Hi folks,

we - a team of engineers working with Windows Embedded Technologies - want to give you useful information and the latest news on Windows Embedded.

Discover the Windows Embedded experience!

If you have any questions or feedback you can reach us here: embedded-experience at gmx dot de

Ihre Fragen können Sie natürlich gerne auch in Deutsch an uns schicken.

So long and thanks for all the fish!
Read more! Post this to a friend!

Company Info - AUG Electronics







To find out more about AUG Electronics simply follow the link and don't forget to come back to discover more of the Windows Embedded Experience:

http://www.aug-electronics.com/

Read more! Post this to a friend!

Company Info - EB (Elektrobit)

EB is a Windows Embedded Gold Partner, with more than 12 years hands-on experience with Windows Embedded Technologies, in the categories:
  • System Integrator
  • Independent Software Vendor
  • Training Partner
EB offers a wide range of services, trainings and software for all Microsoft Embedded Operating Systems:
  • Windows Embedded Compact (formerly known as Windows Embedded CE)
  • Windows Embedded NavReady
  • Windows Embedded Standard (formerly known as Windows XP Embedded)
  • Windows Embedded PosReady
  • Microsoft Auto
  • Windows for Automotive
  • Windows Mobile

To find out more about EB simply follow the link and don't forget to come back to discover more of the Windows Embedded Experience:

http://www.elektrobit.com
Read more! Post this to a friend!

Company Info: Avnet Embedded

Avnet Embedded is Europe's leading Microsoft Windows Embedded distributor. Avnet Embedded can place a team of very well trained engineers at your disposal. Avnet Embedded's task is to determine the best Microsoft Windows Embedded operating system for your application. Thus, with a broad product range, extensive service and high professional competence, Avnet Embedded can help you get your developments more quickly to market.

To find out more about Avnet Embedded simply follow the link and don't forget to come back to discover more of the Windows Embedded Experience:

http://www.msembedded.biz
Read more! Post this to a friend!

Monday 7 July 2008

About time too ...

I've been boasting this BLOG quite a lot in the past and now here it is - at last!


The team hopes you will find lots of interesting information around Windows Embedded.
Read more! Post this to a friend!