Patent Application
20140297714
1. Technical Field
Embodiments of the present disclosure relate generally to memory space constrained systems such as embedded systems, and more specifically to providing binary images customized for different users in memory space constrained environments.
2. Related Art
A binary image refers to a set of software instructions ready for execution by a processor. Typically, modules of a software program (written in higher level languages such as C, C++, Java, etc.) are compiled to generate corresponding object modules in machine level formats, and are thereafter linked to form an executable binary image. The binary image thus formed can be stored in a random access memory and executed to obtain the functionality for which the software program is designed.
Often, a software program has a ‘core functionality’ and several optional peripheral features. Different customized versions of the software program are often provided integrated with different combinations of peripheral features, with each version typically tailored for the requirements specific to corresponding groups of users. Core functionality refers to the basic features (for which the software program is designed) that are integral to all such versions of the software program. Thus different versions of the software program may have different sets of modules implementing the corresponding optional peripheral features.
There is often a need to provide binary images customized for different users in memory space constrained environments. A memory space constrained environment is characterized by limited memory available for storing binary images, in that a binary image, if built to contain all the optional features, may not fit in the available limited memory space.
Example embodiments of the present invention will be described with reference to the accompanying drawings briefly described below.
In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
An aspect of the present invention provides a web-based system enabled to generate binary images customized for different users in memory space constrained environments. In an embodiment, inputs from a user identifying a set of features of interest in a software program, and a maximum size of memory space available for storing the software program, are received. A required size of memory space for the software program, including the set of features is computed. If the required size is more than the maximum size, the user is notified that the set of features cannot be fit into the available memory space.
Otherwise, a corresponding binary image implementing both of a core functionality of the software program and the identified set of features of interest is built. The user can retrieve the binary image from a server of a web based system using a client system.
Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant arts, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.
Memory space constrained system 100 represents a system designed/implemented by an original equipment manufacturer (OEM), and may, for example, represent a refrigerator, printer, air conditioner, weighing scale, data acquisition and control unit, etc. System 100 is shown containing base function block 105, host microcontrol unit (MCU) 110, system-on-chip (SoC) 120, internal flash 125, memory 130, external flash 140, and antenna 150.
Base function block 105 performs the operations required in providing the basic function (base functionality) that system 100 is designed for. Thus, for example, when system 100 represents a refrigerator, base function block 105 performs the operations involved in cooling/heat transfer, and is assumed to contain the corresponding physical components (e.g., compressor, heat-exchanger etc.) required for refrigeration. Similarly, when system 100 represents a data acquisition and control unit, base function block 105 represents corresponding sensors (e.g., temperature/pressure sensors), signal conditioning components, etc. Base function block 105 may transmit to host MCU 110 on path 101, data representing one or more parameters (e.g., temperature/pressure values) of interest. Base function block 105 may receive from host MCU 110 on path 101, commands for controlling various operations of base function block 105.
Host MCU 110 may receive parameter values from base function module 105 on path 101, and may store the values in memory 130. Host MCU 110 may also provide commands (received, for example, from a remote system connected to wired network 190 and via Wireless communication block 120) to base function block 105 via path 101. Host MCU 110 may optionally display parameter values received from base function block 105 on a display (not shown). Host MCU 110 communicates with wireless communication block 120 via path 112 to forward parameter values to, and receive commands from, wireless communication block 120. The commands may be received from a remote system connected to wired network 190, as noted above. Memory 130 may include volatile and non-volatile memory, the non-volatile memory storing code to be executed by host MCU 110.
Wireless communication block 120, which may be implemented, for example, as a system-on-chip (SoC), provides wireless communication capabilities to system 100. In an embodiment, wireless communication block 120 implements medium access control (MAC) layer and physical layer functions specified according to IEEE 802.11 (family of) specifications, also referred to as WLAN (Wireless Local Area Network). Wireless communication block 120 contains one or more processing units or processors (not shown) to execute software instructions (firmware) required for controlling the hardware portions of Wireless communication block 120, as well as for providing network layer and other communication protocol layers required for communication. The firmware may be stored either in internal flash (memory) 125 or in external flash 140, or in both.
Antenna 150 transmits/receives signals to/from a wireless medium, and may be connected to the corresponding physical layer components in Wireless communication block 120. Wireless communication block 120 may be configured as a wireless station (for e.g., according to IEEE 802.11) and enables communication between system 100 and remote systems (e.g., those connected to wired network 190) via AP 160. Although memories 125 and 140 used by wireless communication block 120 have been noted herein as being flash memory, in alternative embodiments system 100 may in general use any other solid state non-volatile memory (e.g., ROM, EPROM, non-volatile RAM, etc.) instead, in place of internal flash 125 and external flash 140.
AP 160 communicates (exchanges data packets with system 100) via antenna 170 on a wireless medium, and with wired network 190 via network backbone 180 and wired path 168. Wired network 190 may represent the World Wide Web or internet.
Typically, an OEM purchases Wireless communication block 120 (as well as the firmware required for operation of Wireless communication block 120) from a vendor, and assembles the various blocks of
The OEM may produce many (e.g., several hundreds or thousands of) units of system 100. In addition, the OEM may also produce variants of system 100, the variants differing in terms of the specific features included in the firmware. Thus, for example, the OEM may produce 1000 units of system 100 with serial communication on path 112 implemented according to UART (Universal Synchronous Receiver Transmitter, an asynchronous data link standard), and another 1000 units with serial communication on path 112 implemented according to SPI (Serial Peripheral Interface, a synchronous serial data link standard). The firmware binary image may be different for the two examples noted above, with different serial communication drivers being used for the two examples. As another example, different OEMs may use different features to build their systems. Thus, while one OEM may use ‘WPA/WPA2 personal’ as the security mechanism, another OEM may use ‘WPA/WPA2PSK Enterprise’ as the security mechanism.
Accordingly, the vendor may make available to the OEM, multiple variants (or versions) of the firmware (or binary image representing the firmware) that is to be installed/loaded by the OEM in flash 125 and/or flash 140 prior to shipment or use of system 100. As noted above, all variants of the firmware, in general, have a same ‘core functionality’, but different optional peripheral features. Core functionality of the firmware provides basic operations needed for wireless communication according to a corresponding standard, for example, IEEE 802.11.
The size of internal flash 125 and external flash 140 is typically limited (due to cost/power considerations), and may not be sufficient to store the firmware with all variations/features included. Hence, the vendor of Wireless communication block 120 provides multiple variants of the firmware, each variant including a corresponding set of selectable features. The manner in which such variants can be provided to OEMs (or any other users, in general) in accordance with several aspects of the present invention, is described below reference to examples.
Client system 210 represents a system (digital processing system) such as a personal computer, workstation, mobile station, etc., used by an OEM to specify/select the desired set of features to be included in the binary image representing the firmware to be loaded in internal flash 125 and/or external flash 140. Client system 210 forwards the user selections to a corresponding application/software executing in server 240. Client system 210 may provide a suitable user interface (e.g., a graphical user interface) to enable the OEM to specify/select the desired features. Client system 210 may execute scripts (e.g., java scripts) in a browser and may perform computation of whether the user selections of the set of features to be included in the binary image will fit in the available memory space or not, as noted further in sections below.
Internet 230 provides network connectivity between client system 210 and server 240. Internet 230 may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP) well known in the relevant arts. In general, in TCP/IP environments, a TCP/IP packet is used as a basic unit of transport, with the source address being set to the IP address assigned to the source system from which the packet originates and the destination address set to the IP address of the target system to which the packet is to be eventually delivered.
Server 240 represents a physical machine (digital processing system) that executes corresponding application(s) for receiving, via Internet 230, the features selected at client system 210, and generates (builds) a binary firmware image that can be loaded in internal flash 125 and/or external flash 140 for execution. Server 240 may store the generated binary image in data store 250, and the binary image is available for retrieval by a user (e.g., OEM personnel, registered with server 240) via client system 210. The build operations by the application(s) executed in server 240 may include automated code modification based on the features received, automatic build to generate the firmware binary image, elimination of invalid feature combinations, organization of functions for pre-fetching, caching, and paging, etc.
Data store 250 represents a non-volatile storage facilitating storage and retrieval of data representing software instructions (e.g., source files) that are to be compiled and linked to form the firmware binary image noted above. Data store 250 may also store compilers, linkers, etc, required for building the firmware binary image. Broadly, data store 250 may be viewed as storing the data (including web pages, etc.) and instructions necessary for server 240 to providing OEMs at client systems the ability to indicate the features of interest and to provide in response, a binary image in accordance with several aspects of the present invention.
Thus, an OEM is provided the flexibility to specify different desired features for different environments, and conveniently have available the corresponding version of the software program that can be executed in wireless communication block 120 (after storing in flash 125/140). Such a feature is convenient at least in environments where OEMs may desire many number of variations of a software program. The manner in which the system of
In step 310, client system 210 receives inputs identifying a set of features of interest to be included in a software program, as well as a maximum size of memory space available for storing the software program. The maximum size of memory equals the sum of the sizes of internal flash 125 and external flash 140, in the example of
In step 320, client system 210 computes a required size of memory space for the software program, including the set of features. The term ‘computing’ as used herein refers to one or more mathematical operations (which may include addition, subtraction, multiplication or division) as against mere receiving of a pre-computed value from an external system. Control then passes to step 330.
In step 330, client system 210 determines whether the required size of memory space is more than the maximum size of memory available (as specified in step 310). If the required size of memory space is more than the maximum size of memory available, control passes to step 340, and to step 350 otherwise.
In step 340, client system 210 notifies the user that the set of features cannot be fit into the available memory. The notification may be provided via visual display on the user interface of client system 210. Control then passes to step 399, in which the flowchart ends.
In step 350, client system 210 provides to the user, a binary image implementing both of a core functionality of the software program and the set of features of interest (selected in step 310). In an embodiment, client system 210 forwards the user selections made in step 310 to server 240 (server 240 is assumed to have access to the core functionality portion), with server 240 in turn building the binary image and sending it back to client system 210. The binary image is (without further processing) ready for execution by the processing unit(s) in Wireless communication block 120. Control then passes to step 399, in which the flowchart ends.
It may be appreciated that the programming logic to implement steps 310-350 may be provided by server 240, for example, in the form of scripts embedded in a web page specification. Client system 210 may render a web page corresponding to the specification (including elements for receiving inputs, etc.) and the scripts are executed automatically in the browser (in a known way) to process the user inputs. The scripts may, for example, have an approximate memory requirement for each feature, and compute the memory requirement as an addition of the requirements for all the specified features (in addition to that required for the core functionality).
It may be further appreciated that the computations for step 320 can thus be an approximation, and notification of step 340 may be based on such an approximation. Alternatively or in addition, server 240 may perform a more accurate computation (e.g., while building the binary image), considering the specific modules to be included in the image. In an embodiment, server 240 first translates each specified feature into a corresponding set of modules (in many cases multiple modules), and the union of all the modules corresponding to the specified features and also the core functionality is formed. The sets in such a union are linked to form the binary image.
As is well known, each object module contains ‘relative addresses’ within the same module, and linking entails assigning absolute addresses to such relative addresses. Linking may similarly resolve references to variables referred across different object files. The binary image formed by linking, thus represents an executable file ready to be stored in a randomly accessible memory from which a processor can retrieve and execute instructions of the image. Server 240 may accordingly provide a more accurate computation of the memory space requirements for the image.
Thus, the determination of whether the binary image to be used fits the available memory space or not, can be performed at client system 210 and/or server 240. The OEM may also be notified the extent to which the memory space requirement exceeds the available memory requirement, such that the OEM may consider removal of some of the features for the corresponding image.
The manner in which a user is enabled to select the desired set of features referred above is illustrated next with respect to example web pages rendered by a browser at client system 210.
In the example illustrated herein, it is assumed that a single binary image is generated and eventually stored in internal flash 125. Since the image contains all linked modules, the addresses of instructions, etc., are generally with resolved values (contrasted with object files, where the addresses are relative). External flash 140 on the other hand stores the various data, web pages, backup data, etc., which can again be retrieved/manipulated by the instructions stored in internal flash 125. According to an aspect of the present invention, the sufficiency of memory is checked for both the image and the data, as described below in further detail.
In the webpage of
In the webpage of
After the corresponding selections are made, the user clicks on the ‘Next’ button (510) to navigate to the next webpage (shown in
WPAWPA2PSK Enterprise (Client), DHCP Server, DNS Server, HTTPS Client (HTTP over SSL), HTTP Client, SNTP Client, SSL Client, HTTPS Server, HTTP Server, SSL Server, GSLink with SSL, GSLink, Discovery mDNS DNS-SD and Network Connection Manager. User-selectable features are indicated in the respective Figures by black check boxes.
It is noted that, in an embodiment, the following capabilities are part of the core functionality, and therefore not selectable by a user as a feature: 802.11b/g Client & Limited AP, Radio Configuration, Power Save Modes (Sleep, Deep Sleep, Standby),
Unsolicited Data Transmission, WPAWPA2PSK(Client), ARP, ICMP, UDP, TCP, DHCP Client, DNS Client, IPV4, Battery Check, GPIO Support and Async Support. These capabilities are shown as ‘preselected’, as indicated by the grayed check boxes in
With respect to
It may be observed from the web pages of
The web page of
It may be appreciated that markers 501 and 502 are updated to reflect the expected aggregate memory space in flash units 125 and 140 respectively, as the user continues to select features of interest. If the size of the resulting binary image would exceed the maximum available memory space (in flash 125 and/or flash 140), browser 400 may display that the binary image cannot be built, and force the user to change selections.
Thus, once a user selects features that are within the limits of the available memory space, client system 210 forwards the set of selected features and the data identifying user inputs as to memory space availability, to server 240. Server 240 may then make a more accurate computation of the memory space requirements, and notify the user (e.g., via electronic mail (email) offline) that the available memory space is not sufficient to contain the binary image. On the other hand, if the available memory space is sufficient, server 240 performs the necessary operations such as compiling and linking to generate the binary image, which the user can then retrieve from server 240 via client system 210.
In an embodiment, client system 210 does not forward (i.e., submit) the selected set of features to server 240 if client system 210 determines that the available memory space would be insufficient to contain the binary image when built. In the embodiment, once client system 210 submits the set of features to server 240 (after determining that the available memory space is sufficient to contain the binary image when built), client system 210 also notifies the user via email that the set of features has been submitted. Server 240 then makes a more accurate computation of the memory space requirements ensures that the selected set of features are included in the binary image to be built. Server 240 may perform multiple iterations and dynamically figure out changes to be made to fit the feature set so that the build succeeds. Once the build is successful, server 240 notifies the user via email that the submitted set of features were included successfully in the built binary image.
It should be appreciated that an OEM may use interfaces such as the above to obtain a binary image. The user inputs in screens of
The block-level implementation details of server 240 are described next with respect to an embodiment.
Module map 1150 contains a map, which can be used to identify the set of modules to be incorporated into the binary image, for providing each of the features that can be selected by a user using the interfaces described above with respect to
Scripts 1130 contain the programming logic executed when web pages are rendered in the browsers of client system 210, as well as that used on server 240 for various checks and to build the binary image. The programming logic may compute the available memory space in markers 501/502 (without having to rely on web server 1110 for such a functionality) and provide other rich functionality in combination with elements defined as a part of HTML content, as explained above.
Web pages 1120 represent the static content that is sent to client systems 210 for rendering in corresponding browser 400. Some of scripts 1130 are embedded in web pages 1120 before being sent to client system 210. Examples of the web pages transmitted by web server 1110 are noted above with respect to
Web server 1110 retrieves web pages 1120 and transmits the web pages on path 243 to client system 210, in response to a user request to access web pages at a corresponding URL. Subsequently, web server 1110 receives the set of features selected by a user at client system 210 (and data indicating available memory space), and forwards the received information to binary image construction module 1140. The web server 1110 may also facilitate a user to download the binary image, once it is constructed and available for the requesting user, as described below.
Email communication module 1170 receives messages from binary image construction module 1140, and generates corresponding electronic mail (email) for transmission to client system 210 via path 243.
Binary image construction module 1140 analyzes module map 1150 to determine the set of modules required for building the binary image corresponding to each of the set of features received (and also including the core functionality portion). The union of all such sets forms the set of modules that are to be incorporated in the binary image. The size of the memory space required for storing the binary image is computed based on the sizes of the modules in the union, or alternatively such size may be determined once the image is constructed.
Binary image construction module 1140 retrieves the corresponding modules (including those identified as being required for implementing the core functionality) from modules 1160 (which may also be stored in data store 250, as noted above), and builds the binary image by linking the modules. Such building/linking can be performed in a known way. In forming (or prior to forming) the binary image, binary image construction module 1140 may perform several operations such as, for example, automated code elimination of invalid feature combinations, organization of functions for pre-fetching, caching, and paging, etc., well known in the relevant arts. As noted above, such binary image may be stored in internal flash 125. The binary image can be made available in the form of a file for downloading via the Internet.
Binary image construction module 1140 may further generate another file containing the data (e.g., the parameter values according to the applicable standards), the web pages, etc. The data can be directly loaded into external flash 140, and the program logic of the binary image may be designed to access (from external flash 140) the data desired in specific programming context according to any pre-specified convention.
Binary image construction module 1140 may store the binary image and data file in data store 250 via path 245 for later retrieval (as, for example, on receipt of request from client system 210). Binary image construction block 1140 may send messages on path 1141 to email communication block 1170 indicating whether the build of the binary image (and corresponding data file) was successful or not, if the available memory space is sufficient to store the (built) binary image or not, etc. In response, email communication module transmits a corresponding email, addressed to client system 210, on path 243.
In the example business context noted above, an OEM may retrieve the two files, and stores the binary image in internal flash 125 and the data in the data file in external flash 140. As the instructions in internal flash 125 are already linked, a processor in wireless communication block 120 executes the instructions in internal flash 125 (while accessing any required data from external flash 140) to provide various features described above with respect to
In Appendix A, column 1 lists the feature selectable by a user, column 2 lists the source files corresponding to the feature, column 3 is the name of the corresponding (software) sub-system that provides the feature, column 4 lists the size (in bytes) of object code of the corresponding sub-system, and column 5 lists the object files corresponding to the feature. It is noted that a single feature may require multiple software sub-systems. Thus, for each feature, binary image construction module 1140 links all the corresponding multiple software sub-systems. For example, feature WPS would require sub-systems named supplicant, GEPS, Serial2Wifi, as noted in Appendix A. Hence, to provide feature WPS, binary image construction module 1140 links the object files corresponding to all the corresponding sub-systems. It is noted that a source file may have a single corresponding object file (code only, noted in Appendix A as .text) or have corresponding a code file as well as data file (noted in Appendix A as .rodata). Some of the details corresponding to feature SPI are also noted above with respect to
The description is continued with respect to a digital processing system in which various features are operative when the corresponding executable modules are executed.
Digital processing system 1300 may contain one or more processors (such as a central processing unit (CPU) 1310), random access memory (RAM) 1320, secondary memory 1330, graphics controller 1360, display unit 1370, network interface 1380, and input/output interface 1390. All the components except display unit 1370 may communicate with each other over communication path 1350, which may contain several buses as is well known in the relevant arts.
CPU 1310 may execute instructions stored in RAM 1320 to provide several features of the present invention. The executed instructions may first be copied from secondary memory 1330 to RAM 1320 prior to execution by CPU 1310. CPU 1310 may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU 1310 may contain only a single general-purpose processing unit.
RAM 1320 may receive instructions from secondary memory 1330 using communication path 1350. RAM 1320 is shown currently containing software instructions constituting shared environment 1325 and/or user programs 1326. Shared environment 1325 contains utilities shared by user programs, and such shared utilities include operating system, device drivers, etc., which provide a (common) run-time environment for execution of user programs/applications.
Graphics controller 1360 generates display signals (e.g., in RGB format) to display unit 1370 based on data/instructions received from CPU 1310. Display unit 1370 contains a display screen to display the images defined by the display signals. When system 1300 corresponds to client system 210, display unit 1370 displays the web pages of
Network interface 1380 provides the electrical and protocol interfaces to enable system 1300 to communicate with other systems on a network (e.g., using Internet Protocol).
Secondary memory 1330 (representing a non-transitory machine/computer readable storage/medium) may contain hard drive 1335, flash memory 1336, and removable storage drive 1337. Secondary memory 1330 may store data and software instructions, which enable digital processing system 1300 to provide several features in accordance with the present invention. Thus, when system 1300 represents server 240, the software instructions corresponding to the blocks 1110/1140/1160 of
Some or all of the data and instructions may be provided on removable storage unit 1340, and the data and instructions may be read and provided by removable storage drive 1337 to CPU 1310. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 1337.
Removable storage unit 1340 may be implemented using medium and storage format compatible with removable storage drive 1337 such that removable storage drive 1337 can read the data and instructions. Thus, removable storage unit 1340 includes a computer readable storage medium having stored therein computer software and/or data. However, the computer (or machine, in general) readable storage medium can be in other forms (e.g., non-removable, random access, etc.).
References throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.
