WO1996007967A1

WO1996007967A1 - Interface including method and apparatus for remotely loading program code into the interface

Info

Publication number: WO1996007967A1
Application number: PCT/US1995/010542
Authority: WO
Inventors: Mark A. Lacas; David J. Warman; Richard S. Spirtes
Original assignee: Medialink Technologies Corporation
Priority date: 1994-09-09
Filing date: 1995-08-17
Publication date: 1996-03-14

Abstract

An interface apparatus (32, 30) that allows an electronic device (16) to communicate with one or more other electronic devices (14, 18, 22, 24) over a transmission medium (10) interconnecting the devices. The interface apparatus (32, 30) includes a first non-volatile memory (90), a second non-volatile memory (92) that is erasable and programmable, and a processor (90). The processor (90) uses program code (120, 122) stored in the first non-volatile memory (90) and the second non-volatile memory (92). The first non-volatile memory (90) contains communications program code (120) that allows the device (16) to communicate with other devices (14, 18, 22, 24), and the second non-volatile memory (92) is for storing additional program code (122) for controlling the functionality of the device (16). Another device (24) remotely loads new program code into the second non-volatile memory (92) by sending the new program code to the device (16) over the transmission medium (10). The processor (90) programs the new program code into the second non-volatile memory (92), and then performs an initialization sequence to begin executing the new program code along with the communication program code (120) in the first non-volatile memory (90).

Description

INTERFACE INCLUDING METHOD AND APPARATUS FOR REMOTELY LOADING PROGRAM CODE INTO THE INTERFACE

Field of the Invention This invention relates to interfaces for allowing an electronic device to communicate with one or more other electronic devices over a transmission medium and, more particularly, method and apparatus for remotely loading program code onto an interface.

Background of the Invention

Electronic devices that communicate with other devices over a transmission medium, e.g., a network, generally include interface electronics that allow the device to communicate over the transmission medium. Such interface electronics include a processor and a read-only memory (ROM) that permanently stores program code

(i.e., firmware) and data. The read-only memory is used because it is non-volatile, i.e., permanently stores the program code and data, even when the device is powered down. In contrast, if random access memory (RAM) is used, the program code and data would be lost when the device is powered down. The processor executes the program code contained on the read-only memory to control the communication of the device with other devices connected to the transmission medium. The read-only memory can also contain program code that is executed by the processor to control the functionality of the device itself. For example, an audio equalizer can be constructed with a processor that controls both the communication of the equalizer with other devices and the functionality of the equalizer.

While the use of read-only memory is beneficial in that the program code is not lost when the device is powered down, the use of read-only memory makes it difficult to modify the program code. In particular, if it is desired to change the program code, it is generally necessary to replace the read-only memory with a new read-only memory containing the desired program code. Unfortunately, this is expensive and inconvenient. While it is possible to use electrically erasable and programmable read-only memories ("EEPROM memory"), it is still necessary to remove the EEPROM memory and use a special device to reprogram the memory.

Interface electronics that allow loading new program code into a read-only memory exist; however, such interface electronics include extra read-only memory that is not needed during normal operation. The interface electronics include at least two read-only memories, at least one of which is •electrically erasable and programmable, i.e., a EEPROM memory. The EEPROM memory contains the program code that is used by the processor (in the interface electronics) during normal operation of the device to communicate with one or more other devices and possibly control the functionality of the device itself. The other read-only memory contains program code that is only used during loading of code into the EEPROM memory. In particular, to remotely load program code into the EEPROM memory, the processor is restarted using the program code in the other read-only memory. This program code starts a special communication protocol for receiving new program code over the transmission medium to which the device is connected. Upon receipt of the new program code, the processor reprograms the EEPROM memory with the new program code. The processor is then again restarted to execute the program code in the EEPROM memory. Because the other read-only memory is not used during normal operation of the device, this read-only memory represents overhead.

Furthermore, because a special communication protocol is used during the loading of new program code, normal communication cannot take place on a network to which the interface apparatus is connected during the remote loading of new program code over the network. Thus, normal operation of the network must be shutdown during downloading.

Other interface electronics that allow loading new program code into a read- only memory without the use of an extra read-only memory that is used only during loading of new program code exist. Such interface electronics use specialized code during the loading of new program code. In particular, the specialized code is loaded into random access memory (RAM) of the interface electronics, and the interface electronics is restarted so as to operate in accordance with the specialized code. Using this specialized code in RAM, new program code is loaded into the read-only memory. The drawbacks of such interface electronics are that they may require extra RAM, and because specialized code is used during loading, normal operation of the network over which loading is performed must be interrupted, i.e., the network must be shutdown.

What is needed is an interface apparatus whose program code read-only memory can be remotely updated, without the use of overhead memory. Furthermore, the program code should be organized into separate units so that individual units of the program code can be loaded, without changing the other units. Furthermore, the units of executable code should be connected together so that additional units of code can be loaded to modify the functionality of the device with which the interface apparatus is used. The remote updating should be accomplished using the normal communication protocol so that it is possible to perform the updating over a network, without interfering with normal operation of the network. As described in the following, the present invention provides an interface apparatus that meets these criteria and solves other shortcomings in the prior art. Summary of the Invention

In accordance with this invention, an interface apparatus that allows an electronic device to communicate with one or more other electronic devices over a transmission medium interconnecting the devices is provided. The interface apparatus includes a first non-volatile memory, a second non-volatile memory that is erasable and programmable, and a processor. The processor uses program code stored in the first non-volatile memory and the second non-volatile memory to control the functionality of the device, including its communication with other devices. The first non-volatile memory contains communication program code that allows the device to communicate with other devices, and the second non-volatile memory is for storing additional program code for controlling the functionality of the device along with the communication program code in the first non-volatile memory. Upon request, the processor programs new program code into the second non-volatile memory as follows. Another device sends new program code over the transmission medium connected to the device. Upon receiving the new program code, the processor programs the new program code into the second non-volatile memory, which is erasable and programmable. Then, the processor performs an initialization sequence to begin executing the new program code in the second non-volatile memory along with the communication program code in the first non-volatile memory.

