none
Windows CE on ARM Cortex A8 RRS feed

  • Question

  • I am a developer of glass cockpits for aircraft. Our company (MGL Avionics - www.MGLAvionics.co.za) has developed its own in house operating system and even programming language and compilers for these systems. They work fine but now we have a new project where we need to provide a general purpose operating system platform.
    We are looking at both Linux and Windows CE as candidates and currently favour Windows CE (slightly). We are quite confident that we can port our EFIS application to either operating system (even if we have to use some kind of wrapper app).
    The platform we are developing contains a Ti ARM Cortex A8 chip and thus I have a question that docs on CE so far could not answer (at least I have not found out where to look yet):

    a) Does Windows CE natively use the thumb-2 instruction set or does it use the 32 bit ARM instruction set on the Cortex A8 ?

    b) Related to (a) - Does the application natively run in ARM or Thumb-2 mode ?, i.e. on application entry is the instruction set ARM or Thumb-2 ?

    I'm sure I'll have more questions as time goes by - but that's one for starters. Anybody on this forum know ?

    Rainier

     

    Wednesday, June 16, 2010 6:59 AM

Answers

  • I understand your point about performance and feeling that you are "losing control" of your device is pretty common when you move from firmware development to an OS.

    In CE applications are not able to access hardware directly.

    You can use NEON and VPF but (as KMOS correctly said) you should consider that you are running in a multi-thread environment and so registers must be restored on context switches.

    The FP solution proposed by KMOS will use the VFPv2 floating point unit (ARM11 and A8), to use the full A8 VFPv3 floating point unit you need CE7 (Windows Embedded Compact 7, if you prefer the official name).

    My suggestion is that you should study very carefully what your OS provides in terms of features and start to "trust" its capabilities and the decide what you should re-implement for performances reasons and what you can take from the OS (carefully checking its reliability, of course!).

    Both linux and Windows CE provide a lot of source code (I know that for CE that should be a surprise... but it's the truth) and you will be able to see that in Windows CE (maybe also il linux, but I don't know it well enough!) many things are implemented in a very lightweight and reliable way, so reinventing the wheel may not be the best option.

    On the other side, CE don't put too many layers between the app and the hardware, this will make hardware access simpler than on Windows NT-based operating system. And usually simple things are more reliable and easy to modify.

     


    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Thursday, June 17, 2010 3:48 PM

