Tuesday 31 August 2010

TechED Europe 2010 talks accepted!

Hi folks,

thanks for voting for our submissions for TechED Europe 2010 from November 8th to 12th in Berlin, Germany. Your wishes will be granted: I will hold both these talks at this years TechEd Europe:

Advanced Application debugging techniques with Windows Embedded Compact 7

as well as

Windows Embedded Automotive 7 – Creating Next Generation User Experiences (UXs)



I will post an update as soon as I have further information about when and where these talks will take place. So stay tuned!

See you in Berlin!

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

Thursday 26 August 2010

SWE und EB GUIDE Artikel

Hallo zusammen,

In der aktuellen Ausgabe der Automobil Elektronik ist ein von meinem Kollegen Jan Babst und mir geschriebener Artikel über Silverlight for Windows Embedded unter EB GUIDE Studio: "Mit Silverlight und Guide Studio zur intuitiven Bedienung" erschienen.


Viel Spaß beim lesen!
Read more! Post this to a friend!

SWE under Windows Embedded Compact Webcast

Hi folks,

If you are looking for a Silverlight for Windows Embedded under the Windows Embedded Compact 7 PCTP video tutorial; here you go:

Silverlight for Windows Embedded under Windows Embedded Compact 7 - Part 1



Silverlight for Windows Embedded under Windows Embedded Compact 7 - Part 2



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

Deutsche Windows Embedded Compact 7 und Windows Embedded CE 6.0 R3 Webcasts

Hallo zusammen,

Sie sind auf der Suche nach Windows Embedded Compact 7, Silverlight for Windows Embedded oder Windows Embedded CE 6.0 R3 Video Tutorials? Dann habe ich das richtige für Sie:

Ich habe zwei Webcast aufgenommen, schauen Sie doch einfach mal rein!

Was ist neu in Windows Embedded CE 6.0 R3 – Teil 1



Was ist neu in Windows Embedded CE 6.0 R3 – Teil 2



Silverlight for Windows Embedded unter Windows Embedded Compact 7 - Teil 1



Silverlight for Windows Embedded unter Windows Embedded Compact 7 - Teil 2



Viel Spaß dabei!
Read more! Post this to a friend!

Tuesday 24 August 2010

MARK YOUR CALENDARS: Windows Embedded Compact (Windows CE) Live Chat!

Hi guys,

Microsoft is hosting a live chat about Windows Embedded Compact next week. Do you have tough technical questions regarding Windows CE for which you're seeking answers? Then join the upcomming live chat with the Microsoft guys! And we hope, that the technical problems at the last chat are solved already.

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

Title: Windows Embedded Compact Live Chat!
Date: Tuesday, August 31, 2010 18:00 - 19:00 CET

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

Have fun!


Read more! Post this to a friend!

Thursday 19 August 2010

Ariadne's thread in the labyrinth of PCI

Do you ever setup a BSP with PCI support? It should be easy enough because all you need is there, however it is spread across your entire C:\WinCE600 folder. But what are the parts you may use without changes, what libraries must be included and what is hardware-specific and must be adapted?

You may start with the PciBus.dll. But there is nothing hardware-specific, that’s the wrong end of the thread.
There is a PCI library in the production-quality OAL (PQOAL) model, maybe that’s the right point to start. But the online help says this:

“Implements PCI bus support in the kernel. It also implements simple PCI bus configuration functions intended to be used for boot loader and KITL.”

No, it’s no KITL we want to setup. But anywhere between PciBus.dll and PQOAL must be a hardware-specific part, which must be ported to our PCI host controller.


Let’s start with some basics.
The PCI bus provides three address spaces: Config-Space, Memory-Space and IO-Space. Each PCI device “shows” its internal registers or memory in up to six so-called BARs. These BARs are in Memory or IO Space. It is common usage to iterate all buses and devices to find a specific controller on the PCI bus. Under Windows CE it’s better to implement a bus-agnostic driver calling DDKReg_GetWindowInfo(), but that’s another story.
Memory-Space and IO-Space are ordinary address spaces you may access with e.g. VirtualCopy(). The access to the Config-Space could be different: memory mapped or via special registers. As a result we need some special routines to read or write the Config-Space.

Let’s go back to the PciBus.dll:
During initialization of the PCI bus the driver reads the config space of each device and each function by calling HalGetBusData():

PCIBus.c:
Init()
Enumerate()

