WO2006075145A1

WO2006075145A1 - Producin a generic programmable platform

Info

Publication number: WO2006075145A1
Application number: PCT/GB2006/000079
Authority: WO
Inventors: Christopher Roy Box; Peter Joseph Murphy; Simon Roy Nieder; Paul James Walke
Original assignee: Axr Limited
Priority date: 2005-01-11
Filing date: 2006-01-11
Publication date: 2006-07-20
Also published as: GB2422071A; GB0600435D0

Abstract

A programmable platform has interfaces (1101, 1104) for use in embedded systems, such as a monitoring systems. A mobile processor (401) from a re-purposed mobile cellular telephone has a serial interface (1114), a visual display (1115) and a modem functionality program. Upon power-up, the modem functionality program is activated and is responsive to AT commands. A control processor (502) is configured to receive input data and to communicate with the mobile processor via the serial interface (1114). The control processor (502) is configured to energise the mobile processor, de-activate the modem functionality program, activate data communication procedures and communicate input data to the mobile processor. The mobile processor is configured to process input data received from the control processor and supply output data to the visual display as a result of processing the received input data.

Description

Producing a Generic Programmable Platform

The present invention relates to a method of producing a generic programmable platform including an input interface and an output interface. Over recent years, there has been a tendency to replace bespoke electronic components with general purpose programmable components, such as micro processors and micro controllers. It is therefore appreciated that a low cost high powered generic processing platform would be highly desirable. A high powered processor would be capable of processing content data (such as audio and/or video signals etc) in realtime and therefore the range of applications for which such a device could be used could be very wide. Furthermore, the generic approach would ensure that it only became necessary to learn and develop a single instruction set and method of programming. Thus, by using the available power of the processing platform, it would be possible to achieve many desirable processing functions while at the same time presenting a user friendly and generic interface. A known problem with adopting an approach of this type is that of costs and in many applications a high cost, highly powered processing engine could not be justified in relation to the totality of the cost of the overall product. In the market place, it would be possible to under-cut production costs by^' using a processing platform that was just powerful enough and programmed, possibly using assembler code, so as to be optimised for its particular application. A problem therefore exists in terms of providing relatively inexpensive but relatively highly powered processing devices that may be converted into a generic platform, which in turn could then be adopted in many different real-time processing environments while being programmed using generic building blocks. According to a first aspect of the present invention there is provided a method of producing a generic programmable platform including an input interface and an output interface, comprising the steps of removing operational equipment from an outer casing of a mobile telephone, said operational equipment including a first data communications interface and operating in accordance with one of many hardware and proprietary software combinations; connecting said first interface to a second interface of a control processor; encapsulating said operational equipment and said control processor to produce a generic platform; and executing instructions within said control processor so as to facilitate data communication with said operational equipment and to provide said generic platform with a generic data interface and a generic operating environment.

A solution is thereby provided by the recycling and redeployment of operational equipment found in, what have become, redundant mobile telephones.

Furthermore, this approach is also highly advantageous in that it provides an environmentally acceptable solution for the disposal of redundant mobile telephones (cell phones) and is therefore attractive to mobile telephone manufacturers who may be tasked with the disposal of telephony equipment in an environmentally acceptable way.

In a preferred embodiment, the input interface and/or output interface includes a digital data interface or a radio interface. The radio interface may be provided by additional circuitry, thereby making redundant mobiles ZigBee compatible for example, for radio network solutions. Alternatively, communication channels presently resident within the mobile telephone system itself may be deployed, such as Bluetooth connections or infrared connections.

In a preferred embodiment, a serial port unlocking command is issued by the subsidiary processor to the operational equipment to thereby allow a further communication over the first serial interface. The provision of this further communication may include the installation of programs upon the operational equipment and the exchange of operational data between the operational equipment and the subsidiary processor. Preferably, one of the programs installed upon the operational equipment is a virtual machine to facilitate the provision of the generic operating environment. Preferably, cellular mobile telephony would not be exploited so as not to compete with first-use mobile telephone technology.,

According to a second aspect of the present invention, there is provided a method of re-purposing processing devices of a mobile cellular telephone (a mobile processor) having a serial interface for data communication via a modem process, comprising the steps of: interfacing a control processor to said serial interface; issuing a command from said control processor to power-up said mobile processor; issuing a command from said control processor to said mobile processor over said serial interface to drop said modem process; downloading executable instructions from the control processor to the mobile processor; and executing said executable instructions to facilitate communication between the control processor and the mobile processor.