All replies

  • The current version of Windows CE supports the ARMV4I architecture. Cortex A8 it's ARMv7 (ARM's naming can be even more confusing than ms one...) and currently the compiler does not use its specific features (NEON, VFP3 etc.).

    The new release of Windows CE (named Windows Embedded Compact 7) will support the ARMv7 architecture.

    Here you can find some information about the new features of this release:

    http://www.microsoft.com/windowsembedded/en-us/products/windowsce/compact7.mspx

    You can download a public beta from connect.microsoft.com.

    If your project has not a very short time frame (you plan to release your device Q2 next year, for example), you may consider using this new release for your development to be able to "unleash" all the power of your CPU core.

     


    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Wednesday, June 16, 2010 10:14 AM
  • Thank you Valter, that is a helpful answer.

    It probably does not matter much if CE does not use the added goodies on the CPU, I am planning to run it in a very minimalist way with just about everything stripped out. I really need it just to provide access to the SGX 3D graphics engine via the CE (or Linux) drivers provided by Imagine. We would not normally do this as we use GPUs natively but Imagine has a funny way of supporting their graphics engine which involves NOT telling you how to use it.

    Anyway, I presume the application would be able to run in Thumb-2 anyway (after switching to it of course) and it would access peripherals directly including NEON and VFP, it should not go through drivers - on our systems squeezing the last drop of performance out of processors is standard practise.

    Will definitely look at compact7...

    Rainier

     

     

    Wednesday, June 16, 2010 12:58 PM
  • Although CE6 still generates ARMV4I binaries (V4 instruction but with ARM/Thumb interworking) but the kernel still utilizes many V6 features, such as ASID, L2 cache and etc.
    And as the OS supports ARM/Thumb interworking, so even the whole system run in ARM mode, it can still launch and execute an application with Thumb mode instructions. Regard to NEON and VFP, as there is no native supports for these features in CE6, it fully depends on OAL to initialize and save/restore coprocessor context during context switch. The default CRT does not utilize VFP instruction until you create your own FRPCRT (for detail refer to http://msdn.microsoft.com/en-us/library/ee479873.aspx and http://evmonbeagle.codeplex.com/wikipage?title=Implementing%20CRT%20Vector%20Floating%20Point%20Support&referringTitle=Documentation)

    And if "squeezing the last drop of performance out of processors is standard practise", why do you consider to use Thumb mode? A pure ARM mode should give you maximum performance.

    Wednesday, June 16, 2010 7:25 PM
  • Although CE6 still generates ARMV4I binaries (V4 instruction but with ARM/Thumb interworking) but the kernel still utilizes many V6 features, such as ASID, L2 cache and etc.
    And as the OS supports ARM/Thumb interworking, so even the whole system run in ARM mode, it can still launch and execute an application with Thumb mode instructions. Regard to NEON and VFP, as there is no native supports for these features in CE6, it fully depends on OAL to initialize and save/restore coprocessor context during context switch. The default CRT does not utilize VFP instruction until you create your own FRPCRT (for detail refer to http://msdn.microsoft.com/en-us/library/ee479873.aspx and http://evmonbeagle.codeplex.com/wikipage?title=Implementing%20CRT%20Vector%20Floating%20Point%20Support&referringTitle=Documentation)

    And if "squeezing the last drop of performance out of processors is standard practise", why do you consider to use Thumb mode? A pure ARM mode should give you maximum performance.


    Thanks for the info.

    Regarding thumb - it's the thumb-2 instruction set that is of interest. For example it includes a native integer divide which is pretty fast so it makes sense to switch to thumb-2, do the deed and then switch back. Remember we also designed our own programming language (loosly based on Pascal for readability reasons with hardcore embedded functionality) so we use everything available. If you look at our website you will see a large screen EFIS system with an incredible array of varied communications interfaces and huge functionality. It also does full 3D terrain rendering (without a 3D graphics engine), and video overlays/underlays (infrared cameras for night flying etc) and only uses a small $6 400Mhz ARM chip (at91sam9G20 from Atmel). To make this kind of thing possible, you need high level programming right down to the core - there is no room for wasted processor cycles. Even some of the normal C compiler code is not good enough (too much overhead) - hence we started a new compiler with new ideas from scratch (we started this about 15 years ago and the compiler has developed into a very efficient code generator - but we never released this as a product as we don't want to support it - we just don't have the time. This is a pity of course).

    With our new platform (using a 1Ghz Cortex A8) we can relax a bit and allow an operating system to waste a bit of CPU time (also this chip has the 3D engine so that alone frees up a lot of CPU time).

    Our very unusual development platform and methods are partly due to the need to create bullet proof systems as this goes into real aircraft. A (software) crash is simply not an option. As we are responsible for every single byte of code and understand why it is there it makes locating even tricky bugs quick and easy. We really do every byte, compiler output, application, operating system, and device drivers including USB hosts etc. Zero third party code at this point. (yes, we are somewhat worried about moving to an operating system where the majority of code is written by others and much of it is locked away but we are keeping an open mind).

    Of course we have many concerns with this move. For example boot time. Right now, from switch on to fully operational (all databases loaded and processed, 3D terrain showing on the screen, all systems operational) is about 6 seconds. It will be a challenge, I think, to get anywhere even near that with a general purpose operating system.

    Our new system will be using the Cortex to run CE or Linux (as yet undecided) to handle the application/display/user interface itself but we are moving all the hardcore into a seperate processor to avoid the need to move all hardware access stuff into dozens of kernel mode drivers.

    Rainier

     

    Thursday, June 17, 2010 7:59 AM
  • I understand your point about performance and feeling that you are "losing control" of your device is pretty common when you move from firmware development to an OS.

    In CE applications are not able to access hardware directly.

    You can use NEON and VPF but (as KMOS correctly said) you should consider that you are running in a multi-thread environment and so registers must be restored on context switches.

    The FP solution proposed by KMOS will use the VFPv2 floating point unit (ARM11 and A8), to use the full A8 VFPv3 floating point unit you need CE7 (Windows Embedded Compact 7, if you prefer the official name).

    My suggestion is that you should study very carefully what your OS provides in terms of features and start to "trust" its capabilities and the decide what you should re-implement for performances reasons and what you can take from the OS (carefully checking its reliability, of course!).

    Both linux and Windows CE provide a lot of source code (I know that for CE that should be a surprise... but it's the truth) and you will be able to see that in Windows CE (maybe also il linux, but I don't know it well enough!) many things are implemented in a very lightweight and reliable way, so reinventing the wheel may not be the best option.

    On the other side, CE don't put too many layers between the app and the hardware, this will make hardware access simpler than on Windows NT-based operating system. And usually simple things are more reliable and easy to modify.

     


    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Thursday, June 17, 2010 3:48 PM
  • In the end what did you pick WinCE7 or Linux? Is Win10 IOT a viable option for a new project. I have troubles finding boards supporting Win 10. 
    Friday, February 24, 2017 3:45 PM
  • Ovidiu-G

    This discussion dates back to 2010, so don't expect a response from the original poster.

    Windows 10 IoT Core is available on a small number of boards, to discuss those I recommend that you look at https://social.msdn.microsoft.com/Forums/en-US/home?forum=WindowsIoT



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Tuesday, February 28, 2017 2:38 PM
    Moderator