Direct Interface Between Fuel Pump and Computer Cash/Register

This invention relates generally to fuel dispensing pumps, and more particularly to a control system for such pumps, especially to such a control system which utilizes a personal computer to exchange information with a smart fuel pump, including a dispenser and/or a user debit or credit card accepter device. More particularly, the invention relates to an interface unit to regulate the exchange of information between the personal computer and the smart fuel pump.

Smart fuel pumps have been developed which are capable of receiving commands from a remote control device, such as a computer. Such commands may include a limit on the amount of gas that may be dispensed, the limit relating to the prepaying of that amount by the customer, a price per unit volume of gasoline, and the like. Such fuel pump may additionally provide status information to the computer such as the amount of fuel dispensed, whether the pump is active or "down", or the like. In addition, to having a dispenser, such smart fuel pump may additionally include a card accepter which reads a magnetic strip on a user debit card, or credit card, to allow the user to prepay for the gasoline purchase from the location of the fuel pump, remote from the computer/cash register.

An interface unit is required to handle the communication from the computer/cash register to the fuel pumps. Because of the physical separation, a universal asynchronous receiver/transmitter (UART) is typically provided to transmit and receive information to/from the remote fuel pumps which are arranged in a current-loop with each fuel pump assigned a unique address. Data exchange between the computer and adaptor box is typically in serial fashion using a standard interface format, such as an RS-232 format. This arrangement has proved to be extremely slow because all data must be converted to serial format and communicated one word at a time. Furthermore, the multiple fuel pumps on the current loop may only be addressed one device at a time from the computer to the interface unit which, in turn processes the information prior to sending it to the fuel pumps, and visa versa. This arrangement is not only exceptionally slow, but is also unreliable. A fault in any one dispenser or card reader can shut down the entire current loop, which typically is the entire system. Furthermore, it is inflexible in that any modifications to the system must be installed by a field-service representative who must physically gain access to the adapter box.

One form of computer that is gaining universal acceptance is the personal computer, or PC. A PC is especially adapted to controlling a fuel dispensing terminal because the PC may additionally handle the cash register function, payroll and inventory for the associated convenience store. A PC typically includes an expansion bus and a plurality of edge card connecters for allowing peripheral devices to directly interface with the PC. Interface circuits engaging the PC bus typically utilize a dual-ported direct memory access (DMA) in which a single memory device is accessible from the PC through the first port or a microprocessor, residing on the interface board through the second port. The direct memory access (DMA) occupies a location in the memory map of the PC and is under the control of the PC, with access granted to the on-board microprocessor by the PC through interrupts generated by the on-board microprocessor. This arrangement has many drawbacks. Not only does the DMA occupy space in the PC memory map, but the supervision of the DMA by the PC is a considerable task, which slows multi-tasking functions within the PC. Furthermore, the on-board microprocessor is required to operate at the same clock speed as the PC, whether or not this is most efficient for the functions being performed by the microprocessor. On a practical level, the DMA chip-set is expensive. Furthermore, there is only a defacto standard for PC bus format. Because there are no true industry standards, there are risks that the caveats required for the DMA may not be completely satisfied by all PCs. Therefore, it cannot be ensured that a DMA-based interface unit is truly universally compatible with all PC's.

The present invention provides a direct interface between a computer, such as a personal computer, and one or more material dispensers, such as fuel pumps. The interface includes an on-board controller means for communicating with the dispensers and means for providing communication between the controller and the computer. This latter means includes a memory means and access means for allowing the controller and the computer to each access the memory means such that the controller and the computer can write data to, and retrieve data from, the memory means.

According to one aspect of the invention, the interface unit includes a window memory means having an access port and access control means for selectively connecting the access port with either the interface controller or the computer peripheral bus, such that either the controller or the computer may access the memory means at a time. Because of this controlled access, it can readily be ensured that complete messages will be transferred without interruption. Furthermore, the requirement for a common clock cycle between the computer and the controller means is eliminated. Therefore, the controller means can operate at a slower, or if desirable, a faster clock rate than the computer system. In one embodiment, the access control means includes a control port to pass requests for access to the window memory between the computer and the controller.

According to another aspect of the invention, the access control means for the window memory means is substantially controlled by the on-board interface controller. This frees up the computer system for other tasks. Furthermore, in one embodiment of the invention, the controller is not multi-tasked. Accordingly, the controller is dedicated to its interface function to provide a greater level of confidence in data integrating. Because its interface function includes control of the window memory means, the opportunity for other errors is also significantly reduced.