According to a third aspect of the invention there is provided a programmable platform having interfaces for use in an embedded system, comprising: a mobile processor from a re-purposed mobile cellular telephone having a serial interface, a visual display and a modem functionality program; a control processor configured to receive input data and to communicate with said mobile processor via said serial interface; wherein said control processor is configured to: energise the mobile processor; de-activate said modem functionality program; activate data communication procedures; and communicate input data to said mobile processor; and said mobile processor is configured to: process input data received from the control processor; and supply output data to said visual display as a result of processing said input data.

The invention will now be described by way of example only, with reference to the accompanying Figures, of which

Figure 1 shows an example of a donor mobile telephone;

Figure 2 shows the approach adopted by a preferred embodiment of the present invention;

Figure 3 illustrates procedures for the production of generic sub-assemblies; Figure 4 shows the process of removing the operational equipment from the donor telephone;

Figure 5 illustrates an example of a generic sub-assembly in its encapsulated form;

Figure 6 is a diagrammatic representation of the inter-relationships of the functional components within the generic sub-assembly;

Figure 7 illustrates an alternative generic sub-assembly;

Figure 8 illustrates a second alternative generic sub-assembly;

Figure 9 illustrates a third alternative generic sub-assembly;

Figure 10 illustrates a fourth alternative generic sub-assembly; Figure 11 illustrates procedures for the preparation of a product using a generic sub-assembly;

Figure 12 shows procedure for programming a generic sub-assembly; Figure 13 details procedures for the deployment of a product;

Figure 14 shows a first example of an application of a product;

Figure 15 shows a second example of an application of a product; and

Figure 16 shows a third example of an application of a product. Figure 1

An example of a donor mobile telephone is illustrated in Figure 1 , including an antenna 101 to facilitate GSM and GPRS communication. At its base it includes a serial interface 102, usually operating in accordance with RS232 recommendations to facilitate synchronisation and data transfer with a personal computer, for example. The interface is provided primarily in order to allow data communication to and from a personal computer via the telecommunications network. To facilitate this the mobile telephone itself presents a serial interface substantially similar to that provide by conventional modems such that conventional modem commands (AT commands) may be used to transmit data in the same way in which the personal computer would communication with the conventional modem. Furthermore, it is appreciated that, over time, the available command set has been enhanced in order to facilitate direct communication between a personal computer and the telephone itself.; allowing data contained within the mobile telephone to be modified, for example.

The mobile telephone includes a display 103 and the extent to which this display is redeployed within a final product may be dependent upon the ultimate application for which the device is intended. However, the display is, preferably, available to the generic platform. This also applies to other telephony peripherals, such as a microphone 104 and a loud speaker 105. Figure 2 A problem associated with the redeployment of mobile telephone equipment, that is referred to herein as the operational equipment (as distinct from the outer casing of the telephone) is that many different devices and peripherals have been used for different telephone types. However, it is appreciated that a relatively high level of processing capability must be provided in order to achieve digital cellular mobile telephony. Thus, the processing capabilities within a mobile telephone of this type, including micro processor technology and DSP technology, is relatively much higher than that provided within general purpose micro controllers for example. It is also appreciated that the level of processing and memory storage has increased recently, with the provision of what are sometimes referred to as smart phones.

In addition to mobile telephones being constructed using different devices (of different capabilities) different manufacturers will also have preferences in terms of the types of devices they select and in terms of preferred operating systems.

The approach adopted by the preferred embodiment of the present invention is illustrated in Figure 2. In this example, the process receives a phone type A₁ shown at 201 , a phone type B, shown at 202 and a phone type C, shown at 203. These may be considered as representing examples of mobile telephones of substantially similar levels of functionality but produced by different manufacturers such that their internal programming environment may differ significantly. It is also appreciated that much of this environment would not normally be available to a third party programmer, which in turn would create major obstacles in terms of recycling mobile telephone components.

As shown in Figure 2, each of the phone types 201 to 203 is supplied to a similar process 204 arranged to produce generic sub-assemblies. In engineering circles, a generic sub-assembly of this type would often be referred to as "black box". Thus, irrespective of the source type of phone used, the generic sub-assembly, in a preferred embodiment, provides substantially the same input interfaces and output interfaces (I/O interfaces) and substantially the same programming environment. Thereafter, these generic sub-assemblies may be used to produce many different final products. Thus, as shown in Figure 2, generic sub-assemblies may be used to produce product type X, shown at 205, product type Y, shown at 206 and product type Z, shown at 207, for example.

In a preferred embodiment and as described subsequently with reference to Figures 7 to 10, a plurality of generic sub-assemblies are produced, with varying operational characteristics. However, it should be appreciated that the set of generic sub-assemblies is relatively small, whereas the set of donor mobile telephones may be relatively large and the set of end products may also be relatively large. The alternatives, with respect to the generic sub-assemblies, relate primarily to communication requirements which in turn place additional burdens upon power consumption. Figure 3

