Go Embedded!

KSET Pvt. Ltd. is proud to annouce Detailed Technical Training eBook for Microsoft Windows CE ( Compact Edition ) 5.0/6.0 – better known as WinCE. WinCE is Microsoft’s flagship embedded and mobile OS. We have created this training material through years of experience and actual WinCE work. This content will address lack of good quality learning material in this important technology area.

http://quest.ksetindia.com/product_info.php/Product/eBook_Embedded_Systems_Using_WinCE

Recently, I read a post on Sue Loh’s WinCE Base Team Blog. That made me realize the rationale for using shared memory has changed with the advances in Computer Architecture. Traditionally, we are taught in our OS courses that if you have to share some data between two co-operating processes, there are two options:

1. Copy the buffer from source to target process
2. Create a shared memory area that both processes have access to and use that to share information.

What most people believe is that second approach is inherently better. After all, it prevents two copies of same data from being created.

However, on closer look at modern processors, it turns out that this may not be always true. Most modern CPUs like ARM, MIPS, Hitachi SH4 and even Pentium-4 have 8-16 kBytes of “Instruction” and “Data” cache between CPU and main memory ( which typically is SRAM or DRAM ). The caches are used to hold most frequently used “Instruction”s and “Data” for executing tasks. To identify “what” is being cached, virtual addresses are used.

All these processors are used in conjunction with operating systems like Windows, Linux and embedded Operating Systems like Windows CE. When two processes will “share” some data through shared memory, each will use it’s own set of “Virtual Addresses” for that data. Since the “Level 1″ cache uses “Virtual Address” as a tag, there is no way that “Virtual Addresses” corresponding to this “Shared memory” region be “cached”, unless of course the region has same virtual address in both processes. If it is cached, the cache controller will not know that two different Virtual Addresses from two different processes refer to same area in memory. As a result these operating systems mark the shared memory region as “non cacheable” in “Page Table” of each of these processes.

Since caching affects the access time for frequently used data significantly, it’s clear that in case of shared memory access, such data access turns out to be significantly slower. The advantags of “sharing” may be easily offset of disadvantage of non-cacheability.

To summarise, it’s clear that one cannot make assumptions about performance based on theory alone. If you have performance critical systems, it is necessary for you to understand your Processor, Operating System and finally do some benchmarking to understand which approach works best in your case.

One size fits all is certainly not going to be the case!

With the launch of CE 6.0 WinCE base team has done a commendable job of exploring lot of issues regarding memory usage inside drivers. Part of it was necessary because CE 6.0 now has overlapping address space ( lower 2GB ) for each process. But some other APIs and mechanisms introduced are a marvellous demonstration of how careful one needs to be when working with memory. An article on this topic by Sue Loh is fabulous.

http://blogs.msdn.com/ce_base/archive/2006/11/09/Memory-marshalling-in-Windows-CE.aspx

For those mere mortals among you, I will be publishing series of small articles explaining virtual memory in general and CE 6.0 issues in particular. I hope you enjoy them.

Nice description of Windows CE 5.0 system call mechanics from WinCE Base Team Blog:

http://blogs.msdn.com/ce_base/archive/2006/02/02/Inside-Windows-CE-API-Calls.aspx

For quite some time I had been thinking about the Memory Architecture of WinCE 5.0 and older kernels. Most striking about it is the per process virtual address space of 32MB. This is quite unique in that it offers protection between processes but allows for all virtual addresses to be unique. This is what allows fast context switch between processes during system call and re-schedule. As all Virtual Addresses are unique one doesn’t have to flush L1 cache and TLB during a context switch. Recently when I was reading ARM v6 architecture I saw the FCSE (Fast Context Switch Extension) chapter. It was clear to me in a moment where the origins of 32MB process space limit could be. ARM MMU supports a concept of MVA (Modified Virtual Address) during address translation and this MVA is calculated by combining PID with 0 based virtual addressing scheme.

In today’s fast moving Embedded Systems world one can see that Computer Architecture and Embedded Systems are very closely related for performance reasons and a good ES designer must be savvy enough to keep track of both these worlds!

The dates have been announced. It will be launched on 1st November 2006. If you want to get it all from horse’s mouth, the virtual launch will be available at:

http://www.microsoft.com/windows/embedded/ce6launch/agenda.mspx#session_1

Do expect that all microsoft marketing and other channels will be full or this and other Windows CE related buzz.

I recently got my Phidgets kit – thanks to Microsoft. It’s really cool with every possible sensor that one can think of – RFID tags, LEDs, motor, LCD etc. etc. On top of all this folks at Phidgets have added support for Phidgets with eBox (from ICop-Tech). With this I think building projects with eBox has become much easier. To say that I am impressed with the job Phidgets team has done to enable access to their peripherals would be an understement. They have done everything from writing USB driver to writing WinCE based native library, .NET enabled it by writing Interop-wrappers – you name it and they have it. Hats off to Phidgets team for doing the whole pass. It also goes to show how dedicated and versatile one needs to be in todays Embedded Systems world. I will keep you posted on what one can do with Phidgets and eBox together.

I would strongly recommend eBox + Phidgets as a combo. for anyone building WinCE based projects. I cannot think of an easier launchpad for your next generation ES prototypes and systems!

Happy digging!

References

1. Phidgets
2. ICOP eBox
3. WinCE Driver For Phidgets

With the advent of virtualization in desktop and server computing for variety of reasons it’s imperative that embedded systems too see a growth of this approach in coming years. WinCE emulator is a virtual machine already. Only problem with it is that it’s limited in it’s functionality. We need to see more functional virtual machines for exploit full power of WinCE and development conveniences, testability and debugability that it brings along. Over the years VMWare has proven that virtual machine provides great benefits for build -> test -> debug development cycles. I am sure embedded operating system and OEMs will come up with something similar before very long.
References

1. Vmware – http://www.vmware.com/
2. Microsoft Virtual PC – http://www.microsoft.com/windows/virtualpc/default.mspx

This one is really nice XScale 520MHz PXA270 SBC with WinCE 5.0 BSP. Has one USB Host and one function, builtin LCD controller. Manufactured by Applied Data Systems:

http://www.windowsfordevices.com/news/NS5947193247.html