In accordance with further aspects of the invention, the program code in the second non-volatile memory is connected to the communication program code in the first non-volatile memory. Prior to the processor programming new program code into the second non-volatile memory, the processor disconnects any program code in the second non-volatile memory from the communication program code in the first non-volatile memory, and the processor then performs the initialization sequence so that the processor executes the communication program code in the first non-volatile memory without the program code in the second non-volatile memory.

In accordance with still further aspects of the invention, because the communication program code stored in the first non-volatile memory is used during normal operation and during programming of the second non-volatile memory, the same communication protocol is used during normal operation and programming of the second non-volatile memory. As a result, remote programming of the second non-volatile memory can be accomplished over a network during normal operation of the network.

In accordance with still further aspects of the invention, the communication program code in the first non-volatile memory comprises a plurality of separate units of program code, and the program code in the second non-volatile memory comprises at least one separate unit of program code. The units of program code are connected as a linked list, and the initialization sequence includes sequencing through the linked list of units of program code so that any initialization required by each of the units of program code is performed. In accordance with still further aspects of the invention, each of the units of program code are classes defining program objects, i.e., the units follow the object- oriented programming paradigm.

In accordance with further aspects of the invention, the invention is also embodied as a method, carried out by the processor, of loading new program code into the second non-volatile memory of the interface apparatus, as previously described:

In accordance with further aspects of the invention, a method of loading a unit of program codes into a first electronic device from a second electronic device over a transmission medium interconnecting the first and second devices is provided. The first device includes a processor and memory. The memory contains communication program code used by the processor to allow the first device to communicate with the second device over the transmission medium. The memory can also store additional program code for use by the processor along with the communication program code for controlling the functionality of the first device. The communication program code and any additional program code comprise separate units of program code that are connected together as a linked list. The method of loading a unit of program code into the memory is executed by the processor and comprises receiving a unit of program code over the transmission medium. The processor then loads the unit of program code into the memory and adds the new unit of program code to the linked list. The processor then performs an initialization sequence that comprises sequencing through the linked list of units of program code so that the new program code is executed along with the communication program code to control the functionality of the first device.

As will be appreciated from the foregoing brief summary, an interface apparatus that allows a device to communicate with other devices over a transmission medium is provided. Program code can be remotely loaded into the apparatus to change the functionality of the apparatus. The apparatus includes a first non-volatile memory and a second non-volatile memory, which is erasable and programmable. Both of the non-volatile memories can be used during normal operation of the device with which the interface apparatus is associated. The communication program code stored in the first non-volatile memory is sufficient to allow the device to communicate with another device, to receive and load new program code into the second non-volatile memory. Accordingly, the apparatus does not require any overhead non-volatile memory. The same communication protocol is used during loading as during normal operation, so that the loading can be accomplished over a fully operational network, without shutting the network down. As will be still further appreciated from the foregoing brief summary, the program code contained in the first non-volatile memory and the second non-volatile memory is organized as separate units that are linked together, so that new units of code can be easily programmed into the second non-volatile memory, to change the functionality of the device. As will be further appreciated from the foregoing brief summary, the invention is also embodied as a method of loading new program code into the second non-volatile memory. Furthermore, the invention provides a method for loading individual units of code into an electronic device.

Brief Description of the Drawings The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIGURE 1 is a pictorial diagram of electronic devices interconnected in a bus network configuration with which the present invention can be used; FIGURE 2 is a block diagram of the electronic devices and bus network shown in FIGURE 1;

FIGURE 3 is a block diagram representation of two electronic devices interconnected in a point-to-point configuration with which the present invention can be used;

FIGURE 4 is a block diagram of an amplifier including an interface apparatus formed in accordance with the invention;

FIGURE 5 is a block diagram representation of a software/firmware paradigm that is preferably used in the interface apparatus provided by the present invention; FIGURE 6 is a flow diagram illustrating part of a startup initialization sequence for the interface apparatus provided by the invention; and

FIGURE 7 is a flow diagram of a method of remotely loading new program code into the interface apparatus, in accordance with the invention. Detailed Description of the Preferred Embodiment FIGURES 1 and 2 illustrate a bus network 10 interconnecting various electronic devices 12 with which the present invention can be used so that they can be controlled by signals on the network. The electronic devices shown include two audio amplifiers 14, 16, an audio equalizer 18, and two personal computers 22, 24. Other devices necessary to a complete sound system and their interconnection to the illustrated devices are not shown since they do not form part of this invention.

As shown in FIGURE 2, the personal computers 22, 24 are connected to the bus network 10 by way of bridges 26. In contrast, the amplifiers 14, 16 and the equalizer 18 each include an I/O board 30 and a processor board 32 formed in accordance with the invention to allow the devices to be directly connected to the bus network 10. FIGURE 3 illustrates a point-to-point configuration in which an amplifier 50 is connected to personal computer 52 by way of a cable 54 so that the personal computer can control the operation of the amplifier 50. For communicating with the personal computer 52, the amplifier 50 includes a processor board 32 and a I O board 58. The processor board 32 is the same type of processor board that is included in the devices 14, 16, 18 shown in FIGURE 2, and accordingly the same reference numeral is used. The I/O board 30 is specially constructed for use with the network configuration and a particular type of transmission medium 10, and the I/O board 58 is specifically constructed for use with the point-to-point configuration and a particular type of transmission medium 54. Each of the processor boards 32 shown in FIGURES 2 and 3 determines the type of I/O board to which it is connected, and based thereon, selects a unit of program code so that an appropriate communication protocol is used. In particular, the I/O boards 30, 58 include an electronic identifier 76, 80 that identifies the type of communication protocol with which the I/O boards 30, 58 should be used. Each processor board 32 stores units of program code for different communication protocols. The processor board 32 reads the electronic identifier on the I/O board that is connected to the processor board 32 to determine the appropriate communication protocol. Then, the processor board 32 executes the corresponding unit of program code. For example, in one actual embodiment, the processor board 32 contains a unit of program code for use with the bus network configuration of FIGURE 2. This unit of program code is selected for execution by the processor board 32 if the I/O board 30 shown in FIGURE 2 is present. The processor board 32 also contains a separate unit of program code for use with the point-to-point configuration of FIGURE 3, which is selected if the I/O board 58 shown in FIGURE 3 is present. Regardless of which communication protocol is used, new program code can be remotely loaded into the processor board 32. The processor board 32 includes a processor 90 and erasable and programmable non-volatile memory 92. The processor 90 also has on-board non-volatile memory. In one actual embodiment, the non-volatile memory on the processor 90 is read-only memory ("ROM memory"), and the non-volatile memory 92 is an electrically erasable and programmable read-only memory ("EEPROM memory"). The ROM memory contains program code for controlling the communication of the amplifier 16 with other devices. The EEPROM memory 92 contains application program code for use by the processor 90 for controlling the functionality of the amplifier 16. During normal operation both the ROM memory and EEPROM memory 92 are used.