Procedures 204 for the production of generic sub-assemblies are expanded in Figure 3.

At step 301 the operational equipment is removed from the donor telephone. All electrical connections remain intact and peripheral devices are retained. A serial interface is physically connected to a similar interface of a subsidiary processor, such that the subsidiary processor, preferably a micro controller, facilitates communication with external I/O interfaces.

At step 302 the operational equipment is encapsulated with the subsidiary processing device. In this sense, encapsulation means that the operational equipment derived from the mobile telephone and the subsidiary processor are physically retained within a mounting, which may take the form of a box or similar assembly of a preferred shape and size.

At step 303 the micro controller is instructed to issue an AT command to the serial port of the operational equipment to thereby unlock the serial port to facilitate communication with the operational equipment. The internal state of the operational equipment is therefore changed from one of basic telephony to its alternative mode of providing data communication; and it is this second mode of operation that is required in order for the operational equipment to satisfy the requirements of the generic platform.

At step 304 executable instructions to perform the operations of a virtual machine are installed onto the operational equipment. The virtual machine software emulates an operating environment, such that generic instructions may be supplied to said operational environment. The provision of virtual machines, on a variety of platforms which are then responsive to generic commands, is well established and represents the approach adopted by the Java programming language.

At step 305 a control program is installed on the subsidiary device so as to facilitate communication between the operational equipment and external I/O interfaces. At step 306 the generic sub-assembly is encapsulated within its generic package.

The order of the procedures identified in Figure 3 is shown by way of example only and it will be appreciated that the actual procedures could take place in a different order. In particular, processors may be pre-programmed prior to assembly or code may be downloaded with the devices in situ; the particular order adopted probably being dependent upon the number of units being produced. Similarly, it may be preferable to install the control program onto the subsidiary device at an earlier stage, such that this program may be subsequently used to assist with the unlocking of the serial port of the operational equipment. In the procedures shown in Figure 3, it is assumed that an alternative approach is used to achieve the unlocking at this stage. However, similar unlocking is required each time the device is energised and, preferably, is repeated periodically so as to ensure that the operational equipment does not revert to its alternative (and from its perspective preferred) mode of operation. Figure 4

The process of removing the operational equipment from the donor telephone identified at step 301 , is detailed in Figure 4.

With the majority of mobile telephone devices, such as the device shown in Figure 1 , it is possible for the operational equipment 401 to be made available by removing a back cover 402 and a front cover 403. The operational equipment 401 is then in a position for it to be encapsulated with the subsidiary processing device. Figure 5

An example of a generic sub-assembly shown in its encapsulated form is illustrated in Figure 5. This represents the first of five generic sub-assembly types, with types 2 to 5 being illustrated in Figures 7 to 10 respectively.

The operational equipment and the subsidiary processing device are encapsulated within a standard sized box 501 which is sealed such that each generic sub-assembly produced by this process presents a substantially similar appearance, in addition to presenting similar physical interfaces and a similar programmable environment.

Within the encapsulated box 501 , the operational equipment 401 (derived from the mobile telephone) communicates with a micro controller 502 via a serial interface

503. The operational equipment 401 and the micro controller 502 receive power from a power supply unit 505 which, for self contained applications, may include replaceable or rechargeable batteries or, alternatively, for permanent locations, unit 505 may receive mains power. In an alternative preferred embodiment, the power supply unit receives power from the mains but in addition also provides battery backup. For remote sensing applications electrical power could also be derived from solar panels or wind generators.

The micro controller 502 communicates with an input/output serial interface 504, thereby providing data communication with an external device.

The overall functionality of the generic sub-assembly of Figure 5 depends upon the provision of the original telephone hardware, proprietary operating systems and systems presented for the production of the generic sub-assembly functionality itself. Figure 6

The inter-relationships of the functional components within the generic sub- assembly are shown diagrammaticaily in Figure 6. In this example, three generic sub- assemblies have been produced, each derived from different owner hardware.

In the example, first donor hardware is illustrated by square boxes 601 and 602. A second telephone type provides similar functionality sourced from different components, identified by triangular boxes 603 and 604. Thus, large boxes 601 and 603 may represent the display screen whereas small boxes 602 and 604 may represent a particular processor within the operational equipment. Likewise, a third telephone hardware type includes a circular box 605 (screen type) and a smaller circular box 606 representing a different processor type.