According to yet another aspect of the invention, the interface unit includes a database memory which is repetitively updated by data received from the fuel pumps. Messages from the computer are applied to the database rather than to the fuel pumps. In this manner, communication speeds are increased. Normal polling communication between: the interface unit and the computer does not get processed through the dispenser communication loop. Communications with the fuel pump is ongoing and not initiated upon request from the computer. However, certain specific commands initiated by the computer will cause the interface unit to initiate priority communications with the fuel pumps. The database may include an internal database accessed only by the on-board controller and a mirror image of the internal database residing in the window memory shared between the PC and the interface unit. The internal database is periodically written to the shared memory to keep the shared memory current.

In one embodiment of the invention, a plurality of UARTs are provided for simultaneous operation by the controller. Each UART is further multiplexed to sequentially operate a plurality of control loops, each control loop including a single fuel pump, which may include a dispenser and a card reader. This allows multiple fuel pumps to be addressed concurrently and prevents a fault in any fuel pump from degrading the entire system.

The present invention is exceptionally fast because it eliminates the serial interface between the computer and the interface circuitry. Additionally, the ability to address multiple fuel pumps at a time increases system speed. An interface unit, according to the invention, is not format-specific to any personal computer and doesn't require a significant amount of the computer's processing time, which frees the computer for faster response to other tasks. In fact, the PC is freed of any supervisory tasks for the interface and may treat this dispensing system as a peripheral device. The invention allows updates of the operating code for the interface controller to be down-loaded from the computer through the window memory means. The modified operating code may be down-loaded to internal memory through the window memory, a portion at a time, in a bucket-brigade fashion. This allows updates to the system to be implemented through any means of communication with the computer, including down-loading through a MODEM over telephone lines, avoiding the necessity of field-service technicians accessing the interface unit for upgrade modification.

These and other objects, advantages and features of this invention will become apparent upon review of the following specification in conjunction with the drawings.

FIG. 1 is a block diagram of a dispensing system according to the invention;

FIGS. 2A, 2B and 2C are block diagrams of an electrical control circuit of an interface unit according to the invention;

FIG. 3 is a block diagram of a control program according to the invention;

FIG. 4 is a program flow chart of a PC communications module;

FIG. 5 is a program flow chart of a mail processing function;

FIGS. 6A, 6B and 6C are program flow charts of a PC message processing function;

FIGS. 7A and 7B are program flow charts of a dispenser control module;

FIG. 8 is a program flow chart of a get command function;

FIG. 9 is a program flow chart of a poll function;

FIG. 10 is a program flow chart of a load command function;

FIG. 11 is program flow chart of a message receive function;

FIG. 12 is a program flow chart of a memory-image-status handler module;

FIG. 13 is a program flow chart of a dispenser data input/output interrupt handler function.

FIG. 14 is a program flow chart of a receive interrupt handler function;

FIG. 15 is a program flow chart of a transmitt interrupt handler function; and

FIG. 16 is a schematic diagram of a current loop interface with a fuel pump .

Referring now specifically to the drawings, and the illustrative embodiments depicted therein, dispensing system 15 includes a personal computer, or PC, 16, a plurality of fuel dispensing pumps 18 and an interface unit 20 between personal computer 16 and pumps 18 (FIG. 1). Each pump 18 is a "smart" pump having input/output circuitry which may be polled by interface unit 20 and will accept data downloaded from unit 20. Pump 18 includes a dispenser unit 19a to control the dispensing of fuel and may include an optional card accepter unit 19b to read the magnetic data contained on a personal debit card or credit card (FIG. 16). Computer 16 includes a peripheral bus 17 for communication with peripheral devices, such as printers, MODEMS and the like. Interface unit 20 includes a PC bus interface 22 having circuitry for exchanging data between PC bus 17 and a controller such as microprocessor U6 on-board the interface unit. Microprocessor U6 receives timing signals from a 20 megahertz (MHz) clock 24 and initialization routines from a boot prom U8. A nonvolatile or volatile memory 25 stores operating code and a static RAM memory 26 stores data for use by microprocessor U6. Microprocessor U6 drives four universal asynchronous receiver/transmitters (UARTs) U11A, U11B, U12A and U12B. Each UART, in turn, is interconnected with a multiplexer 28 and a de-multiplexer 30. Each de-multiplexer 30 has eight associated output lines 32a, 32b, 32c, 32d, 32e, 32f, 32g and 32h and each multiplexer 28 has eight associated input lines 34a, 34b, 34c, 34d, 34e, 34f, 34g and 34h. Each de-multiplexer output line 32a-32h is in a current loop with an individual fuel pump 18 and an input line 34a-34h of an associated multiplexer 28. Communications with the dispenser unit 19a and card acceptor unit 19b for a particular fuel pump 18 are on the same communication loop, as illustrated in FIG. 16. In this manner, each UART interfaces with eight pumps, which are addressed one at a time. With four UARTs, microprocessor U6 is capable of addressing four pumps at a time and all thirty-two pumps in eight address cycles.