With respect to the amplifier 16 for example, new program can be remotely loaded from the personal computer 22 into the EEPROM memory 92 of the amplifier 16. As explained in detail hereinafter, first the program code in the EEPROM memory 92 is "disconnected" from the program code in the ROM memory, and the processor 90 is restarted (i.e., an initialization sequence is executed) so that the processor 90 only uses the program code in the ROM memory. The personal computer 22 then sends new program code to the amplifier 16, which the processor 90 loads into the EEPROM memory 92. The processor 90 then "connects" the program code in the ROM memory to the program code in the EEPROM memory 92. The processor 90 is again restarted so that the program code in the ROM memory is used along with the new program code in the EEPROM memory 92. Inter-Device Communication With respect to FIGURE 2, the processor board 32 controls the communication of the devices 14, 16, 18 over the bus network 10. For example, if the equalizer 18 wants to send data, a command, or program code (collectively referred to herein as data), the processor board 32 housed in the equalizer 18 constructs a packet of data representing the desired information. The processor board 32 determines the time at which the bus network 10 is available for sending the packet. The processor board 32 sends the packet to the I/O board 30 at the appropriate time, and upon receipt of the packet, the I/O board 30 transmits the packet onto the bus network 10. At the amplifier 16, the I/O board 30 receives the packet over the bus network 10, and sends the packet to the processor board 32. Upon receipt of the packet, the processor board 32 processes the packet and performs any appropriate function, possibly including sending a response packet back to the equalizer 18. The processor boards 32 in the devices 14, 16, 18 are connected to other components in the devices to either control the devices directly or to control the devices in conjunction with other processors or controllers within the devices. For example, the amplifier 16 can include various analog electronics that are controlled by the processor board 32 based upon packets received over the bus network 10. Furthermore, while the processor board 32 is illustrated as a separate board, the components of the processor board 32 could be integrated into a larger board in the device, or the processor board 32 could be a section of a larger board.

The personal computers 22, 24 are not directly connected the bus network 10. Rather, the personal computers 22, 24 are connected via RS232 interfaces 34 and the bridges 26. Standard personal computers typically include an RS232 card 36 for communicating with external devices such as printers. RS232 is an interface standard that specifies signal voltage levels, etc. RS232 is also a byte-level communication protocol that specifies start bits, stop bits, etc. for sending bytes of data. Generally, a higher level communication protocol is used on top of the RS232 byte-level communication protocol.

As show in FIGURE 2, the personal computers 22, 24 each include an RS232 interface card 36 and an RS232 cable 38. The personal computers 22, 24 also include software defining a point-to-point communication protocol that is used on top of the RS232 byte-level protocol. The bridges 26 provide the interface between the RS232 cables 38 and the bus network 10. Each bridge 26 includes a RS232 I/O card 40 for connecting to the RS232 cable 38, and a second I/O card 42 that is constructed for connecting to the transmission medium of the bus network 10. The bridges 26 include a bridge processor board 44 connected to each of the I/O boards 40, 42, to translate between the point-to-point communication protocol and the bus network communication protocol used on the bus network 10. The bus network 10 shown in FIGURES 1 and 2 can be formed of various transmission media such as glass or plastic fiber optic cables, coaxial cables, twisted wire pair cables, ribbon cables, etc. the music industry it is generally preferable to use fiber optic cables, as fiber optic cables are highly immune to electromagnetic interference and are capable of carrying signals over long distances without significant attenuation. As described herein, the bus network 10 represents fiber optic cables. Accordingly, the I/O board 30 shown in FIGURE 2 is constructed for use with fiber optic cables. As previously explained, the I/O board 30 can be easily connected and disconnected from the processor board 32. If the transmission medium of the bus network 10 is changed, e.g., to coaxial cables, the I/O boards 30 are disconnected from the processor boards 32 and replaced with I/O boards that are constructed for connecting to coaxial cables. The processor boards 32 remain unchanged. With respect to the bridges 26, the I/O card 42 would be changed.

Various network communication protocols can be used to communicate over the bus network 10. The particular network conununication protocol used is dictated by the program code utilized by the processor boards 32 and the bridge processor boards 44. The communication protocol can be changed by changing the program code. In one actual embodiment of the invention, the network communication protocol used to communicate over the bus network 10 is that described in U.S. Patent No. 5,245,604, entitled "Communication System", assigned to the assignee of the present application. The contents of U.S. Patent No. 5,245,604 are hereby incorporated by reference, and the network communication protocol described by U.S. Patent No. 5,245,604 is referred to herein as the MediaLink protocol.

In this actual embodiment, the processor boards 32 contain program code for communicating over the bus network 10 in accordance with the MediaLink network communication protocol. The advantage of the MediaLink communication protocol is that it provides an upper limit on the amount of time it takes to communicate over the bus network 10. This is important in real-time environments such as a music performance stage, where unpredictable delay would result in unacceptable sound quality. As all network communication protocols must, the MediaLink protocol includes a network resource sharing and management algorithm such that only one device communicates over the bus network 10 at any one given time and such that each device has sufficient access to the bus network 10.