In order for the telephone functionality to be provided within the hardware environment, it is necessary for operational software to be included in the form of an operating system. Thus, the first telephone includes operating system 611 , that is compatible with physical devices 601 and 602. Similarly the second telephone type includes an operating system 612 again compatible with hardware 603 and 604, with the third telephone having an operating system 613, again compatible with hardware 605 and 606. Thus, although each of the three telephones provide substantially similar functionality when operating in their original mode of communication, the actual implementation varies significantly and the provision of particular operating systems will be consistent with the types of hardware provided and with the preferences of a particular manufacturer or manufacturing group concerned.

When deployed as a generic sub-assembly, for a particular application, the application functionality is defined by an application program. In this example, when converted into a generic sub-assembly, each of the three systems will be providing the same application function and therefore will each require the same application program, illustrated as 614. It should now be possible to appreciate the generic nature of the sub-assembly given that each sub-assembly, although including radically different physical components and operating systems, receives not a different application program in order to achieve the required level of functionality but, in fact, an instance of the same application program such that it is not necessary to develop application programs which vary dependent upon the nature of the original donor equipment. By the inclusion of a virtual machine, differences in the application programs only reflect the differences of the final application for the device and are not restrained by the underlying hardware and low level operating systems deployed within the device itself.

In the representation • of Figure 6, the provision of a virtual machine is illustrated as layer 615 for the first device, layer 616 for the second device and layer 617 for the third device. The geometric relationship illustrates that each virtual machine must interface with the proprietary layer of the telephone operating system while at the same time interfacing with the generic layer of the application programs. Figure 7

An alternative generic sub-assembly is illustrated in Figure 7. In this example, data communication with the micro controller 502 is still effected via the serial interface 504. However, in addition, the micro controller may also communicate with analogue devices. Analogue output signals are received via an analogue output interface 701 from the micro controller 502 via a digital to analogue converter 702. Similarly, input analogue signals are received via an analogue input interface 703 and supplied to the micro controller 502 via an analogue to digital converter 704. Figure 8

A second alternative generic sub-assembly is illustrated in Figure 8. In this example the micro controller 502 communicates with a TCP/IP network 801 via a network interface 802 and a TCP interface circuit 803. In this way, it is possible for the generic sub-assembly to communicate with local networks or the Internet using internet protocol packets.

Furthermore, it will be appreciated that the enhanced functionality (internet capability) of the sub-assembly of Figure 8 could also include the analogue input and output interfaces of the type illustrated in Figure 7. Figure 9

In the sub-assembly of Figure 9 a micro controller 901 is provided that is capable of itself making local radio communications. Like the sub-assembly of Figure 5, the micro controller receives power from power supply unit 505 and communicates with the operational equipment 401 and a digital serial interface 504. Where appropriate, the micro controller 901 is provided with an external antenna 902. In a preferred embodiment, the micro controller is a wireless micro controller capable of operating in accordance with IEEE 802.15.4 protocols. An example of a device of this type is the product referenced JN5121 available from Jennie Limited of Sheffield, in the United Kingdom. This represents a low power, inexpensive wireless micro controller that combines an on chip 32-bit RISC core, a fully compliant 2 GigaHertz IEEE 802.15.4 transceiver, 64 Kb of ROM and 96 Kb of RAM. External devices to complete the micro controller circuit include a crystal, flash memory, decoupling components and a printed antenna, or external antenna as shown in Figure 9.

Software is included to provide for an IEEE 802.15.4 compliant protocol stack suitable for point-to-point communication, star or tree networks and mesh network stacks such as ZigBee and Ipv6. Figure 10 A fourth alternative embodiment is illustrated in Figure 10. In this example, the antenna 101 of the mobile telephone has been retained and operational equipment is configured to revive some of the inherent telephony protocols. Thus, the generic sub- assembly may provide for data communication using a GSM data channel, GPRS, G3 communication or similar data communication protocols provided in telephone systems that subsequently become donor equipments.

Figure 11

A more detailed example of a generic platform is shown in Figure 11 , again with operational equipment 401 communicating with a micro controller 502 via a serial interface 503. In this example, the equipment may be used as a sensor. To provide this functionality, it includes a total of twelve digital input ports made up of three groups of four, each group of four identified by references 1101 ,1102 and 1103. In addition, a single analogue input 1104 is also provided.

Each group of digital inputs 1101 , 1102, 1103, is supplied to a respective multiplexer 1105, 1106, 1107. In addition, a similar multiplexer 1108 receives a digital output from analogue to digital converter 1109, that in turn receives an input from an analogue input port 1104. A single eight bit port 1110 of the micro controller 502 cyclically receives eight bit inputs from multiplexers 1105 to 1108 by means of a selector 11 11 ^'that in turn receives a two bit selection signal from the micro controller 502. Thus, in this way, the micro controller 502 routinely interrogates input levels from all of the digital and analogue inputs. In this example, the micro controller 502 has a digital section 11 12 and a radio frequency section 1113 thereby providing an additional wireless communication channel to the platform which may provide the functionality of a central hub.