PC bus interface 22 includes a control port 36 which receives signals on an external bus 46 extending to personal computer bus 17, buffers the signals received from the personal computer bus and provides signals to microprocessor U6 on an internal bus 44 extending from microprocessor U6. Control port 36 additionally buffers signals from microprocessor U6 and provides such signals to the personal computer on external bus 46 extending to bus 17. A memory control device 42 is interconnected with internal bus 44 of interface unit 20, external bus 46 extending to personal computer bus 17 and a window bus 48 extending between memory control 42 and a window memory 50. Memory control 42 is under the control of microprocessor U6 by way of a control line 41 extending from UART U11A to memory control 42. When microprocessor U6 instructs UART U11A to cause line 41 to be in a first state, memory control 42 actively interfaces window bus 48 with external bus 46 such that personal computer 16 can write data to window memory 50 and retrieve data from window memory 50. When microprocessor U6 instructs UART U11A to cause control line 41 to be in an alternate state, memory control 42 actively interfaces window bus 48 with internal bus 44 such that microprocessor U6 can write data to and retrieve data from window memory 50. However, isolation is always maintained between internal bus 44 and external bus 46 and only one of the internal and external buses is allowed access to window memory 50 at a time.

Memory control 42 interfaces window bus 48 with either internal bus 44 or external bus 46 under the control of microprocessor U6. When personal computer 16 has a command to write to window memory 50 or wishes to retrieve data from window memory 50, access must be requested by PC 16 through control port 36. An interrupt may be generated to the microprocessor U6 at the instruction of the PC by writing to a specific control port address. Additionally, the interface unit 20 may be reset independent of the rest of system 15 by the PC writing to the control port at a specific sequence of addresses which generates at non-maskable interrupt (NMI). Microprocessor U6 additionally supervises and repetitively updates a database partially residing in data memory 26 by polling pumps 18 and writing the retrieved data to the database. This database is periodically copied to window memory 50 shared with computer 16. When personal computer 16 issues a command, it does so by requesting access to window memory 50 for placement of the command, which is then implemented by microprocessor U6. When personal computer 16 wishes to retrieve the status of a particular pump, it requests access to window memory 50 and retrieves the data that had been loaded to the shared memory. Dispenser status is always available in shared memory.

PC bus interface 22 additionally provides the capability for down-loading operating code to an operating code memory 25. This occurs in a "bucket-brigade" fashion by a portion of the code being loaded into window memory 50 through external bus 46 and retrieved by microprocessor U6 over internal bus 44 and written to memory 25. When this cycle is complete, the next batch of code is written to window memory 50 through external bus 46 and retrieved by microprocessor U6 over internal bus 44. This process is repeated until the entire module or modules are down-loaded to memory 25. In this manner, software updates may be provided without gaining physical access to interface unit 20 to replace PROMs or the like. Rather, software updates may be inputted to personal computer 16 through magnetic medium, or down-loaded from a remote database through a MODEM interface, or the like.

Interface unit 20 "looks" like any peripheral device to personal computer 16. Commands may be issued to interface 20 and data read using conventional operating systems, such as UNIX, and commercially available application software developed for the purpose of supervising the operation of a convenience store. A personal computer 16 having such application software combined in a convenience store system is commercially available and is marketed by Retail Automation, Inc. located in Atlanta, Ga. Intelligent pumps, such as fuel pumps 18 are commercially available and are marketed by Bennett Pump Company, the present assignee, under Model Series 6000, 7000, 8000 and 9000.

Microprocessor U6 is preferably Model 80C188 microprocessor, marketed by Intel, which is capable of accessing 384K of code space and up to 128K of data storage space, in addition to 8K of window memory (FIG. 2A). Microprocesser U6 operates on a system clock rate of 10 MHz developed from a 20 MHz clock 24. A latch circuit U7 is actuated by an address-latch-enable signal ALE to drive a low order address bus 52 with address bytes A0-A7. After the address is latched from bus 54, the bus operates as a bi-directional data bus 56. A high order address bus 58 does not require latching.

