"Snowing" news from Nürnberg ...

to all Windows Embedded developers!!! :)

and I hope that you have also nice weather like us here in Nürnberg. If not I recommend you to visit the "Christkindlesmarkt" at Nürnbergs downtown. Just have fun!
Read more! Post this to a friend!

Use previous Windows Embedded CE 6.0 Rx install for your next project

Using your previous Windows Embedded CE 6.0 Rx install for your next project should actually be a valid use case. But as a feedback from yesterdays post in this blog I got a phone call from one of my colleagues asking: "Look: Half of my development team has build problems after installing the new BSP in our new project. Any idea?"

I remembered the Peanuts comics, smiled and said: "The doctor is in! So tell me..."

Doing a blddemo -q build errors occur stating error C2677: Undefined assembler operation. The current build directory is c:\wince600\platform\common\src\soc\....blabla...

So what's happening here?

error C2677 is a MIPS Error Message. The directory above is listing the SOC (System On Chip) designs supported by all installed BSPs. Inside that directory we identified BSP support for various SOCs. These causing the problems and used in previous projects were Freescale's iMX27, iMX31, and iMX35. And these are non MIPS but ARM core SOC designs. And surely the selected MIPS assembler does not know how to handle ARM assembler operations.

So I suggested to deinstall these iMX BSPs which would surely solve the build problem. But that's not a valid solution if you still have to support the old project.

2nd proposal is to introduce some logic checking an environment variable defining the CPU or SOC (TGTCPU) selected for the current build in the C:\WINCE600\PLATFORM\COMMON\SRC\SOC\dirs until now stating to traverse all subdirectories (DIRS=*). But that's most likely causing maintenance issues on this file for upcoming BSP installs or removals that have to be solved manually even if these BSPs do not have the drawbacks from Freescales BSPs mentioned.

So how and where do other BSPs control if they are MIPS or ARM or whatever?

Well, directly in the sources files inside the subdirectories below C:\WINCE600\PLATFORM\COMMON\SRC\SOC\. Inside these sources files you can use NOMIPS16CODE=1 or identify ARM assembler sources by ARM_SOURCES= foobar.s ...

So you can add this type of control where needed in the sources files of the iMX BSPs coming from Freescale. Surprisingly this takes just a few minor changes.

Surely it would be nice if Freescale would solve these build issues directly in their BSPs to improve such compatibility issues in multi platform scenarios with different target CPU cores.

So much for project hopping from Freescale iMX (ARM core) to MIPS II FP. You mean I have not explained how this is solved in x86 or SH? Correct! I haven't... But there always has to be some magic left over. Especially at this time of the year...

-- Oliver Merkel

"Christmas waves a magic wand over this world, and behold, everything is softer and more beautiful." --N. V. Peale


Read more! Post this to a friend!

Windows Embedded CE: touch considerations part II

Hi Folks,

in my last post I talked about improving the touch driver by replacing the timer (SYSINTR_TOUCH_CHANGED) with a Sleep(). Today I want to point out another touch driver improvement.

When using the touch screen the CPU utilization increases dramatically, this of course results in a much worse system performance. After some research and some measurements you will find, that the increase in CPU utilization is mainly caused by busy waits which are used frequently throughout the touch driver (e.g. XllpOstDelayMicroSeconds() in Mainstone BSPs).

Replacing the busy waits with Sleep() will solve this problem while still keeping your touch driver responsive enough.

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

Windows CE Chat Transcript

If you were hoping to find the chat transcript from the December Windows CE Chat, I'm afraid I have to tell you that it did not take place - I wonder if the CE Team will be there next week :-)

So long and thanks for all the fish!

Read more! Post this to a friend!

CommCtrl with R3 Touch broken after QFE update (Fatal error U1077)

A while ago Jochen already posted some info on Touch Gestures feature introduced in R3. So if this is coming along with Windows CE 6.0 R3 then there must be a situation to mess up things from R2 and R3.

And here it is:

Get the R3 iso image from Microsoft download center. Nearly 1.2 GB of data. But at least if that stuff in your installation gets broken you get all data to do a repair then.

Run R3 update being an incremental install to an existing Windows CE 6.0 R2 and voilá: It's working.

Now we learned one thing: Update everything to have the latest changes available! So get the QFEs!

But be aware: This might break your R3 install. If you have already done so then each blddemo will run into the following situation. Your build.log will show a fatal error:

commctrl.lib(aygutils.obj) : warning LNK4217: locally defined symbol SHCreateDefaultGradient imported in function "public: static int __cdecl AygUtils_t::SHGradientInit(struct tagSHGRADIENT *,int,unsigned short const *)" (?SHGradientInit@AygUtils_t@@SAHPAUtagSHGRADIENT@@HPBG@Z)
commctrl.lib(aygutils.obj) : warning LNK4217: locally defined symbol SHGetSystemMetrics imported in function "public: static int __cdecl AygUtils_t::SHGradientInit(struct tagSHGRADIENT *,int,unsigned short const *)" (?SHGradientInit@AygUtils_t@@SAHPAUtagSHGRADIENT@@HPBG@Z)
commctrl.lib(lvgesture.obj) : error LNK2019: unresolved external symbol "public: static void __cdecl TouchPerf::ReleaseSession(void)" (?ReleaseSession@TouchPerf@@SAXXZ) referenced in function "public: __cdecl GestureTriggeredScrollCtrl::~GestureTriggeredScrollCtrl(void)" (??1GestureTriggeredScrollCtrl@@QAA@XZ)
commctrl.lib(lvgesture.obj) : error LNK2019: unresolved external symbol "public: static void __cdecl TouchPerf::AcquireSession(void)" (?AcquireSession@TouchPerf@@SAXXZ) referenced in function "public: __cdecl GestureTriggeredScrollCtrl::GestureTriggeredScrollCtrl(void)" (??0GestureTriggeredScrollCtrl@@QAA@XZ)
C:\WinCE600\OSDesigns\???_MIPSII_FP\cesysgen\oak\target\MIPSII_FP\debug\commctrl.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\WINCE600\sdk\bin\i386\nmake.exe' : return code '0x2'
Stop.