A resource and access management algorithm is obviously not needed when two devices are interconnected in a point-to-point configuration as shown in FIGURE 3. As previously described, in the point-to-point configuration shown in FIGURE 3 the amplifier 50 is connected to the personal computer 52 via the RS232 cable 54. The personal computer 52 includes the RS232 card 56 for communicating over the RS232 cable 54. The personal computer includes software that defines a high level, point-to-point communication protocol, which is used on top of the RS232 byte-level communication protocol. In one actual embodiment, the point-to-point communication protocol used is the same as the MediaLink network protocol, except that resource and access management of the MediaLink network protocol is excluded. This point-to-point communication protocol is referred to herein as the MediaWAN protocol. With respect to FIGURE 3, the amplifier 50 includes the I/O board 58 and the processor board 32, which is identical to the processor boards 32 illustrated in FIGURE 2. The I/O board 58 is similar to the I/O boards 30 shown in FIGURE 2, except that the I/O board 58 is constructed for use with a RS232 cable. The processor board 32 included in the amplifier 50 controls the communication of the amplifier 50 using separate program code for communicating in accordance with the MediaWAN point-to-point communication protocol.

With respect to FIGURE 2, the bridge processor boards 44 include program code for both the MediaWAN point-to-point communication protocol and the MediaLink bus network communication protocol. The MediaWAN and MediaLink protocols are simultaneously used to provide the interface from the RS232 cables 38 to the bus network 10.

The amplifier 50 shown in FIGURE 3 can be connected to the bus network 10 illustrated in FIGURE 2 by simply replacing the I/O board 58 with an I/O board 30, which is constructed for use with the bus network 10. The processor board 32 includes hardware and program code so that the processor board automatically senses the type of communication protocol to use based upon an identifier on the I/O board that is connected to the processor board 32.

Processor Board and I/O Board FIGURE 4 illustrates in greater detail the I/O board 30 and the processor board 32 in the amplifier 16 shown in FIGURES 1 and 2. The I/O board 30 includes two sets of plugs 64, 66, two drivers 72, 74, an electronic identifier 76, a shift register 75, and an application specific integrated circuit (ASIC) 73. The I/O board 30 is coupled to the processor board 32 by a ribbon cable 71. The processor board 32 includes a processor 90, an electronically erasable and programmable read¬ only memory (EEPROM) 92, a random access memory (RAM) 94, an application specific integrated circuit (ASIC) 73, and a timing clock (i.e., oscillator) 96.

With respect to the I/O board 30, the plugs 64, 66 are constructed to receive two fiber optic cables 68, 70, as shown in FIGURE 1. The drivers 72, 74 are respectively coupled to the plugs 64, 66 to produce light signals at the plugs to which the drivers are connected. The two sets of plugs 64, 66 are provided to allow the I/O board 30 to be used on a bus network 10, as illustrated in block diagram form in FIGURE 2. With fiber optic cables it is generally not possible to tap off of the cable. Rather, a fiber optic cable is connected at each of its ends to a device without any taps along the length of the cable. To form a bus network configuration, the devices are "chained" together by fiber optic cables, as shown in FIGURE 1. Except for the two devices at the ends of the "chain" of devices, two fiber optic cables are connected to each device, connecting the device to adjacent devices in the chain. Whenever a device communicates, the device produces light signals on both fiber optic cables. Similarly, if a device receives light signals on one cable, the device produces duplicate signals on the other cable. Functionally, the result is the bus network shown in FIGURE 2.

As is well known by those skilled in the pertinent art, a fiber optic cable consists of a send strand for sending signals and a receive strand for receiving signals. Each set of plugs 64, 66 includes a receive plug 61, 63 to which a receive strand is connected and a send plug 67, 69 to which a send strand is connected. The receive plugs 61, 63 include light sensors that produce corresponding electrical signals, and the send plugs 67, 69 include light emitters. The drivers 72, 74 are connected to the send plugs 67, 69.

The ASIC 73 is connected to the drivers 72, 74 and the receive plugs 61, 63. During normal operation, the ASIC 73 couples the receive plugs 61, 63 to the drivers 72, 74, such that when light signals (representing serial data) are received at the receive plug of one of the sets of plugs 64, 66, duplicate signals are produced at the send plug of the other set of plugs. Also during normal operation, serial data received at the receive plugs 61, 63 is "piped" through the ASIC 73 to the processor 90, via the ribbon cable 71. The processor 90 includes a serial universal asynchronous receiver/transmitter (UART) that receives the serial data. The UART converts the serial data to parallel bytes of data which are processed by the processor 90. When the amplifier 16 wants to send data to other devices on the bus network, the processor board 32 generates a packet of data that consists of several bytes of data. The bytes of data are converted into a serial stream of digital electrical signals by the UART. The serial data produced by the UART is sent to the ASIC 73, which pipes the serial data to both drivers 72, 74, so that the data is simultaneously sent out each of the send plugs 67, 69.

The ASIC 73 is also provided to allow for various test modes, e.g., an internal loop-back mode, and an external loop-back mode. For example, during an internal loop-back mode, the ASIC 73 sends any received serial data signals from the processor 90 back to the processor 90, instead of to the send plugs 67, 69. The mode of the ASIC 73 is controlled by the processor 90 via the shift register 75. The shift register 75 is used to allow a serial control line of the processor 90 to control the ASIC 73, which requires parallel control lines. For example, in one actual embodiment, the ASIC 73 requires four parallel lines (bits) to select its mode. The shift register 75 shifts four bits sent over the serial control line of the process 90 into four bits, which are applied to the ASIC 73.

The electronic identifier 76 included on the I/O board 30 identifies the communication protocol (e.g., the MediaLink or MediaWAN protocol) and the baud rate with which the I O board 30 is constructed to be used. In one actual embodiment, the electronic identifier 76 is a dip switch set to identify the baud rate and the communication protocol. However, those skilled in the pertinent art will readily recognize that other devices could easily be used to serve as the identifier 76. For example, the electronic identifier 76 could be formed of electronic circuitry wired to uniquely identify the baud rate and communication protocol. The identifier 76 could also be formed of a small memory device storing one or more bytes of data to uniquely identify the baud rate and communication protocol. With respect to the use of a dip switch for the electronic identifier 76, multiple pins on the dip switch must be read to determine the identification provided by the dip switch. The shift register 75 is connected to these pins, and converts the parallel data into serial data that is sent to the processor 90.