Boot memory device U8, which stores the initialization routine for microprocessor U6 in the illustrated embodiment, is between a type 2764A and a type 27010, EPROM. Memory device U10, which is a nonvolitile RAM, may be configured to accept between a 32K.times.8 and a 128K.times.8 flash memory device or CMOS static RAM and is provided for the purpose of storing the system operating code for the interface unit. An auxiliary flash memory or CMOS static RAM (not shown) may additionally be provided to augment U10. Memory device U9, which is a nonvolitile RAM, may be configured to accept between a 32K.times.8 and a 128K.times.8 CMOS flash memory device or static RAM and is provided for the purpose of storing system data. Boot EPROM U8 resides at the upper chip-select (UCS), the operating code memory device U10, and its auxiliary, if provided, device reside at middle chip-select 1 and 2 (MCS1, MCS2) respectively, and the data storage device U9 resides at middle chip-select 0 (MC 0) of microprocessor U6.

A programmable logic device (PLD) 60 decodes the memory I/O, control register and data window WR (WRITE) and RD (READ) control lines. Latch enable signal ALE is inverted and supplies the clock input of PLD 60. An S2 signal from microprocessor U6 signifies whether the RD/WR signals eminating from the microprocessor are for a memory cycle or an I/O cycle. PLD 60 produces an IOWR signal 62 which is the I/O WRITE command for the interface unit 20 and an IORD signal 63 which is the I/O read command. These signals are produced by "anding" the microprocessor WR and RD signals respectively with the latched S2 signal. A MEMRD signal 64 is the memory read command for the interface unit 20. This signal is produced by "anding" the microprocessors RD signal with the latched S2 signal. A MEMWR signal 66 is the memory WRITE command for the dispenser interface unit 20. This signal is produced by "anding" the microprocessor's WR signal with the latched S2 signal.

An RDPC signal 68 is the control port read command for the dispenser interface unit 20. The control port resides in the peripheral chip-select area 4 (PCS4). This signal is produced by "anding" the IORD signal with the microprocessor's PCS4 signal. The WRPC signal 70 is the control port write for the dispenser interface unit. This signal is produced by "anding" the IOWR signal and the microprocessor's PCS4 signal. The WINRD signal 65 is the data window read for the dispenser interface unit. The data window resides in the middle chip-select 3 area (MCS3). This signal is produced by "anding" the MEMRD signal with the microprocessor's MCS3 signal. A WINWR signal 67 is the data window WRITE for the dispenser interface unit. This signal is produced by "anding" the MEMWR signal with the microprocessor's MCS3 signal. PLD unit 60 is a generic programmable logic device which is commercially available and is marketed by numerous manufacturers, under Model No. 22V10.

PC bus interface 22 provides an 8-bit edge card connector interface to PC bus 17 (FIG. 2B). An array of programmable logic devices (PLD) 76 decodes the PC bus address bytes on lines 78a, 78b and produces a window chip-select signal WINCS on line 69 during a valid base address range. A valid base address may be jumper-selected at inputs 80 and a control port base address may be jumper-selected at inputs 82. PLD 76 additionally generates various system interrupts including interrupt signal INTOUT on line 84 from the interface unit to the PC at terminal 86. Signal INTOUT is also jumper-selectable to a variety of PC interrupts. PLD 76 additionally generates an interrupt from the PC to the interface unit (IFINT) on line 87. Other signals generated by programmable logic device 76 are outlined in APPENDIX A which sets forth the logic sequence of their generation. PLD circuit 76 is a generic programmable logic device supplied by various manufacturers, under Model No. 22V10.

PC bus interface 22 includes an internal bus access control circuit 88 for selectively coupling or isolating internal data buses 52, 56 and 58 with window memory device 50 by isolating or driving the data window's address bus and control lines with internal bus control busses 52 and 58. A bus access control circuit 90 isolates and buffers the internal data bus 56 with the external data bus 47 to process requests by computer 16 for access to window memory 50. Interface 22 further includes external bus access control circuit 92 for selectively coupling or isolating external bus 46 with window memory 50. External bus access control circuit 92 isolates or enables the PC data bus to the window memory data window. The data window and control port of window memory 50 are connected between internal bus 44 and external bus 46 under the control of microprocessor U6. This is accomplished by the toggling of line 41 extending from output bit OP6 of DUART U11. A logic high-out on this line directs the data window to external bus 46 and a logic low directs the data window to internal bus 44. The bus that is selected is allowed to drive the data window memory through standard bus drivers. In the illustrated embodiment, window memory 50 is a conventional 8K3.times.8 RAM memory device. In the illustrated embodiment, circuit 90 is a standard model 74ALS646 integrated circuit; circuits 88 and 92 each include standard models 74HC244 and 74HC245 integrated circuits.