A further output port of the micro controller 502 energises a loud speaker 1 1 14 so that the generic platform may be capable of providing an audible alarm. The digital inputs 1101 to 1 103 and the analogue input 1104 may receive input signals from many different devices, such as sensors for detecting temperature, humidity, pressure or light levels etc. The CPU 502 collects this raw data, optimises it and then transfers the data to the operational equipment via the serial interface 503. Within the operational equipment, sophisticated data analysis procedures may be deployed, resulting in the return of information back to the micro controller 502 or appropriate output signals being generated for display on the operational equipment's visual display 1115. As previously stated, all of these elements are encapsulated within a single box which appears and behaves in a substantially similar fashion, although many different types of operational equipment may be included therein. A parallel port 1116 of the micro controller 502 communicates with a serial

RS232 communications device 1113 so as to provide a conventional serial connection 1 114 to the operational equipment 401. In order to interface correctly with the operational equipment, a first output line 1117 from the micro controller 502 effects a hard power on function via an^' appropriate relay. In addition, a second output line 1118 provides a soft power on to the operational equipment 401. In this way, the resetting of the software may be performed at two levels. The soft on is a requirement of the operating system of the mobile telephone. After a hard reset, the mobile telephone boots up in a way that requires the soft power on to be pressed; thus the provision of line 1118 replaces this requirement for the soft on button press.

After a soft on button press has occurred, the mobile telephone operating system places the equipment in its normal default operating state. Consequently, the serial port 1114 will be configured for modem-style telephony with an external personal computer or similar. Although a significant degree of functionality is possible via the enhanced set of AT commands available, for the present embodiment to be deployed in a preferred manner, the modem functionality is removed and serial communication is provided directly to the operating environment of the mobile telephone. To achieve this, it is necessary to issue a command for the modem process to be dropped. In a preferred embodiment, using, for example, a Sony Eriksson P800 or P910I, an issuance of the command AT * ESYN = 3 results in the modem process being dropped. Within this environment, it is also possible to make function calls to the Synbian operating system so as to facilitate the establishment of a serial data transfer process. This is essentially interrupt driven such that the mobile telephone is essentially in a wait state (or performing other processing tasks) until incoming data is received which results in a call to an interrupt routine.

Communication over a serial channel is facilitated by the provision of a respective data handler running on both the micro controller 502 and on the operational equipment 401. Each handler scans for changes in the state of input/output channels resulting in an appropriate service call being made when a change is detected. This is achieved by calling, via the interrupt mechanism, a service routine on a periodic basis; typically every ten micro seconds. In response to the service routine being called, the current states of the ports are read and compared with a previously stored state. If a state change has occurred, a respective flag is set and the status conveyed to the message handler. Thus, the service routines that handle the service communication allow the serial communications to occur asynchronously for transmission in either direction.

Between the communication protocols and the processing functionality, there is provided a robust message handler within both processing environments. Each message has a predetermined structure which, in this example, consists of a start tag, a function definition, a specified data content (which may be zero for some functions) and an N tag. An example of such a message may be specified as follows:

<begin>P<end> or

<begin>A0101110Kend> (The function having a byte of binary data associated therewith.) Figure 12

The robust message handler present within the micro controller 502 and within the operational equipment 401 takes the form of a state machine, as illustrated in Figure 12. A byte of data is received and the process is interrupted. Initially, the state machine will be at state 1201 awaiting a start tag. If the correct sequence of bytes is received that represents the start tag <begin> in the preferred embodiment, the state machine will move to state 1202 awaiting the definition of a function. If the next received byte does not represent a function a reset occurs and the state machine returns to state 1201. However, if a function is detected the machine moves to state

1203 awaiting data. As previously stated, the function detected at state 1202 may or may not have data associated therewith. Consequently, if no data is expected the machine moves on to state 1204. Alternatively, if data is expected, the machine waits at state 1203 until the appropriate number of bytes have been received. Again, if these bytes are not received the machine returns to state 1201.

At state 1204 the machine waits for a correct end tag. If a complete end tag is not received the machine is again reset to state 1201. Finally, if a complete end tag is received the machine moves on to state 1205, the data is supplied to the process and thereafter the machine returns to state 1201 awaiting the next data input. It is appreciated that if the operational equipment 401 undergoes an internal reset (for whatever reason) the mobile telephone functionality will return to its preferred operating condition. That is to say, it will reinstall its modem functionality and serial communication with the micro controller (in accordance with an embodiment of the present invention) will cease. In order for this to be prevented, micro controller 502 will periodically issue a ping command to the operational equipment 401 , taking the following form: <begin>P<end> (the P being the ping function)