In one actual embodiment, one end of the ribbon cable 71 is secured to the processor board 32 and the I/O board 30 includes a connector to which the other end of the ribbon cable 71 can be connected. The ribbon connector 71 can be disconnected from the I O board 30, so that a different I/O board can be connected to the processor board 32. In one actual embodiment of the invention, at least two types of I/O boards are provided, one for use with a bus network communication protocol (e.g., the MediaLink protocol) and the other for use with a point-to-point communication protocol (e.g., the MediaWAN protocol). The I/O board 30 shown in FIGURE 4 is constructed for use with a bus network communication protocol at a 125k baud rate, with the bus network 10 formed of fiber optic cables. The I/O board 58 shown in FIGURE 3 is constructed for use with a point-to- point communication protocol, with the transmission medium formed of the RS232 cable 54. The I/O board 58 contains the same basic components as the I/O board 30, except as follows. The I/O board 58 has a single plug 82, to which the RS232 cable 54 is connected. Because there is only a single plug 82, the I/O board 58 includes only one driver 84 (a RS232 driver), which is connected to the plug. As with the I/O board 30, the I/O board 58 includes a shift register 81 and an ASIC 83, and is connected to the processor board 32 by a ribbon cable 87. The I/O board 58 includes an electronic identifier 80 that identifies the point-to-point communication protocol and the baud rate with which the I/O board is constructed to be used. In one actual embodiment of the invention, two types of I/O boards for use with the RS232 cable are provided: one mnning at 125k baud; and the other running at 9600 baud.

With respect to the processor board 32, the processor 90 preferably includes read-only memory (ROM) that stores program code for controlling the communication of the amplifier 16 with other devices. The EEPROM 92 on the processor board 32 contains application program code for use by the processor 90 for controlling the functionality of the amplifier 16. The RAM 94 is used by the processor 90 during operation to temporarily store data and some program code. The clock 96 generates a timing signal upon which the operation of the processor 90 is based. The ASIC 83 on the processor board 32 decodes address lines from the processor 90 to control the processor's access to the EEPROM 92 and RAM 94.

During startup initialization of the processor board 32, the processor board 32 reads the electronic identifier 76 on the I/O board 30 to determine the baud rate and the communication protocol that are to be used, and selects the corresponding program code stored within the processor 90. In one actual embodiment of the invention, the processor board 32 supports the MediaLink bus network communication protocol and the MediaWAN point-to-point communication protocol. The MediaLink bus network communication protocol is used with the bus network 10 shown in FIGURES 1 and 2, and the MediaWAN communication protocol is used with the point-to-point configuration shown in FIGURE 3. Thus, if the processor board 32 determines during startup initialization that the I/O board 30 is present, the MediaLink bus network communication protocol is followed, and if the I/O board 58 is present, the MediaWAN communication protocol is followed.

Readily available digital and analog electronic components can be used to form the components of the I/O boards 30, 58 and the processor board 32 shown in FIGURES 3 and 4. For example, in one actual embodiment, the processor 90 is one of the HCl l family of chips manufactured by Motorola, in particular, the 68HC711E9, which includes on-board ROM for storing program code used by the processor 90 for communication. The EEPROM 92 can be an KM28C64-20 chip manufactured by Samsung, which is desirable because it can be reprogrammed using standard digital voltages. Persons skilled in the relevant art will readily recognize that some additional electronics not shown, e.g., resistors, capacitors, latches, etc. are needed to implement the I/O boards 30, 58 and the processor board 32 at the circuit level. Such persons will also readily know how to interconnect the various components at the circuit level. Accordingly, to avoid unduly complicating the present disclosure, these details are omitted.

Bridge

The circuitry of the bridges 26 illustrated in block diagram form in FIGURE 2 includes many of the same components as the processor board 32 and the I/O cards 30, 58. The bridge processor board 44 includes a processor chip 100, e.g., one of the HCll family of Motorola processors. The bridge processor board 44 also includes a tuning clock 102, a RAM 104, and a EEPROM 106. The I O board 42 is similar in structure to the I O board 30, and the I/O board 40 is similar in structure to the I/O board 58. Each of the I/O boards 40, 42 include appropriate plugs for connecting to the type of external cable to which they are intended to be connected. The I/O board 42 includes fiber optic cable plugs for connecting to the bus network 10, and the I/O board 40 has an RS232 plug for connecting to the RS232 cable 38. The I/O board 40 includes a RS232 driver 108, and the I/O board 42 includes two fiber drivers 110 and 112. The processor chip 100 includes a UART port that is used to send and receive serial data from the I O board 42. The bridge processor board 44 also includes an external UART (not shown) for sending and receiving serial data from the I/O board 40.

The I O boards 40, 42 also include electronic identifiers (not shown) to identify the transmission medium and communication protocol with which the I/O boards 40, 42 are intended to be used. At start-up initialization of the bridge 26, the bridge processor board 44 determines the type of I O boards present and selects the appropriate program code, as described with respect to the processor board 30. To make the bridge 26 compatible with a different transmission medium and/or communication protocol, the I/O board 40, 42 could be replaced with appropriate I/O boards. As is the case with respect to the processor board 32 and I/O board 30 shown in FIGURE 4, the circuit-level implementation of the bridge can be carried out in various ways, as will be readily appreciated by those skilled in the pertinent art.

Program code can be loaded into the EEPROM 106 on the bridge processor board 44 in the same manner as for the EEPROM 92 on the processor board 32. For example, the personal computer 22 can remotely load program code into the EEPROM 106 in the bridge 26 that is connected to the personal computer 24. Program Code Paradigm

FIGURE 5 illustrates the organization of the program code within one actual embodiment of the processor board 32 shown in FIGURE 4. The program code is organized into units (referred to herein as SoftSlots) in the ROM memory in the processor 90 and in the EEPROM memory 92. The SoftSlots 120, 122 are based in part upon the object-oriented programming paradigm in that each SoftSlot 120, 122 is a class defining variables and methods (i.e., functions). Instances, i.e., objects, of each SoftSlot are formed by instantiation. A SoftSlot can be defined as a parent or child of another SoftSlot, so that inheritance of variables and methods is possible. These aspects of the SoftSlots will be readily recognized by those skilled in object-oriented programming.

