KVM is nothing but a generic application on VxWorks. The simplest way to develop a software for VX (VxWorks) is using Tornado IDE. WindRiver provides a API level software emulator to save your time to develop a software for VX. You can develop KVM on emulator then port to VX device. For experience, you can add a library project for your Tornado project then add all your VM code into this porject. After this, just rewrite everything that cannot be run on VX.
For my experience, you have to redesign your VM file system, memory management, graphics management, multimedia control system, AMS and JAM. These sub-systems for VM are not portable. Some of them need to be rewrite and others maybe just change some part of them.
File System :
VX provides ANSI-C 's file api function. You can just use these functions and don't have to redesign your file system. The file system for VX is DOSFS. DOSFS can control your flash device drive so that you don't have to worry about driver layer issue. I suggest you to write your storage management system because RI provides a bad way to manage your RMS. My method is creating a huge file and access from this big file. You must know embedded system is not similar to generic OS environment. Static is better than dynamic.
Memory Mangement :
VX has its own memory management. I don't mean MALLOC or NEW funciton for C Runtime Library (CRT). VX provides heap management. You can create a indepedent heap (separate heap block) so that you will not fragement your system heap. You have to know VM is GC based system. Allocation and free is always happening. But it's pity that VX's heap allocation is a one way fucntion. Once you create a heap and this heap is never freed until system is reset. You must evaluate your system resouce if a fixed heap is allowed. If a special heap for VM only is not allowed, I suggest you must free all resource of VM if VM is out foreground software.
Graphics System :
WindRiver has designed a library call "WINDML". It can provide a 2D graphics management. You can do Windowing, keyboard inputing, bitmap drawing and JPEG encode and decode. We can write VM's LCDUI functions by WindML graphic API. Graphics management of WindML is similar to Win32 GDI. It provides a GC ( DC on Win32) and all of graphics resource is assoicated with the graphics context. I suggest you to save this context to VM's instance object. Ecah time the JAVA level request a LCDUI function then you can retrieve this context from instance object. After you get this context, you can do drawing or setup for this GC. The challenge for graphics management is "How to limite graphics resource usage?" As we know, bitmaps will consume lots of memory to save all of pixels information. If a JAVA application is using too much graphics resource, it maybe cause a big problem. A critical application, for example, phone caller, may not run properly because there is no more free memory to run this program. This is very dangerous for embedded system. I suggest you have to keep track all of graphics generation so that you can know if it's out of memory boundary. I write a simple LINK LIST struture to keep all of grahpics allocation information so that I have if there is enough memory resource to create a new bitmap. If I find system don't have enough resource, I will call VM's GC to free garbage and try to create it again. If we still cannot get enough resource, just return out of memory exception.
Multimedia :
Multimedia is very platform dependent. In general, all of code for multimedia must rewrite and resign. You may use your DSP on your SOC or a special hardware CODEC to play a tone, wave and midi message. J2ME has many JSR defintions about multimedia (or hardware). Before you start to develop a hardware related function for VM, you can find if there is a related JSR for this device. For example, bluetooth device, obex exchange, com port mapping, GPS, SIP, PIM access and so on. For MIDP 2.0, you need port WAVE, MIDI and TONE playback. I just you write a simple JAVA layer player to play all of these multimedia resource and not to use RI's player. RI just uses JAVA software to process too many thing. For PC this kind of implementation is good and simple but for embedded system, we can not do the same thing. We don't have a powerful CPU so that we have to move complex computing to native layer.
Speed Up your VM:
There are many methods to speed up your VM performance. You can adjust task priority to share more cpu time for VM (If this is allowed). You can rewrite VM core implementation in assembly language. You can use JIT compiler technique to compiler JAVA byte code to native code. You can use threading technique to imporve your VM speed, for example, Direct Threading.
|