In response to receiving this ping command, the operational equipment will return a similar command back to the micro controller, thereby conforming that a reset has not occurred and that the system is operating as required. Alternatively, if for whatever, reason a ping command is not returned back to the micro controller, the micro controller will assume that a fresh reset is required and the AT command

AT^*ESYN=3 will be reissued so as to cause the modem process to be dropped and for the serial communication protocols to be re-established. In this way, high level programs may continue to operate such that/the generic platform continues to provide its desired functionality and continues to make use of the processing power provided by the mobile telephony components within the operational equipment.

Figure 13

In Figure 2, it was shown that generic sub-assemblies could be used to produce products, identified as product type X, type Y and type Z. Procedures for producing these product types are illustrated in Figure 13. At step 1301 a generic sub- assembly is prepared, primarily by removing the packaging applied at step 306.

At step 1302 the application-specific software is installed. This takes the form of software capable of running on the virtual machine, of the type identified as 612 in Figure 6. Consequently, a first stage to achieving the downloading of this software involves the unlocking of the serial port of the operational equipment in a procedure similar to that described with respect to step 303.

At step 1303 the generic sub-assembly is effectively re-encapsulated, in a preferred approach, for a specific purpose. Thus, in a preferred approach, the operational equipment and related devices are encapsulated in a first generic box. This generic box may then subsequently be encapsulated in a further box wherein each further box has a specific purpose and the nature of the boxes will vary dependent upon the purpose for which they are intended.

At step 1304 a specific product is repackaged, identifying its specific purpose and then ultimately the product is deployed at step 1305. Figure 14

Procedures for programming a generic sub-assembly are illustrated in Figure 14. At step 1401 an evaluation of the problem is made which would also make an assessment as to whether the device would be appropriate for the application under consideration. Furthermore, it is also envisaged that in some applications it may be possible to include two or more of the generic devices. Even in situations where this approach would provide a degree of redundancy, in terms of the available processing functionality, it is envisaged that the relatively low cost of the devices would be such that multiple applications could often provide a realistic commercial solution.

At step 1402 the destination platform is emulated and in many situations it should be possible to make use of emulation programs suitably configured to introduce the developer to the working environment of the virtual machine. This in turn facilitates the development of application programs, such as those illustrated at 612 for execution within the virtual machine such that it is not necessary for the developer to become familiar with specific donor module preferences, as previously described with reference to Figure 6. In a preferred embodiment a programming environment is provided in which it is possible to connect functional block diagrams so as to define the functionality of an application running on a real-time virtual machine. Furthermore, such a system should guarantee real-time performance for critical applications such as the provision of phase locked loops.

At step 1403 the program is tested whereafter, at step 304, a question is asked as to whether the program has performed as expected. If answered in the negative, further evaluation is performed at step 1402 and again further testing is performed. When answered in the affirmative, to the effect that the program is considered satisfactory, a compilation process may be performed at step 1405. In alternative configurations, the virtual machine may be responsive to interpreted commands, which could be supplied directly thereto without requirements for compilation or assembly. At step 1406 the program is downloaded to the device whereafter at step 1407 a question is asked as to whether another device is to be downloaded. When answered in the affirmative, a further device is selected and a further download is performed. Ultimately, all of the devices will have received the downloaded program resulting in the question asked at step 1407 being answered in the negative. Figure 15

Procedures for the deployment of an actual product, identified at step 1305, are detailed in Figure 15. At step 1501 the operating system of the operational equipment is started, essentially by providing power to the device. As previously described, in a preferred embodiment, this hard power on (activation of line 1117) is followed by a soft power on (operation of line 11 18) and then the issuance of a command to drop the modem process. Having loaded and started the internal operating system of the operational equipment, it is now necessary for the operational equipment to receive program code, such as that illustrated at 615, defining the virtual machine environment, at step 1502.

Both the operational equipment 401 and the subsidiary micro controller 502 include program storage memory. This represents relatively slow access memory which is used to permanently hold programs such that they may be installed upon program memory (fast dynamic memory) for execution within the relatively fast processors of the operational equipment. Thus, the loading of the virtual machine may take place within the operational equipment itself without requiring communication with external devices. This approach is illustrated in Figure 15 but it should be appreciated that the virtual machine program could be received from external storage such that the order of the procedure shown in Figure 15 would be somewhat different.

However, in the preferred example of Figure 15, the virtual machine software is held locally and the specific application software is also held locally such that, at step 1503, the specific application software is loaded into executable memory within the operational equipment 401.