In addition to the object-oriented paradigm of the SoftSlots, the SoftSlots 120, 122 are organized as a linked list. In particular, begmning with the TAPCORE SoftSlot 124 in the ROM memory of the processor 90 and ending with the SoftSlot 126 in the EEPROM memory 92, each SoftSlot points to a subsequent SoftSlot. At start-up, the SoftSlots are sequenced through in the order of the linked list. As each SoftSlot is processed, each SoftSlot performs certain needed hardware and software initialization. After the initialization is performed, instances (i.e., objects) of the SoftSlots are created. During normal operation of the processor board 30, the objects perform various functions, including creating additional objects, for controlling the functionality and communication of the device in which the processor board 30 is housed.

The program code provided by the SoftSlots forms the basic operating system of the processor 90, controls the communication of the device in which the processor board 32 is housed, and possibly controls the functionality of the device. The operating system is a multi-tasking operating system that organizes tasks in a task ring, in which the tasks are sequentially executed. The SoftSlots included in one actual embodiment of the invention are illustrated in FIGURE 5 and briefly described next. The actual program code in each SoftSlot can be implemented in various ways, as will be appreciated by those skilled in the pertinent art. The TAPCORE SoftSlot 124 is an ancestor of all other SoftSlots and includes basic operating system methods and variables. In the linked list of SoftSlots for startup initialization, the TAPCORE SoftSlot 124 is the first SoftSlot and it points to the EVENT SoftSlot 126. The EVENT SoftSlot 126 is a child of the TAPECORE SoftSlot and defines variables and methods for providing the multi¬ tasking task ring. In the linked list, the EVENT SoftSlot points to the I/O PORT SoftSlot 128. The I/O PORT SoftSlot 128 is a also child of the TAPCORE SoftSlot. It is a virtual SoftSlot in that during normal operation no instances of the I/O PORT SoftSlot are created. Rather, the I/O PORT SoftSlot defines variables and methods that are inherited by SoftSlots that are descendants of the I/O PORT SoftSlot. The variables and methods defined by the I/O PORT SoftSlot support interfacing the I/O board 30. The I/O PORT SoftSlot points to the PACKET SoftSlot 130 in the linked list.

The PACKET SoftSlot 130 provides variables and methods that define packets, which are the unit of information communicated between devices in the MediaLink and MediaWAN communication protocols. The PACKET SoftSlot is a child of the EVENT SoftSlot, so that packets are events that control the execution of themselves. The PACKET SoftSlot 130 points to the UART SoftSlot 132, which defines variables and methods for controlling the UART within the processor 90. The UART SoftSlot is a child of the IO Port SoftSlot.

The UART SoftSlot 132 points to the MEDIALINK SoftSlot 134, which in turn points to the MEDIAWAN SoftSlot 136. The MEDIALINK and MEDIAWAN SoftSlots 134, 136 are each a child of the IO Port SoftSlot. The MEDIALINK SoftSlot provides variables and methods that define the MediaLink bus network communication protocol, and the MEDIAWAN SoftSlot provides variables and methods that define the MediaWAN point-to-point communication protocol, supporting a 125k baud rate, a 9600 baud rate, and other baud rates. The communication protocol used during normal operation of a device is also used during loading of new program code into the EEPROM 92 of a device. Thus, the program code provided by the MEDIALINK and MEDIAWAN SoftSlot is used during the loading of new program code. The MEDIAWAN SoftSlot 136 points to the Virtual Device Management

(VDM) SoftSlot 138, which is a child of the TAPCORE SoftSlot. The VDM SoftSlot 138 provides variables and methods that identify the type of device, e.g., an amplifier, that the processor board 32 is housed in, and the VDM SoftSlot 138 provides methods that allow the device to identify itself when queried by other devices. The VDM SoftSlot 138 also provides methods that allow the processor 90 to write to the RAM 94 and program the EEPROM memory 92 on the processor board 32. Thus, the methods provided by the VDM SoftSlot 138 are used during loading of new program code into the EEPROM memory 92.

The VDM SoftSlot 138 points to the NULL APP SoftSlot 140, which is the last SoftSlot within the processor 90. The NULL APP SoftSlot 140 is a child of the TAPCORE SoftSlot and provides variables and methods that define a generic device. The functionality and identity of the device in which the processor board 32 is housed is defined by the NULL APP SoftSlot, unless there is one or more APPLICATION SoftSlots 122 within the EEPROM 92.

The NULL APP SoftSlot 140 points to the first APPLICATION SoftSlot 142 in the EEPROM 92, if there is one. More particularly, the NULL APP SoftSlot 140 points to a memory location in the EEPROM 92 that points (i.e., contains the memory address location) of the first APPLICATION SoftSlot 142; the bytes at this memory location are referred to herein as Link bytes. If there are no APPLICATION SoftSlots or any other SoftSlots in the EEPROM 92, the Link bytes contain zeros. In this case, during start-up initialization of the processor board 32, a detennination is made that the device should run as a generic device as defined by the NULL APP SoftSlot 140. In contrast, if there are one or more APPLICATION SoftSlots 122 within the EEPROM 92, they define the identity and functionality of the device in which the processor board 32 is housed. The parent-child relationship of the APPLICAΗON SoftSlots 122 depends on the nature of the particular APPLICATION SoftSlot.

In addition to containing APPLICAΗON SoftSlots 122 to define the functionality of the device, the EEPROM 92 can contain SoftSlots that override a portion of the program code provided by the various SoftSlots 120 within the processor 90. For example, if it is desired to change a portion of the MEDIALINK SoftSlot 134, a SoftSlot can be electrically programmed into the EEPROM 92 to patch or override the desired portion of the MEDIALINK SoftSlot 134.

Method of Loading New Program Code FIGURE 6 illustrates a portion of the initialization performed by the processor 90 at start-up. In particular, FIGURE 6 illustrates how the device (e.g., amplifier 16) runs as a generic device or some other device, depending upon whether there is an APPLICAΗON SoftSlot in the EEPROM 92. The start-up initialization includes sequencing through the linked-list of SoftSlots 120, 122 illustrated in FIGURE 5. As illustrated in FIGURE 6, first a series of software and hardware initialization steps 150 are performed by SoftSlots positioned prior to the NULL APP SoftSlot 140 in the linked-list of SoftSlots.

