Patent Application
20050060378
This invention relates in general to the field of electronics and more specifically to a method and apparatus for providing language modularization in an electronic device.
Embedded software products and operating systems face a variety of challenges when being designed for use with multiple languages. The performance and memory resource constraints demanded by these embedded products often force software designers to know up-front which languages (e.g., French, English, etc.) will be supported by a particular product. In prior art designs, specific language translations are designated at compile-time and placed in fixed locations so that applications can quickly access them. The inherent limitation of this approach is that any new language that needs to be supported by the software (e.g., due to product entry in a new foreign country) requires a new release of the applications and, potentially, the operating system, which delays introduction of products into new markets and can introduce new defects into the product.
As such, a need exists in the art for a method and apparatus for providing language modularization that can minimize some of the problems previously mentioned.
The features of the present invention, which are believed to be novel, are set forth with particularity in the appended claims. The invention may best be understood by reference to the following description, taken in conjunction with the accompanying drawings, in the several figures of which like reference numerals identify like elements, and in which:
While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the following description in conjunction with the drawing figures.
As shown in
Each software component, including but not limited to, browser 110, applications 112, font manager 114, smart text entry utility 116, keypad mapping rules 118 and encoding schemes 120 found in electronic device 100 that require language information can access the information from the language data package 102. Language data package 102 can reside in memory within electronic device 100 such as flash memory, Random Access Memory (RAM), etc. Language data package 102 can be compressed and be sized such that it can be efficiently delivered to the electronic device 100 wirelessly (over-the-air) or using a tethered device such as a computer. Updates to an existing language data package 102 can also be done over-the-air. Installation and accessing of the language data package 102 is done without requiring a system re-boot.
Though at least one language data package 102 must always be resident in the electronic device, any number of additional languages may be loaded without recompilation of the software; the only limitation is the amount of memory. Removal or enhancement of a language is accomplished by removing or loading a new language data package 102.
As each application or function requires access to a data element, it makes use of an access function that obtains the data from the currently active language data package. For example, an application may request a text prompt from the application data package and, when it requests the operating system to draw the display, the function that handles graphic layout will then request the bitmaps for the character set and any graphic elements before composing the screen and updating the display.
Referring to
Controller 202 is in charge of accessing the language packs 214 and deciding which language pack 214 is the currently active language package. The controller 202 accesses all language specific information from the currently active package. For example, an application in radio 200 may request a text prompt from the currently active language package 214 (for example language package 1). When the application requests the operating system to draw the display, functions that handle graphic layout will then request the bitmaps for the character set and any graphic elements before composing the screen and updating the display.
Periodically, the operating system of radio 200 will search for the available language packs 214, confirm their integrity, and designate one language pack as the currently active language. In one embodiment of the invention, the search will be conducted at power-up of radio 200. However, a more dynamic system can perform the necessary checks when a change is detected in the language pack memory space 212.
The flash packs 214 are located starting at a fixed location in flash memory, in this example starting address 216; however, this location can vary from product to product. The starting position will be defined by the memory map of the radio 200. Having a fixed starting location for the first flash pack (pack 1) 214 affords the advantage of making the flash packs 214 easy to find during the power-up sequence of radio 200. During the power up initialization of the Data Resource Manager (DRM) (
The DRM is responsible at runtime for reading the flash pack memory region and determining what flash packs have been loaded. Memory pointers are set up so that the data contained in the packs may be accessed. After this step, the use of the resources should be transparent to the clients using the data, since there should be no difference between a flash pack and a non-flash pack configuration as far as accessing the data.
A flash pack 214 in accordance with an embodiment of the present invention can be loosely defined as an image file that may be flashed into a radio such as radio 200. A flash pack is intended to be a “package” that can be “plugged” into the radio 200. This provides an opportunity for configuring the radio 200 with different languages. The data that comprises any of these languages are located in C language files that are generated using an editor tool. At build time, the file is compiled into an object file and is then linked into the image that carries the data for supporting the particular language. By using the flash pack system, it is possible to add/delete different languages without having to rebuild the radio's subscriber software code. If a new feature such as support for a new language is required, using the flash system, the new language is simply “flashed” into the radio 200.
The flash pack system of the present invention contains both runtime and non-runtime components. The non-runtime components of the flash pack system are responsible for taking input data, for example, taking text prompt data, and creating image files (flash packs 214) that may be flashed into radio 200. The flash packs 214 may then be flashed into the radio's flash memory 212. Once this occurs, the data flashed into the memory 212 is simply hex data, and has no linkage to the compiled radio's “subscriber” code. The runtime components of the system are responsible for searching the designated flash pack memory region in the radio and loading any packs that it finds. The runtime software's job is to find the flash packs 214 and decode the data in them.
In
The information or info portion 304 is unique for language packs that are loaded. The info portion 304 includes information regarding the sizes of the data located in the data portion 306. The contents of the information section are specific to the type of flash pack (e.g., a bit map pack, a font pack, etc.). Additionally, a checksum is located in this section for ensuring the integrity of the data section. Finally the data portion 306, like the info portion 304, is unique to the type of flash pack being used; it can for example be arrays of any type of data, depending on the data being carried.
In
A language pack (flash pack) runtime architecture 500 for radio 200 is shown in
In
The data portion 602 of language pack 600 contains all of the necessary data that the DRM needs in order to use a language as well as hold the smart text entry database for the language. The first three data sections: prompt data 602, decode table 604 and the prompt table 606 are used by the DRM to display a language in an electronic device such as radio 200. The smart text entry info 608 and smart text entry data 610 hold the smart text entry database (e.g., T9™ database) for the particular language in question. The low table 612 and the up table 614 provide information for the lower case and upper case character sets for the language. Finally, the browser info 616 and browser data 618 ensures that the browser data specific to a particular language is in memory only when necessary.
The present invention is hardware agnostic, and does not require use of a file system which is very important when implemented in portable electronic devices such as radio telephones. Access to the data may be stored in whatever memory is available to the embedded device, and can be accessed very rapidly. The language modularization technique of the present invention allows for updating of the language packs without having to re-release operating system software or reload applications.
With the language pack system in place, it is possible to manufacture products that have an identical subscriber load, yet have different language configurations. In effect, the languages available on a product may be added or removed without requiring a rebuild of the product's (e.g., a radio) software. When a language other than the default language (e.g., English) is desired for a product, the flash pack file for the desired language is simply flashed into the product. This process can be repeated to add more languages. By separating and later loading any required language-specific data prevents wasted memory space at compile-time for unused language information. Furthermore, by using access functions that access language specific data from the currently active language pack, the data can reside wherever is most efficient for a given product. Thus, data can be accessed directly from flash memory, Random Access Memory (RAM), etc.
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents will occur to those skilled in the art without departing from the present invention as defined by the appended claims.