At step 1504 the control program, resident within the micro controller 502, starts and the micro controller is now in a position to initiate communication with the operational equipment. It should be appreciated that the micro controller executes commands at a relatively slower speed therefore program instructions may be read directly from permanent read only memory, such as flash memory devices. With the micro controller 502 now being in an operational state, at step 1505 a command is issued over the serial connection 503 so as to unlock the serial port 506 of the operational equipment; issued by a similar serial port 507 of the micro controller 502. Thereafter, at step 1506, the sub-assembly enters an active state in which the application program executes on the operational equipment and communication with external devices is provided via the serial channel 503, the micro controller 502 and the external communication port 504; in the platform illustrated in Figure 5. This would also include communication with the analogue interfaces 701 , 703 in the platform of Figure 7, the ethemet connection 802 in the platform of Figure 8 and communication with the local radio network in the platform of Figure 9.

As described herein, a plurality of generic sub-assembly types have been described but, as generic sub-assemblies, each of these may be deployed in many different operational environments, thereby presenting a situation in which many different now redundant telephone handsets may be redeployed in may different specific applications, as illustrated by the representation of Figure 2. Figure 16

The generic sub-assembly shown in Figure 5 has what may be considered as an entry level of functionality and communication. Its level of functionality may also be considered as super-generic, in that ail of the other generic sub-assemblies may themselves provide substantially the same level of functionality.

Even with this basic level of functionality, the generic sub-assembly may be used in many different applications. Thus, it should be emphasised that the following examples are merely that, and many other applications are also envisaged. Firstly, the device could be interfaced to a global positioning satellite detector so as to provide a tracking device for, for example, monitoring the position of vehicles or equipment.

In a second application, the devices could be used to detect radio frequency identification tags (RFID tags) used, for example, on goods in retail environments so as to detect unauthorised movement of goods etc. The device could also be interfaced to a barcode wand or similar barcode reader so as to convert scanned data into text related data as part of a scanning procedure. Thus, it can be appreciated, that many applications are available even for the basic model that only includes a serial interface connection.

With the provision of analogue interfaces, such as that shown by the generic device of Figure 7, further applications become available. A house is shown in Figure 16 with a processing system 1601 communicating with many detectors over transmission cables 1602, 1603, 1604 and. 1605 etc. Such a configuration may be deployed as a burglar alarm, such that inputs are received from detectors and an output signal is supplied to an alarm. A similar configuration may also be used in an environmental control situation, with information being received from thermostats and this in turn being used to control the activation of boilers and mechanical valves. It should also be appreciated that other household monitoring activities may be considered and a network of this type could also be deployed in other environments.

Moving on, a similar level of functionality may be achieved by the generic device shown in Figure 9 in which the physical wires 1602 to 1605 etc are replaced by radio links. Thus, ZigBee radio communication could be facilitated in a system with a device acting as a hub and being responsible for detecting intruders, controlling temperature and receiving inputs from other household appliances. Taking this a stage further, with the functionality of the device shown in Figure 10, it would even be possible for the mobile telephony functionality to be used such that, under extreme conditions, it would be possible for the device to communicate with the householder via a mobile telephone message or a text message etc. Thus, with relatively modest investment, it would be possible for a householder to receive a text message identifying the presence of an intruder or other household condition. Again, similar functionality may be provided in alternative environments. Figure 17 The use of the platform illustrated in Figure 9, with ZigBee radio communication, facilitates relatively wide distribution of detectors while at the same time achieving long periods of standby time (typically 2 years) with reliance upon batteries. An example is shown in Figure 17 in which, on a farm, a plurality of moisture detectors 1701 , 1702 etc have been deployed over an area of ground where different drainage conditions may exist. In the radio environment, a particular detector or base station would be identified as a master and communication would take place between it and the slaves within the meshed radio environment. Thus, a farmer would be alerted to conditions in which, for example, an area of land has become waterlogged or an area of land has become too dry. Again, for a modest financial outlay, it is possible to optimise a farm's resources and thereby enhance overall efficiency. Figure 18 A more extreme environment is illustrated in Figure 16 in which the position of detectors is such that local radio communication is not possible. In this environment of mountains and lakes etc the detectors are positioned to consider the activity of volcanoes or the presence of earthquakes etc. When an event occurs such that information must be transmitted to a base station, the device is placed in an active condition and data is transmitted using the radio telephony systems (in a sub- assembly of the type shown in Figure 10) using GPRS or other data protocols. It can also be appreciated that in some environments communication may be achieved via existing hard wired TCP/IP networks, in which case generic devices of the type shown in Figure 8 would be appropriate for deployment, given that they may be attached to the existing network directly.