This one can not be resolved with turning on/off catalog item selections or something like that. The current QFEs simply break your R3 install and overwrite some files but not all being related to Touch Gesture or other R3 features.

This will most likely be fixed in the upcoming QFEs again but meanwhile just re-run the R3 rollout msi (Microsoft Installer) included in the ISO image and select repair from the corresponding menu.

Until now I did not encounter any side effects after using this R3 repair.

Unfortunately it's hard to say if the R2 tree is completely merged in R3 or if some side effect might occur. If I find some time I will check that. But most likely best way is to wait for the next QFEs to get that properly fixed.

At least the repair will allow you to continue work on R3 development that way.

Merry Christmas and Best Wishes for a happy new year, and all your R2 and R3 projects...

--- Oliver
Read more! Post this to a friend!

Switching target OS from project to project

Ho ho ho and joyous Season Greetings,

from time to time I come across the situation to help out in projects with different Operating Systems. And guess what... sometimes one of the Operating Systems is a Microsoft Windows CE / Windows Mobile / MS Auto etc. Now assume that first such a switch of the target OS from one project to the other is happening and that second it is most likely that both Operating Systems are mainly developed in C/C++.

So we have compilers, linkers and other parts of the tool chain including make tool, etc. Thus we all (including you) run into issues that the environment variables of the development host have most likely the same naming even if we switch the compilers, linkers, etc.

You probably just came across such a situation if e.g. the Visual Studio Platform Builder Plugin for Windows CE 6.0 Rx behaves like that:

Starting Build: blddemo -q

Some output in Build Output window during sysgen phase but less than expected... There were build errors and build.log just says

Starting sysgen phase for project ( common )
Found localized resources for Languages ( 0404 0407 0409 040C 0410 0411 0412 0413 0416 0419 041D 0804 0C0A)

Microsoft (R) Program Maintenance Utility Version CE-6.00.1893.0
Copyright (C) Microsoft Corporation. All rights reserved.

NMAKE : fatal error U1065: invalid option '-'
Windows CE Version (Release) (Built on Jun 30 2006 16:52:46)
Stop.

So what can possibly go wrong at that early build phase? If this is correlated to the same reason I am thinking of then this will happen in all your BSP building solutions yet.

The failure results from an nmake sysgen invoked in C:\WINCE600\PUBLIC\COMMON\CESYSGEN. Having a short look into the makefile reveals that from included cesysgen.mak the rules preproc and postproc described in makefile should be executed.

But where's this !"§$ option of that nmake error message above coming from? You never set that option?

On build console (build window) do a set MAKE. Probably you get something like:

MAKEFLAGS=-Id:/??????/target/????/usr/include

This could have been set up by other build environments and is normally or most likely not used in a Windows CE / Windows Mobile environment. If you clearly identify this to belong to some other target operating system than Windows CE / Windows Mobile and it is not used right now then remove this environment variable and run your build command again.

set MAKEFLAGS=
blddemo -q

This is most likely doing the trick...

To wish you the special gifts of this holiday season - Peace, Joy, Lasting Happiness and a working tool chain to build your favorite OS.

-- Oliver
Read more! Post this to a friend!

Windows Embedded CE touch driver consideration

Hi folks,

As you might have noticed, the Windows Embedded CE touch driver uses TWO interrupts. One interrupt (SYSINTR_TOUCH) to wait for the user to touch the screen, while the other interrupt is a timer (SYSINTR_TOUCH_CHANGED). Upon its expiration the touch driver determines if the touch is still pressed, if so the coordinates are measured and the timer is reset; if not the touch driver switches back to the first interrupt to wait for the user to press the screen.

This is a relict from Windows CE versions prior to 3.0 when the systemtick was still 20ms. Hence the systemtick was too long to be used as a timer for the touch screen.

However, this implementation sometimes leads to unexplainable behavior/errors due to the fact that interrupt events are queued differently in your system then regular events. An interrupt service thread (IST) should therefore only consist of ONE (and only ONE) WaitForSingleObject() as well as ONE (and only ONE) InterruptDone()! Unfortunately this implementation uses TWO WaitForSingleObject() calls in its IST!

On top of that, it also utilized unnecessary resources namely the extra timer.

An elegant solution would be to get rid of the extra timer and use a Sleep() in its stead:


static ULONG TouchPanelpISR(PVOID Reserved)
{

...

static BOOL fStartIST = TRUE;

...

while(!bTerminate)

{

if(CurrentDown)

{

...

Sleep(5); // use appropriate value here

}

else

{

// don't call InterruptDone the first time

// as this is done by InterruptInitialize

if (!fStartIST)

{

InterruptDone( gIntrTouch );

...

}

else

{

fStartIST = FALSE;

}

WaitForSingleObject( hTouchPanelEvent, gdwTouchIstTimeout );

}

...

}

...

}

Stay tuned for part II!

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