A pair of dual universal asynchronous receiver/transmitters (DUARTs) U11 and U12 interface directly to microprocessor buses 56 and 52 (FIG. 2C). A clock 72 drives the internal circuitry of the DUARTs and determines the BAUD rates used by the DUARTs for communicating with fuel pumps 18. DUARTs U11 and U12 are driven directly from RD and WR signal lines 62 and 63. DUART U11 resides at peripheral chip-select 0 (PCS0) and DUART U12 resides at peripheral chip-select 1 (PCS1) of microprocessor U6. Output pins OP0-OP5 of DUART U11 select the pump loops 1 through 16 to communicate with and output pins QP0-OP5 of DUART U12 select the pump loops 17 through 32 to communicate with. Output pin OP6 of DUART U11 is provided on line 41 as the tri-state control signal for the operation of memory control 42. Output pin OP6 of DUART U12 is supplied as a watchdog timer reset bit on line 74 to battery backup circuit 76. Backup circuit 76 is a maxim model MAX690 supervisory circuit marketed by Maxim and includes a 3.6V lithium cell 78 to provide optional backup power to memory devices U8-U10.

DUARTs U11 and U12 interface with up to 32 fuel pumps 18 utilizing 32 separate current loops, each including an output line 32a-32h and an input line 34a-34h. Each driver portion of the current loop is formed with a high current source driver 29, such as a unit marketed by Sprague under Model No. UDN2982A, through a 180 ohms, 1/2 watt series current limiting resistor. The inputs to the source drivers are provided by outputs of the corresponding de-multiplexers 30. In the illustrated embodiment, de-multiplexers 30 are provided as standard Model No. 74HCT138 integrated circuits. Each receiving portion 27 of the current loop is formed with a 56 ohm series current limiting resistor, an 82 ohm pull-down resistor and an open-collector transistor, such as supplied under Sprague Model No. ULN2081. The outputs of the open collector transistor are pulled high with a 15K ohm pull-up resistor and provided to the input channel of the corresponding multiplexer 28. In the illustrated embodiment, multiplexers 28 are industry-standard Model No. 74HC151 integrated circuits. Each dispenser 19a and credit card acceptor includes an optically coupled transistor 99a for transmitting to the interface unit and an optically coupled transistor 99b for receiving from the interface unit (FIG. 16).

Transmit channel A of DUART U11 drives the input of the associated de-multiplexer 30-0. The de-multiplexer selectively applies a signal to eight output channels 32a-32h. The inputs of this de-multiplexer are controlled by the output port bytes OP0-OP2 (SEL0-SEL2) of DUART U11. Transmit channel B of DUART U11 drives the input of de-multiplexer 30-1 which separates the single output channel out to eight output channels. The select inputs of this de-multiplexer are controlled by the output port bytes OP3-OP5 (SEL3-SEL5) of DUART U11. The receive channel A of DUART U11 is driven by the output of multiplexer 28-0. This multiplexer combines eight channels received on lines 34a-34h into one channel. The select inputs of this multiplexer are controlled by the output port bytes OP0-OP2 (SEL0-SEL2) of DUART U11. Receive channel B of DUART U11 is driven by the output of multiplexer 28-1. The select inputs are controlled by the output port bytes OP3-OP5 (SEL3-SEL5) of DUART U11.

DUART U12, having channels A and B and associated multiplexers and de-multiplexers are arranged in the same fashion as DUART U11 in order to service the other 16 of the 32 pumps in dispensing system 15. In the illustrated embodiment, DUARTs U11 and U12 are industry standard Model No. 88C681 integrated circuits. De-multiplexers 30 are industry standard 74HCT138 integrated circuits and multiplexers 28 are industry standard 74HC151 integrated circuits. The communications current loop is powered from the 12V DC power supply of computer 16. The 12V DC supply is filtered and the communications current loop ground is isolated from the ground of the 12V DC supply of PC 16.

A software control program 100 used in interface unit 20 includes a PC communication module (PC-COMM) 102 to handle communications with the PC bus and a plurality of pump-loop communication modules (LP-COMM) 104, each to handle communications with the fuel pumps associated with a single UART (FIG. 3). LP-COMM module 104 will be duplicated four times, once for each UART in the system. The UART specific data, such as UART port addresses can then be incorporated by having a unique header file for each LP-COMM Module 104. All modules are called by an executive routine (EXEC) 106, which is the mainline control of program 100. The EXEC routine 106 first calls an initialize routine 108 and then goes into an infinite loop to call all of the remaining modules. No data is handled by the EXEC routine.