In Conclusion

It can be appreciated that the process of producing and encapsulating a generic sub-assembly (as represented by Figure 2) allows a wide range of redundant mobile telephony equipment to be redeployed in various constructive applications, thereby providing a relatively low cost, high powered processing engine while at the same time reducing the burden placed upon mobile telephone manufacturers to ensure that equipment is not disposed of in non-environmentally acceptable ways.

Claims

1. A method of producing a generic programmable platform including an input interface and an output interface, comprising the steps of removing operational equipment from an outer casing of a mobile telephone, said operational equipment including a first data communications interface and operating in accordance with one of many hardware and proprietary software combinations; connecting said first interface to a second interface of a control processor; encapsulating said operational equipment and said control processor to produce a generic platform; and executing instructions within said control processor so as to facilitate data communication with said operational equipment and to provide said generic platform with a generic data interface and a generic operating environment.

2. A method according to claim 1 , wherein said input interface and/or said output interface includes a digital data interface or a radio interface.

3. A method according to claim 2, wherein a digital data interface is a serial interface or an packet based asynchronous interface.

4. A method according to claim 2, wherein a radio interface operates in accordance with GSM data protocols, GPRS, G3, Bluetooth or ZigBee.

5. A method according to claim 1 , wherein said first interface is a serial interface, originally configured to exchange serial data with the originating mobile telephone.

6. A method according to claim 1 , including the step of transmitting a serial port unlocking command from the subsidiary processor to the operational equipment to allow further communication over the first serial interface.

7. A method according to claim 6, wherein said further communication includes the installation of programs upon the operational equipment and the exchange of operational data between the operational equipment and the subsidiary processor.

8. A method according to claim 7, wherein one of the programs installed upon the operational equipment is a virtual machine to facilitate the provision of said generic operating environment.

9. A method according to claim 1 , wherein the generic programmable platform is deployed in an embedded environment and include analogue to digital converters and/or digital to analogue converters.

10. A method according to claim 1 , wherein a plurality of generic programmable platforms are deployed in a distributed monitoring environment and communicate via radio transmission.

11. A method of re-purposing processing devices of a mobile cellular telephone (a mobile processor) having a serial interface for data communication via a modem process, comprising the steps of: interfacing a control processor to said serial interface; issuing a command from said control processor to power-up said mobile processor; issuing a command from said control processor to said mobile processor over said serial interface to drop said modem process; downloading executable instructions from the control processor to the mobile processor; and executing said executable instructions to facilitate communication between the control processor and the mobile processor.

12. A method according to claim 11 , wherein the control processor and the mobile processor are encapsulated in a shared housing.

13. A method according to claim 12, wherein the mobile processor includes a display screen and said display screen is visible via a hole in said shared housing.

14. A method according to claim 13 wherein said command to power-up the mobile processor includes a first signal to supply power to the mobile processor and a second signal to effect a soft power-up, in which said soft power-up signal emulates the application of a power-on button.

15. A method according to claim 11 , wherein the control processor continually checks the operation of the mobile processor and re-issues the command to drop said modem process.

16. A method according to claim 11 , wherein communication between said control processor and said mobile processor occurs in the form of function strings having a pre-defined format.

17. A method according to claim 16, wherein the mobile processor and the control processor each include a robust message handler that only passes on received function strings that are compatible with said pre-defined format.

18. A programmable platform having interfaces for use in an embedded system, comprising: a mobile processor from a re-purposed mobile cellular telephone having a serial interface, a visual display and a modem functionality program; a control processor configured to receive input data and to communicate with said mobile processor via said serial interface; wherein said control processor is configured to: energise the^* mobile processor; de-activate said modem functionality program; activate data communication procedures; and communicate input data to said mobile processor; and said mobile processor is configured to: process input data received from the control processor; and supply output data to said visual display as a result of processing said input data.

19. A programmable platform according to claim 18, wherein said control processor also includes radio-frequency functionality for communicating over a radio network.

20. A generic programmable platform including an input interface and an output interface (I/O interfaces), comprising operational equipment from a mobile cellular telephone having a data interface and operating in accordance with proprietary protocols; a control processor having a second data interface connected to said first data interface; encapsulation for encapsulating said operational equipment and said control processor to form said generic platform, wherein; said control processor executes communication instructions to facilitate communication between said I/O interfaces and said operational equipment; and said operational equipment executes virtual machine instructions facilitate the execution of generic instructions upon a plurality of proprietary devices.

21. A method of producing a generic programmable platform substantially as herein described with reference to the accompanying drawings.

22. A programmable platform having interfaces for use in an embedded system substantially as herein described with reference to the accompanying drawings.