Porting Embedded Windows CE 6.0 R2 to the OMAP-L138: Part 3 - Embedded.com

Porting Embedded Windows CE 6.0 R2 to the OMAP-L138: Part 3

The authors discuss how to take full advantage of the Microsoft Windows CE 6.0 board support package in this final part in a series of three articles on how they ported the Windows CE 6.0 R2 embedded operating system to the Texas Instruments ARM-based family of OMAP-L138 processors.

Part 3: Using the Windows 6.0 Board Support Package

The standard board Windows CE 6.0 board support package (BSP) for the OMAP-L138 SoC (discussed in detail in Part 1 and Part 2) does not include the DSPLink library. In complex DSP operations where it is necessary to link to the library, the developer needs to modify the mDDR/DDR2 random access memory normally used for data storage, so programs can access the library when needed.

This RAM is normally used for Windows CE 6.0 OS for operation of applications, services, drivers, and the ARM processor core . To give the developer as much flexibility as possible this memory needs to be segmented into several partitions, one available only to the ARM core and Windows CE 6.0 OS, another segment available only for DSP core and a third area available to both cores and for the DSPLinklibrary.

Figure 10 shows distribution of RAM DDR memory when using DSPLink. Windows CE 6.0 OS uses 24-Mbyte RAM for applications, drivers, and services where an additional 63 Mbyte RAM has been assigned from from one of the other partitions for use by Windows CE 6.0 OS.


Click on image to enlarge.

Figure 10: Distribution of memory in Windows CE 6.0 when DSPLink library is used

2 Mbytes of RAM have been allocated for the DSPLink library. If this is not enough, then it is necessary to change the memory configuration in the Windows CE 6.0 BSP, which will decrease the RAM area (63 Mbytes for applications). Apart from this, the BSP configuration files need to be corrected, as Windows CE 6.0 OS requires execution of an OEMGetExtensionDRAM subroutine for notifying the OS of additional areas of RAM.

Special attention needs to be paid to the process of assembly and integration of the library into the Windows CE 6.0 image. The library itself consists of five components:

  1. Code Generation Tool C6000;
  2. DSP/BIOS;
  3. Windows CE 6.0 (including installed Platform Builder + Visual Studio);
  4. Windows CE BSP for OMAP-L138; and
  5. ActiveState Perl

All these components are required for simplification and, in most cases, abstraction of the assembly code generated by Code Composer Studio. Assembly of the DSPLink library is not complicated but it does require some time and attention during configuration. After successful assembly, the resulting files are transferred to the BSP. Additional settings are not required – it is enough to add a component from the package of DSPLink source codes into the Windows CE 6.0 OS working project.

It is also possible to make use of the OMAP‘s DSP capabilities in applications using Windows CE 6.0 OS without necessarily using TI‘s DSP/BIOS or the DSPLink library. However, this often requires solving a number of problems related to the distribution of sections of a DSP application,such as making sure the correct address of the input point is communicated in order to start a DSP operation. In our experience there are quite a few of these.

The problem is that the exchange between ARM and DSP subsystems needs to be arranged independently, as does loading and starting DSP code. In the implementation used in our projects at Axonim, the OAL has been modified for use in the BSP OMAP-L138 for Windows CE 6.0, where it can be implemented in combination with a tool for complete DSP core manipulation. This, in turn, allows implementation of communications algorithms that do not normally work in combination with the DSPLinklibrary.

Developers experienced in programming with TI‘s C6000 DSPs would find such an approach more reasonable as it would significantly reduce the time they would have to allocate to this issue.

Debugging applications for DSP
If the developer of an application for DSP has an opportunity to use JTAG and the Code Composer Studio environment, then the debugging process is simple. In the core selection window for debugging, the DSP core can be selected and the debugger can be connected to it without stopping the ARM subsystem. As a result, when Windows CE 6.0 OS is operating, simultaneous debugging of algorithms can take place with the help of both JTAG and Code Composer Studio.

But if code debugging is performed without JTAG and Code Composer Studio, the task becomes more complicated as some nonstandard methods will be needed. For example, you may need to add control points to the program in order to display the state of the DSP core in particular memory cells. There are a number of such methods, and the choice depends on how complex the implementation is and the debugging results you wish to obtain..


Encoding and decoding of video
When using the H.264, MPEG4and audio (MP3, AAC) codecs provided by TI in combination with WindowsCE 6.0 OS, the company offers a new package with source codes to supportDirect Show filters for Windows Media Player.

Figure 11 shows the sequence of calls when using DVSDK 1.00.00.05 WinCE package.When using Direct Show filters, it is necessary to use an intermediatelayer for connection of Direct Show filter and the VISA API (Video,Image, Speech, Audio), which further uses codecs at the DSP subsystemvia Codec Engine library. The TIMM.DLL dynamic library operates as thisintermediate layer, generating primitive elements for working with videoand audio flows.