Then, at block 152, program code provided by the NULL APP SoftSlot 140 reads the Link bytes in the EEPROM 92, and as indicated by the decision diamond 154, a determination is made as to whether the Link bytes are zeroed. As indicated at block 156, if the Link bytes contain only zeros, the device is run as a generic device, as defined by the NULL APP SoftSlot 140. In contrast, the Link bytes point to an APPLICAΗON SoftSlot, the device is run as specified by the APPLICAΗON SoftSlot, as indicated at block 158.

FIGURE 7 is a block diagram of a method of remotely loading a SoftSlot into the EEPROM 92, in accordance with one actual embodiment of the invention. For illustration purposes, the method will be described with respect to the personal computer 24 loading a SoftSlot into the EEPROM 92 of the amplifier 16, shown in FIGURES 1 and 2. First, at the personal computer 24, the SoftSlot that is to be loaded into the EEPROM 92 is selected, and the target device (i.e., amplifier 16) that is to receive the SoftSlot is selected, as indicated at blocks 200 and 202. These selections may be made by a person operating the personal computer 24, or the selections may be programmed into a script executed by the personal computer 24.

Next, as indicated at the decision diamond 204, the personal computer 24 determines whether compatible SoftSlots are stored in the EEMPROM 92 of the target device (i.e., amplifier 16). This comprises sending a query to the amplifier 16 over the bus network 10, asking the amplifier 16 to identify the SoftSlot types and version numbers in the EEPROM 92. The amplifier 16 sends a response back to the personal computer 24 over the bus network 10. The personal computer 24 then determines whether the SoftSlot that is to be loaded into the EEPROM 92 is compatible with the existing SoftSlots in the EEMPROM 92. If the SoftSlot that is to be loaded is not compatible, the loading process is ended, as indicated by block 206. On the other hand, if the SoftSlot is compatible, it is loaded into the EEPROM 92, as indicated by blocks 208-218 and explained below.

Checking the types and versions of SoftSlots in the EEPROM 92 is not necessary in some instances. For example, if all existing SoftSlots in the EEPROM 92 are to be either erased or overwritten, the types and versions of existing SoftSlots in the EEPROM 92 is irrelevant. Generally, it is only necessary to check the types and versions of SoftSlots that are not going to be removed by the loading of the new SoftSlot into the EEPROM 92. In some situations it may also be necessary to check the types and versions of the SoftSlots in the ROM of the processor 90. This is not necessary if all processors are known to contain the same SoftSlots. The loading of the selected SoftSlot is begun by the personal computer 24 instructing (via a message) the amplifier 16 to disconnect the SoftSlots in the EEPROM 92 from SoftSlots in the ROM of the processor 90, as indicated at block 208. The amplifier 16 disconnects the SoftSlots in the EEPROM 92 by filling the Link bytes linking the NULL APP SoftSlot 140 in the processor ROM to the APPLICAΗON SoftSlots in the EEPROM 92, as explained above with respect to FIGURE 5. The personal computer 24 then instructs the amplifier 16 to perform its start-up initialization sequence, as indicated at block 210. With the EEPROM 92 SoftSlots disconnected, the amplifier 16 restarts as a generic device, as defined by the NULL APP SoftSlot; the SoftSlots in the EEPROM 92 are not used. As indicated by blocks 212 and 214, the personal computer 24 pauses before sending the selected SoftSlot to the amplifier 16 so as to allow the amplifier 16 sufficient time to re-start as a generic device. After sending the selected SoftSlot, the personal computer again pauses to allow the amplifier 16 sufficient time to program the SoftSlot into its EEPROM 92, as indicated by block 216. When the amplifier 16 receives the selected SoftSlot, the processor 90 programs the SoftSlot into the EEPROM 92. The processor 90 adds the newly loaded SoftSlot to the linked list of any other SoftSlots remaining in the EEPROM 92. The processor 90 also updates the Link bytes in the EEPROM 92 so that the NULL APP SoftSlot in the processor ROM is linked to the SoftSlots in the EEPROM 92. To complete the SoftSlot loading process, the personal computer 24 instructs the amplifier 16 to re-start, as indicated at block 218. Upon receipt of the instruction, the processor 90 performs its start-up initialization sequence. As previously described, this involves sequencing through the linked list of SoftSlots in the processor ROM and the EEPROM 92. Thus, the operation of the processor 90 is governed by the SoftSlots in the processor ROM and the new SoftSlot and any other SoftSlots in the EEPROM 92. For example, the newly loaded SoftSlot may define the functionality of the amplifier 16. Thus, in accordance with the invention, it is possible to remotely change the functionality of the amplifier 16 by loading a new SoftSlot into the amplifier 16. It is also possible to change certain portions of the SoftSlots in the processor ROM by loading "patch" SoftSlots into the EEPROM 92 to override certain portions of SoftSlots in the processor ROM. While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention. For example, in place of EEPROM 92 and the processor ROM, a single electronically erasable and programmable read-only memory device (i.e., single package) could be used. The memory device would have two sections, one corresponding to the EEPROM 92 and the other corresponding to the processor ROM. The memory device would have to allow reading of one section during the loading of the other section. Hence, within the scope of the appended claims, it is to be understood that the invention can be practiced otherwise than as specifically described herein.

Claims

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. An apparatus for allowing an electronic device to communicate with at least one other electronic device over a transmission medium interconnecting the device and said at least one other electronic device, said apparatus including:

(a) a first non-volatile memory containing communication program code that allows said device to communicate with said at least one other device over said transmission medium;

(b) a second non-volatile memory that is programmable, for storing additional program code for controlling the functionality of said device along with said communication program code; and

(c) a processor for:

(i) executing said communication program code, and for executing said additional program code along with said communication program code when said additional program code is present in said second non-volatile memory; and

(ii) programming said additional program code into said second non-volatile memory by: receiving said additional program code over said transmission medium from said at least one other device; progπuriming said additional program code into said second non-volatile memory; and performing an initialization sequence to execute said additional program code along with said communication program code.

2. The apparatus of Claim 1, wherein said additional program code is connected to said communication program code, and wherein prior to said processor programming said additional program code into said second non-volatile memory, said processor: disconnects said additional program code from said communication program code; and performs said initialization sequence to run said communication program code without said additional program code.

