Facsimile and static presentation processing – Static presentation processing – Memory
Reexamination Certificate
1999-12-17
2003-10-14
Coles, Edward (Department: 2622)
Facsimile and static presentation processing
Static presentation processing
Memory
C358S468000, C358S001170
Reexamination Certificate
active
06633405
ABSTRACT:
BACKGROUND OF THE INVENTION
The invention relates to fax machines, printers, multifunction machines and other machines having print engines. More specifically, the invention relates to print controllers and code development for such machines.
During manufacture of fax machines, printers, multifunction machines and other machines including print engines, an original equipment manufacturer (“OEM”) purchases a “core.” The core typically includes print head drives, paper motor drives, carriage motor drives, paper sensors and flags, and controllers programmed with basic functions and variable values to control these core printing devices. The OEM then adds certain features to the core to produce a finished product. For example, different OEMs might add different cases and different paper path mechanisms to their fax machines.
The OEM may purchase some or all of these core components from a vendor. At a minimum, however, the OEM typically purchases, a print controller and print read-only memory (“ROM”) from the vendor because these components control the very basic, or low level, functions of the core printing devices. The remaining core components may be purchased from sources other than the print controller vendor.
The print ROM stores control code for controlling the print engine. The control code includes “generic” executable code and device-specific executable code.
During code development, the vendor generates the control code. If the OEM purchases core printing devices from a source other than the vendor, the device-specific code generated by the vendor might be different from the specific paper path of the OEM design.
The current practice is for the vendor to supply portions of source code to the OEM, and let the OEM modify the source code and determine final functions and variable values that work with the OEM's machine. If the default paper path is different than the paper path used by the OEM, the OEM modifies the vendor-supplied variable values and paper path functions. Once the device-specific code has been developed by the OEM, the OEM sends the modified device-specific source code (including the modified variable values and paper path functions) to the vendor. The vendor then compiles the entire source code, burns the compiled code into the print ROM, and delivers the print ROM back to the OEM. The print ROM is mounted in the OEM's machine.
Three problems are inherent in such code development. First, the vendor provides generic source code to the OEM, and the OEM provides device-specific source code to the vendor. Thus, each party exposes valuable intellectual property to the other. However, this approach is not desirable for a party who desires to protect its source code.
Second, the code development is performed sequentially, which takes time. Developing the vendor and OEM code in parallel would be faster and more efficient.
Third, the vendor customizes its print ROM for each OEM. Providing different print ROMs to different OEMs can be costly to the vendor.
SUMMARY OF THE INVENTION
These problems are overcome by the present invention. According to one aspect of the present invention, an apparatus includes a print engine having a first controller and scratch memory. A portion of the scratch memory is reserved for a jump table. The apparatus further includes a second controller. During startup of the apparatus, the second controller passes variable values and functions to the print controller. The print controller writes the variable values to specific locations in the jump table. The print controller also writes the functions to the scratch memory and writes starting addresses of these functions to specific locations in the jump table. The print controller uses the jump table to access the variable values and execute the functions. Thus, the jump table allows the second controller to share variables and functions with the first controller. Such an architecture allows code to be developed more efficiently. It also allows code to be protected, and the manufacturing cost of the print controller to be reduced.
REFERENCES:
patent: 4998960 (1991-03-01), Rose et al.
patent: 5402528 (1995-03-01), Christopher et al.
patent: 5537517 (1996-07-01), Wakabayashi et al.
patent: 5699494 (1997-12-01), Colbert et al.
patent: 5726770 (1998-03-01), Harada
patent: 5758124 (1998-05-01), Ogata et al.
patent: 5790860 (1998-08-01), Wetmore et al.
patent: 5809554 (1998-09-01), Benayon et al.
patent: 5813026 (1998-09-01), Borg et al.
patent: 5860156 (1999-01-01), Williams
patent: 5878275 (1999-03-01), Okada et al.
patent: 5915078 (1999-06-01), Miyasaka et al.
patent: 5937150 (1999-08-01), Phan
patent: 2 220286 (1990-01-01), None
patent: 2334606 (1999-08-01), None
Coles Edward
Hewlett--Packard Development Company, L.P.
Rahimi Alan
LandOfFree
Method and apparatus for interfacing generic and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for interfacing generic and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for interfacing generic and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3157044