Click on image to enlarge.

Figure 11. Sequence of calls when using codecs in DSP subsystem for Windows Media Player

Thestandard DVSD K WinCE 1.00.00.xx package does not contain source codefor the OMAP-L138 SoC. For implementation of OMAP projects, we portedthe source codes from the DVSD K 4.02 package for Linux Embedded OS(which supports the GStreamer framework for codecs where a DSP core hasbeen used) and combined it with the DVSD K WinCE 1.00.00.05 package.This is necessary only for the OMAP3530 SoC, though the option of addingnew platforms is reserved. Any remake operations take time and require acomprehensive setting of all components (Codec Server, Codec Engine,DSPLink, DS How Filter, and Windows CE 6.0 OS itself).

However,at Axionim we’ve managed to initialize decoding of the AVI container -which contains video flow – with a resolution of 720х576 (MPEG4) and MP3audio data. The resulting reproduction rate is 30 frames per secondwith an ARM core load of about 30% (network reproduction of video).

Anotherway to use codecs on the DSP subsystem side is to use the DVSD Kpackage and develop your own customized application, a much more commondesign option when using the Windows Direct Show and Windows MediaPlayer components. As for AVI containers, the analyzer needs to bewritten independently and ported from projects with an open code.Confined to just the encoding of the video flow obtained from videoinput (VPIF), this method is much more beneficial from the point of viewof resources exploitation.

Figure 12 shows the sequenceof system calls during development of the application using the DVSDKpackage. With such an approach, the development of an applicationincludes preparation of the libaries for the DMAI (Digital MultimediaApplication Interface), Codec Engine, and DSPlink as well as for acodecs container. Using examples presented in DMAI library(video_encode_io1, video_ decode_io2, audio_decode_io1, etc.), thedeveloper can generate applications to which all the static componentsneeded for operation of these examples can be attached. Thus,unification of the interaction interface with the DSP subsystem andcodecs container is possible.

The codecs container includescompletely operational codec libraries from TI in binary form. However,the developer also has the option of adding his or her own codecs to thecontainer, using the unified VISA interface to access them.


Click on image to enlarge.

Figure 12. Sequence of calls when using codecs in DSP subsystem during user application development

Testing of ARM core with Embedded Windows CE 6.0
Imagetesting using the standard board support packages has been performedindependently by MPC Data Company and is presented in the form of Exceltables in appendix to the BSP that MPC provides (Figure 13 ). Testing was performed using a LogicPD OMAP-L138 SOM-M1 module.


Click on image to enlarge.

Figure 13: Whetstone performance test

Thismodule uses 166-MHz mDDR memory for 128 Mbytes, though it is possibleto use DDR 2 memory up to 512 Mbytes in size, which significantlyimproves performance. In these tests, using the Marvell PXA270, TIOMAP-L138 and Cirrus Logic EP9315 processors Windows CE 6.0 R2 OS wasoperating but additional libraries of floating point functions supportwere not used.

Conclusion
The ARM926EJ-S core isuseful in applications of moderate performance with frequencies of up to456 MHz operating independently, and up to 300 MHz when equipped with aperipherals set (such as a SATA, module for working with SD/MMC-cards)and used with McASP, McBSP, and additional DSP cores.

Based on our experiences using it in the design of a matrix RGB LED display controller (Figure 14 ),we believe the OMAP-L138 can be used as a basic core not only in mobileapplications but in traditional fixed systems where it is necessary toresolve a wide range of tasks connected with reproduction and storage ofmedia content.


Click on image to enlarge.

Figure 14: LED display controller based on OMAP-L138 with Windows CE 6.0 and Xilinx Spartan6 FPGA

TheLED display controller was based on the TI OMAP-L138 SoC and the XilinxSpartan6 FPGA as video controller. We used Windows Embedded CE 6.0 R3as the main OS to receive MPEG2/4/H.264 video streams over Ethernet/3G,then decode them and display on an LED screen.

We think themethodology we followed with the OMAP-L138 SoC and C6-Integra familywill allow development of systems that can easily be integrated intomany medical equipment and factory automation processes.

To read Part 1, go to “The basics of the two platforms”
To read Part 2, go to “The OMAP Programmable Real Time Unit .”

Artsiom Staliarou
and Denis Mihaevich are founders of the AXONIM Devices Company, a Microsoft EmbeddedPartner and independent embedded electronics system design center and systemintegrator with 25 engineers based in Minsk, Belarus. E-mail: , Skype: axonim.by.

Artsiom has a degree in radiophysics and has more than 10 years of experience in embedded system design based on ARM/Blackfin/TI DSP C2x/C5x/C6x)/x86 devices and using Embedded Linux/Windows EmbeddedOSes.

Denis also has a degree in radiophysics and more than 12 years ofexperience in embedded system design and video analysis algorithm development, and has a certificate in optoelectronics.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.