3. The apparatus of Claim 1, wherein said communication program code comprises a plurality of separate units of program code and said additional program code comprises at least one separate unit of program code, wherein said plurality of separate units of program code and said at least one separate unit of program code are connected as a linked list, and wherein said initialization sequence comprises sequencing through said linked list.

4. The apparatus of Claim 3, wherein each of said plurality of separate units of program code and said at least one separate unit of program code are classes defining program objects.

5. The apparatus of Claim 1, wherein said first non-volatile memory and said processor are each part of one semiconductor chip.

6. The apparatus of Claim 1, wherein said communication program code is used by said processor to communicate with said at least one other device in accordance with a particular communication protocol, and wherein said processor also follows said communication protocol during said programming said additional program code into said second non-volatile memory.

7. An apparatus for allowing an electronic device to communicate with at least one other electronic device over a transmission medium interconnecting the device and said at least one other electronic device, said apparatus including:

(a) memory containing communication program code that allows said device to communicate with said at least one other device over said transmission medium, said memory also storing additional program code for controlling the functionality of said device along with said communication program code, wherein said communication program code comprises a plurality of separate units of program code and said additional program code comprises at least one separate unit of program code, wherein said plurality of separate units of program code and said at least one separate unit of program code are connected as a linked list; and

(b) a processor for:

(i) executing said communication program code, and for executing said additional program code along with said communication program code when said additional program code is present in said memory; and

(ϋ) loading said at least one separate unit of program code into said memory by: receiving said at least one separate unit of program code over said transmission medium from said at least one other device; storing said at least one separate unit of program code in said memory; adding said at least one separate unit of program code to said linked list; and performing an initialization sequence comprising sequencing through said linked list to run said additional program code along with said communication program code to control the functionality of said device.

8. The apparatus of Claim 7, wherein each of said plurality of separate units of program code and said at least one separate unit of program code are classes defining program objects.

9. The apparatus of Claim 7, wherein said communication program code is used by said processor to communicate with said at least one other device in accordance with a particular communication protocol, and wherein said processor also follows said communication protocol during said loading said at least one separate unit of program code into said memory.

10. The apparatus of Claim 7, wherein prior to said processor loading said at least one separate unit of program code into said memory, said processor: disconnects said additional program code from said communication program code in said linked list; and performs said initialization sequence to run said communication program code without said additional program code.

11. A method of loading a unit of program code from a first electronic device into a second electronic device over a transmission medium interconnecting at least said first and second devices, said second device including a first non-volatile memory, and an second non-volatile memory, said first non-volatile memory containing communication program code used by said processor of said second device to allow said second device to communicate with said first device over said transmission medium, said second non-volatile memory for storing additional program code for use by said processor of said second device along with said communication program code for controlling the functionality of said second device, said method comprising the steps of:

(a) said first device sending a unit of program code to said second device over said transmission medium; (b) said first device instructing said second device to program said unit of program code into said second non-volatile memory, so that said additional program code comprises said unit of program code; and

(c) said first device instructing said second device to perform an initialization sequence to run said additional program code along with said communication program code to control the functionality of said second device.

12. The method of Claim 11, wherein during a normal operation said first device and said second device communicate with each other in accordance with a particular communication protocol, said processor of said second device using said communication program code, and wherein said first device and said second device also communicate in accordance with said particular communication protocol during said method of loading a unit of program code.

13. The method of Claim 11, wherein said additional program code is connected to said communication program code, and wherein said method further comprises, prior to said step of said first device sending a unit of program code, the steps of: said first device instructing said second device to disconnect said additional program code from said communication program code; and said first device instructing said second device to perform said initialization sequence to run said communication program code without said additional program code.

14. The method of Claim 13, wherein said method further comprises said first device verifying that said unit of program code is compatible with said second device prior to said step of said first device instructing said second device to disconnect said additional program code.

15. The method of Claim 11, wherein said method further comprises said first device verifying that said unit of program code is compatible with said second device prior to said step of said first device sending a unit of program code.

16. The method of Claim 11, wherein said communication program code comprises a plurality of separate units of program code and said additional program code comprises at least one separate unit of program code, wherein said plurality of separate units of program code and said at least one separate unit of program code are connected as a linked list, and wherein said initialization sequence comprises sequencing through said linked list.

17. The method of Claim 16, wherein each of said plurality of separate units of program code and said at least one separate unit of program code are classes defining program objects.

18. A method of loading a unit of program code from a first electronic device into a second electronic device over a transmission medium interconnecting at least said first and second devices, said second device having a processor and memory, said memory containing communication program code used by said processor to allow said second device to communicate with said first device over said transmission medium, said memory also for storing additional program code for use by said processor along with said communication program code for controlling the functionality of said second device, wherein said communication program code comprises a plurality of separate units of program code and said additional program code comprises at least one separate unit of program code, wherein said plurality of separate units of program code and said at least one separate unit of program code are connected as a linked list, said method comprising the steps of:

(a) said first device sending a unit of program code to said second device over said transmission medium;

(b) said first device instructing said second device to program said unit of program code into said memory and add said unit of program code to said linked list, so that said at least one separate unit of program code comprises said unit of program code; and

(c) said first device instructing said second device to perform an initialization sequence to sequence through said linked list to execute said additional program code along with said communication program code to control the functionality of said second device.

19. The method of Claim 18, wherein each of said plurality of separate units of program code and said at least one separate unit of program code are classes defining program objects.

20. The method of Claim 18, wherein during a normal operation said first device and said second device communicate with each other in accordance with a particular communication protocol, said processor of said second device using said communication program code, and wherein said first device and said second device also communicate in accordance with said particular communication protocol during said method of loading a unit of program code.

21. The method of Claim 18, wherein said method further comprises, prior to said step of said first device sending a unit of program code, the steps of: said first device instructing said second device to disconnect said additional program code from said communication program code in said linked list; and said first device instructing said second device to perform said initialization sequence to run said communication program code without said additional program code.

22. The method of Claim 21, wherein said method further comprises said first device verifying that said unit of program code is compatible with said second device prior to said step of said first device instructing said second device to disconnect said additional program code.

23. The method of Claim 18, wherein said method further comprises said first device verifying that said unit of program code is compatible with said second device prior to said step of said first device sending a unit of program code.