PCIcfg.c
PCICfg()
PCICfgBus()
/*...*/
// Loop through all device numbers
for (Device = 0; Device < PCI_MAX_DEVICES; Device++) {
SlotNumber.u.bits.DeviceNumber = Device;

// Loop through all functions
for (Function = 0; Function < PCI_MAX_FUNCTION; Function++) {
Cfg.VendorID = PCI_INVALID_VENDORID;
Cfg.DeviceID = PCI_INVALID_DEVICEID;
Cfg.HeaderType = PCI_DEVICE_TYPE;

SlotNumber.u.bits.FunctionNumber = Function;

// Read device's configuration header (except for device-specific information)
Length = HalGetBusData(PCIConfiguration, Bus, SlotNumber.u.AsULONG, &Cfg, sizeof(Cfg) - sizeof(Cfg.DeviceSpecific));

HalGetBusData() is implemented in the CeDDK:


CeDDK.h:
HalGetBusData()
CeDDK/DDK_Bus/Data.c:
HalGetBusDataByOffset()
KernelIoControl(IOCTL_HAL_DDK_CALL, ¶ms, sizeof(params), NULL, 0, &outSize);

The KernelIOCtrl takes us to the kernel:

ioctl.c from the OAL_IO_PCI.lib (Platform/Common/Src/Common/IO)
OALIoCtlHalDdkCall() implements the IOCTL_HAL_DDK_CALL
/*...*/
case IOCTL_OAL_READBUSDATA:
pParams = (OAL_DDK_PARAMS*)pInpBuffer;
pParams->rc = OALIoReadBusData(
&pParams->busData.devLoc, pParams->busData.offset,
pParams->busData.length , pParams->busData.pBuffer
);

data.c from the OAL_IO_PCI.lib (Platform/Common/Src/Common/IO)
OALIoReadBusData()
/*...*/
case PCIBus:
rc = OALPCICfgRead(
pDevLoc->BusNumber, *(OAL_PCI_LOCATION*)&pDevLoc->LogicalLoc,
address, size, pData
);

And here is the call to OALPCICfgRead():

PCI.c in your OAL:
UINT32 OALPCICfgRead(UINT32 busId, OAL_PCI_LOCATION pciLoc, UINT32 offset, UINT32 size, VOID *pData)

Well, this was the implementation for a “normal” CPU. As usual x86 is different:

ioctl.c from the OAL_IO_x86.lib (Platform/Common/Src/x86/Common/IO)
x86IoCtlHalDdkCall() implements the IOCTL_HAL_DDK_CALL
/*...*/
else if (nInBufSize == sizeof(BUSDATA_PARMS)) {
/*...*/
case IOCTL_HAL_GETBUSDATA:
pbd->ReturnCode = OEMGetBusDataByOffset(
((PBUSDATA_PARMS)lpInBuf)->BusDataType,
((PBUSDATA_PARMS)lpInBuf)->BusNumber,
((PBUSDATA_PARMS)lpInBuf)->SlotNumber,
((PBUSDATA_PARMS)lpInBuf)->Buffer,
((PBUSDATA_PARMS)lpInBuf)->Offset,
((PBUSDATA_PARMS)lpInBuf)->Length
);
break;
/*...*/
}
} else if (nInBufSize == sizeof(OAL_DDK_PARAMS)) {
/*...*/
case IOCTL_OAL_READBUSDATA:
pParams->rc = PCIReadBusData (bus, device, function, pParams->busData.pBuffer, offset, size);
break;


OEMGetBusDataByOffset()
/*...*/
case PCIConfiguration:
return(PCIGetBusDataByOffset(BusNumber, SlotNumber, Buffer, Offset, Length));

PCI.c (Platform/Common/Src/x86/Common/IO)
PCIGetBusDataByOffset()
PCIReadBusData()



Summery:
The key feature to access the PCI bus in your BSP is a good implementation of OALPCICfgRead() and OALPCICfgWrite().
And what about the KITL and PCI?
Well, KITL is an extra DLL and has no direct access to the OAL. That’s why KITL implements it’s own versions of OALPCICfgRead() and OALPCICfgWrite(). These implementations call the KernelIOCtl(IOCTL_HAL_DDK_CALL).

That’s a lot of grepping work to find out how PCI works. I hope to be your Ariadne's thread if you ever have to fix a PCI problem below PciBus.dll.

Tschüß Holger

Read more! Post this to a friend!

Monday 16 August 2010

Windows Embedded Compact 7 PCTP: Download link fixed

Hi folks,

I stated in my previous post, that the download link for the Windows Embedded Compact 7 (WEC7) PCTP on Connect was incorrect.

Well the WEC7 download link is fixed now!


Oh, and if you have connections issues when using the WEC7 Virtual PC BSP, check out Olivier’s post!

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

Thursday 12 August 2010

Kernel-Mode and User-Mode DLLs

The new memory architecture in Windows CE 6.0 leads us to two types of DLLs: Kernel-Mode DLLs and User-Mode DLLs. We put a Kernel-Mode DLL in the MODULES section of our BIB-File and mark it with a K:

MODULES

MyDll.dll $(_FLATRELEASEDIR)\MyDll.dll NK SK

If we want to use the DLL in both Kernel- and User-Mode we replace the K with a Q:

MODULES

MyDll.dll $(_FLATRELEASEDIR)\MyDll.dll NK SQ

MakeImg creates a copy of our DLL named K.MyDll.dll. Each version of the DLL will relocated to the corresponding XIP section in User-Space and in Kernel-Space.

Up to this point the facts are easy and every BSP developer should know about it.

Now it starts to be tricky:

What about LoadLibrary()? What happens if I try to call LoadLibrary(L”MyDll.dll”); from a driver in the Kernel context?

The answer is: LoadLibrary() loads K.MyDll.dll, you don’t have to add a “K.”!

But what if the DLL needs another DLL, e.g. My2ndDll.dll?

It is obvious that My2ndDll.dll must be also a Kernel-Mode DLL, but the name mustn’t be K.My2ndDll.dll.

Alternatively you may move My2ndDll.dll from the MODULES section to the FILES section. Remember to remove any K or Q!

MakeImg cannot resolve all dependencies in this situation:

Warning: Unable to do imports from K.MyDll.dll to My2ndDll.dll - will late bind

But if My2ndDll.dll is on your target, K.MyDll.dll will be loaded successfully.

It’s a good idea to review all DLL dependencies and think about the special functionalities of your DLLs. Some DLLs do kernel-specific things and cannot run in User-Mode, e.g. read from KSeg1 addresses. Some DLLs use application interfaces you won’t move to the Kernel, e.g. MFC or OleAut32.

Tschüß Holger


Read more! Post this to a friend!

Windows Embedded CE QFEs for July 2010 have arrived!

Hi all,
new updates for Windows Embedded CE are available for download. Some issues (especially the scheduler fix for Windows CE 6.0) have been resolved, no time to loose and get them now! More information for each update is provided in the Readme document available after the individual update(s) has been installed.

Windows Embedded CE 5.0 Monthly Update July 2010:

Fixes made in this update:

Component:  Internet Explorer

Windows Embedded CE 6.0 Monthly Update July 2010:

Fixes made in this update:

Component:  COMM

Component:  Internet Explorer

Component:  IPSec

  • 100727_KB2252004 - This update addresses a few thread leaks in udevice.exe system process.

Component:  MSFlash

  • 100722_KB2263918 - The block may get marked as bad block during CompactDataBlock process.

  • 100731_KB2289488 - During stress tests the device could get into a state where the critical compaction loop runs during boot initialization of the Flash MDD. This may prevent the device from booting.

Component:  .NET CF v3.5

  • Remote Performance Monitor crash when attempting to get GC Heap snapshot

  • RPM may show exception message "Error displaying GC heap view: The given key was not present in the dictionary"

  • TRemote Performance Monitor crash when attempting to get GC Heap snapshot

  • Deserialization incorrectly succeeds on bad XML creating bad objects

  • Data passed to Serializer is serialized twice

  • Unable to obtain information when PInvoked code or CLR generates an exception

Component:  Scheduler

  • 100723_KB2267739 - Co-processor registers may get restored in the wrong thread.

Component:  TimeSVC

Component:  USB 2.0

  • 100722_KB2193954 - This update adds missing curly brackets in CIsochronousPipe::AddTransfer.

Keep your OS up to date!


Read more! Post this to a friend!

Tuesday 10 August 2010

Programming Windows Phone 7

Hello guys,

it should be quite interesting for all Windows Phone7 developers. The second draft preview of Charles Petzold’s upcoming Programming Windows Phone 7 ebook including several code examples is available to download :)

Image1

The final version of this ebook will be available in october and will be free!

Have fun!


Read more! Post this to a friend!

Thursday 5 August 2010

Missing extern "C"

I'm sure most of us hit the problem of that annoying linker error "unresolved external symbol "aoein0hepqo2washpeofh a@foo" (ok, I just hammered the keyboard - it's no real live symbol name!).
After triple-checking the library link list it turns out that (again) the mixing of C and C++ modules and libraries is the root of the problem.

But what to do if you have a C++ module that references an API function declared in a header file that is not prepared to be included by C++ code?

If you are not allowed to patch the file (may be its 3rd party stuff) there is a quite simple solution:

extern "C"
{
#include
}

Cheers,
Jürgen
Read more! Post this to a friend!

Monday 2 August 2010

Cool stuff – new Windows CE based devices from METTLER TOLEDO

Hello guys,

METTLER TOLEDO is a global manufacturer and marketer of precision instruments for laboratory, industrial and food retailing applications and launched a new generation of density meters and refractometers.

MT hired EB as a software partner to strengthen its own software team thereby utilizing EB architecture, design and software project management expertise. MT and EB jointly created a complex software solution that integrated 250 screens in 40 different device combinations on a Windows Embedded CE platform. The solution reused parts, such as the user interface concept and basic software design of a previous project for titration devices and used EB GUIDE Studio as HMI tool.

Check out the video below, which shows you the huge range of possibilities of the new devices:

Have fun!


Read more! Post this to a friend!