Program 100 additionally includes an LP-STATUS module 110 for the purpose of checking the status bytes of a fuel pump to determine if there has been any change. If a change has occurred, this module will then decide what, if any, action is necessary. DCA-LIB module 112 and DIS-LIB module 114 contain the support routines for communicating respectively with card readers and dispensers associated with each fuel pump 18. A general utility module 116 holds utility procedures that other modules use. An INT-UTIL module 118 contains interrupt routines that are not associated with the LP-COMM module 104. This includes the internal timer interrupts, interrupts from the PC and non-maskable interrupts and window access control. A DIAG module 120 is provided to handle any problems encountered during normal operations of program 100 and to initiate diagnostic routines where necessary. In the illustrated embodiment, all modules are implemented with the C language.

The PC-COMM module 102 handles communications with PC bus 17 including communication of commands and data between the module and PC system software. This module communicates with all other modules through a mailbox system or the database internal to interface unit 20. This module acts as a go-between for the internal data and mailbox structure to the PC system software. PC-COMM module 102 will be called from executive routine 106. The PC-COMM module 102 uses a shared block of memory accessed by both the internal bus 44 and external bus 46. Before the module will continue its execution, the access to the shared memory is checked. If the memory is under PC control, PC-COMM will exit back to EXEC routine 106.

After being called at 122, the PC-COMM program checks its input mailbox at 124 to see if any requests are coming from other modules (FIG. 4). If it is determined at 126 that the mailbox has a message, the message will be processed at 128. If there is no input mail, the program will check the shared memory buffer read pointers at 130 to determine at 132 whether any messages are ready for input from the PC. If there is a message, it will be processed at 134, which could include updating the database, returning data back to the PC, or passing commands to the communications mailboxes.

If it is determined at 132 that there is no PC message to be processed, the program passes to 136 where the timer that tracks the time remaining in the update cycle is examined and to 138 where it is determined whether the time has been reduced to zero. If so, control passes to 140 where the update value is increased to its maximum value and to 142 where the local status RAM is copied to the memory that is shared with the PC. If the update timer has not timed out at 138, control exits this module to resume the EXEC routine 106.

The process mail function 128 examines commands in mail received from other modules (FIG. 5). Listing of these commands is set forth in APPENDIX B. If the command #1 is received (Authorize Hoze Response) then control passes to 144 where the status of the associated fuel pump is outputted and to 146 where it is determined whether a transaction with that pump has been authorized. If so, an acknowledgement word (ACK) is loaded into an output register at 148. If not, a not-authorized message (NAK) is loaded to the output register at 150. Control then passes to 152 where a PC message is formed from the data word and to 153 where the message is written to the memory shared with the PC. If command #16 is received, the control determines whether a price level has been set at 154. If so, an authorize hose message is provided to the appropriate mailbox at 156. From 156, control passes to 162 where the authorization is passed to the dispenser module. If an authorize hose message is not received, the not-acknowledge message (NAK) is loaded to the mailbox at 158. From 158 control passes to 160 where the data is formatted as a PC message and to 153 where the command is written to the shared memory.

If one of commands #4, #6, #9 or #10 is received, control passes to 164 where an appropriate return mail code is loaded into the output mailbox and 166 where the appropriate data from the database is loaded into the output mailbox. Control passes to 168 where the command is formatted to a PC message and to 153 where the message is written to the shared memory. If one of commands #21, #22, #23 or #25 is received, control passes to 170 where the requested information is retrieved and to 153 where the requested information is written to the shared memory.

Function 134, which processes messages from the PC, loads the message into a temporary store at 172 and processes the retrieved messages at 174 by reference to the command numbers listed in APPENDIX C (FIG. 6A). If command #1 is the PC message, then the request that a particular fuel pump be armed is processed by determining at 176 whether the sale is a prepay sale. If so, control passes to 178 where the prepaid amount is loaded into the database and to 180 where the message is transferred to the mailbox of the appropriate dispenser communication module (LP-COMM) 104. If the sale is not a prepay sale, then an authorization command is provided at 182 to the appropriate dispenser communication module. If one of commands #2, #9, #4, #11, #10 or #13 is received, then control passes to 184 where an appropriate mailbox command is developed and to 186 where the message is transferred to the appropriate dispenser communication module (FIG. 6B). If PC command #7 or #18 is received, control passes to 188 where the PC message is loaded into the database and to 190 where its parameters are checked for validity. If it is determined at 192 that it is a valid command, then control passes to 194 where the command is loaded into the output mailbox and 196 where the command is transferred to the appropriate dispenser communication module. An acknowledge message is built at 198 and returned to the shared memory at 202. If the command is determined at 192 to be not valid, then a not- acknowledged (NAK) message is built at 200 and returned to the shared memory at 202.

If one of PC commands #3, #12 or #5 is received, then the command message is loaded into the database at 204 (FIG. 6C). An appropriate mailbox command is built at 206 and transferred to the appropriate dispenser communication module 104 at 208. If one of commands #14, #6 or #15 is received, then the data requested in the command is transferred from the database at 210 and a PC message is constructed at 212 which is loaded to the shared memory at 214.

Because of the unique arrangement of the program 100, system priority is given to the PC bus. While this architecture could slow down the polling of the fuel pumps and responses received therefrom during periods of extensive updating, any detrimental effect is more than offset by the freedom of the interface unit from slowing down operation of the PC. In the PC-COMM module, all commands to the PC are loaded into the window memory and all internal commands are issued in the mailbox system. Once a command is issued to update data to the loop devices, the loop communication modules will handle the logic of verifying that all devices are updated and report back any problems by indicating a down device. Any data required to execute the PC commands is communicated through the database. Microprocessor U6 is not multi-tasking and interrupts can only fill or empty reserve buffers. Therefore, a reading or writing from the database will always complete its task before another process accessing the database can begin. If the PC requests a series of data elements, the system gets the data from the database without requesting the data from the loop communication modules. This avoids overloading of the loop controls and the PC is presented with valid data which is updated on a continual basis.

The dispenser control, or loop communication module (LP-COMM) 104 handles communications with the dispensers and, if provided, the card acceptor devices associated with a single UART (FIG. 7A). The LP-COMM module handles commands present in the associated mailbox or, if no commands are present, then a poll routine is called to keep the pump face and status data up to date in the database. Additionally, the card acceptors will be polled for service requests. When called at 216 the module examines the COMSTATE register at 218 to determine the status of the communication loop. If it is idle, then control passes to 220 where a command is obtained either from the mailbox system or the polling routine by the "get command" function and to 222 where the command is added to a command list used by the LP-COMM module to send to the fuel pump. Control then passes to 224 where the data is transmitted on the appropriate communications loop.

If it is determined at 218 that the particular loop is not idle, then the COMSTATE register is checked at 226 to determined whether the loop is in a receive mode. If it is, then the status of a time-out timer is checked at 228 to determine if it has timed out. If the loop is not in a received mode, then it is determined at 230 whether it is in a transmit mode. If so, then the time-out timer is again checked at 228 to determined if it has timed-out. If it is determined at 230 that the particular communication loop is not in a transmit state, then it is determined at 232 whether any receive buffer full condition has been cleared. If so, then it is determined at 234 whether the just received message is valid (FIG. 7B). If not, the time-out timer is set to a time-out state at 236 and the COMSTATE register for the communication loop is set to a idle state at 238. If the message received is determined at 234 to be valid, then control passes to a receive routine 240 for loading the dispenser receive buffer to the database. Control then passes to 242 where it is determined whether any commands remain to be executed. If so, then a new command is obtained from the list at 244 and the COMSTATE register is set to a transmit state at 246. The command is then transmitted to the fuel pump at 248. If the command list is empty at 242, then the COMSTATE register is set to idle at 250 and a response is sent to the appropriate module 102 at 252.

The "get command" function 220 begins by determining whether incoming mail is present at 254 (FIG. 8). If so, the message is read at 256 and the status of the particular fuel dispenser is checked at 258 to determine if the fueling position is in the "down" state. If it is down, then a response is sent to the PC at 260 and control goes back to 254 to get another command. If it is determined at 254 that there is not incoming message, then control passes to 264 where the poll function is called to get a status request command or price set command for the next dispenser in the poll list.

The "poll function" is responsible for coordinating what command should be sent on a particular dispensers poll cycle (FIG. 9). The dispenser whose turn it is to be polled is determined at 264. The dispenser is checked at 265 to determine if the hose is in "flow" or not. If the dispenser is in flow, then control goes to 266 where a long poll command is selected to be sent to the dispenser. The long poll command requests status and pump-face information. If it is determined at 265 that the hose is not in flow, then control goes to 267, where the dispensers "price change" flag is checked. If it is set, then control goes to 268 to determine if a "price set" was sent during the dispensers last poll cycle. If it was, then control goes to 269 and a short status poll is sent. Otherwise, the control goes to 270 and a "price set" command is sent. If the "price change" flag is not set at 267 then control goes to 271 and a short status command is sent.

The LP-COMM module calls the "get command" function to initiate communication in response to commands in either the dispenser, or the card acceptor, mailbox. If there are no messages waiting then the "get command" function will call the "poll function" to get a status command.

The DIS-UTIL 115 module contains the actual interrupt service routines for responding to the DUART interrupts (FIG. 13). Each DUART has one interrupt and when it becomes active the program must poll the individual status registers to determine what handler to call. When the interrupt service routine is called at 286 the status register for channel 1 is checked at 288 to see if the transmitter has a character waiting. If a character is waiting, then control is transferred to 289, which calls the routine in the LP-COMM to handle the processing of the character to be read. Next the program control goes to 290 where the status register for channel 1 is checked to see if a received character needs to be processed. If one does, then control goes to 291 to call the receive handler. Next, program control goes to 292 where the status register for channel 2 is checked to see if the transmit buffer needs servicing. If it does then control goes to 293 to call the transmit handler routine. Next, control goes to 294 to check the status register of channel 2 to see if the receive handler needs to be called. If it does, control transfers to 295 where the receive handler routine is called.

The receive handler routine is entered at 300 (FIG. 14) and the data character and the associated error bits are read. If an error condition is discovered at 301 then control does to 302 before going to 303, otherwise control goes directly to 303. At 302 the error bits are cleared in the UART. The CHECKSUM is next updated at 303 on character by character basis. Next, control goes to 304 where the RCV counter is updated. At 305, the RCV counter is compared to the message length to see if a complete message has been received. If a complete message has been received then control goes to 306 where the COMSTATE register is set to BLK DONE.

The transmit handler is entered at 310 (FIG. 15). If a complete message has been received, then control transfers to 314 and 315, which change the COMSTATE to "receive" and enable the UART to interrupt on received characters, in order to reverse the direction of communication for the half duplex dispenser current loop. If it is determined at 310 that a complete message has not been received, control goes to 311 where the next character in the message string is sent out of the UART. At 312 the character counter is incremented and at 313 the time out counter is reloaded.

The LP-STATUS module 110 is provided for the purpose of checking the status bytes of a loop device and determining if there has been any change (FIG. 12). If a change has occurred, the module will then decide what, if any, action is necessary. Separate status check modules are provided for the dispenser and any card acceptor device that is used. When the LP status module 110 is called, the mail-in box is read at 318 and the dispenser or card reader whose status is being checked is set at 320. Then it is determined at 322 whether the command received in the mailbox is command #15. If so, a change of state of the associated dispenser is requested and is carried out at 324. If not, then the status image in the internal memory is updated at 326 including any change of state from any dispenser at 328. The control then compares the previous and present states at 330 to determine whether action is required at 332. If action is determined to be required at 332 then any area status changes are carried out at 334 and any associated mailbox commands are constructed at 336. The mailbox commands are then sent to the proper software module at 338. Any necessary status changes are updated in the the image of the status memory stored in internal memory. This will allow the status update modules access to change the status at any time regardless of whether the internal bus or the PC bus has access to the shared memory. The internal memory status image is then copied to the shared memory status area, which resides in window memory 50, on a periodic basis.

Thus, it is seen that the present invention provides a direct interface for a fuel pump which is slot-compatible with a personal computer, PC bus. A microprocessor based controller included in the interface unit handles the exchange of information with the dispensing units and card acceptor units which make up a fuel pump. Data is exchanged with the PC through a window memory having a single port which is accessed by either a bus internal to the interface or the PC bus. Access to the window memory is controlled by the interface unit microprocessor which frees the PC of this supervisory responsibility to avoid slowing down other multi-tasking functions of the PC performed in the convenience store environment. Although the microprocessor determines which bus has control over the window memory, the personal computer has priority. A database of fuel pump information is kept up to date by the interface unit so that the commands by the personal computer will be fulfilled with accurate information. A listing of hardware and software interface specifications is set forth in APPENDIX C.

The invention provides a direct interface unit which is more adaptable to variations in PC bus format than dual-ported direct memory access interfaces. Furthermore, updates in program modules may be transferred through the memory window in a bucket-brigade fashion to allow system upgrades without the requirement for field modifications. In fact, no requirement exists for a field technician to access the hardware in order to implement upgrades. The direct interface uses power supplied by the PC bus and thus eliminates the cost and cabling required for separate interface power supplies.

Changes and modifications in the specifically described embodiments can be carried out without departing from the principles of the invention which is intended to be limited only by the scope of the appended claims, as interpreted according to the principles of patent law, including the Doctrine of Equivalents. ##SPC1## ##SPC2##