CA2097099A1 - Method for field programming an electronic parking meter - Google Patents

Abstract

ABSTRACT

An electronic parking meter is programmable in the field, in order to provide flexibility and adaptability to future conditions, by partitioning its software program into two independent modules, the smaller of which controls the replacement by a new program module of the other module or of itself.

Description

METHOD FOR FIELD PROGRAMMING AN ELECTRONIC PARKING METER

BACKGROUND OF THE INVENTION

1, Field of the Invention The present invention relates to parking meters in general, and in particular to electronic parking meters.
05 More particularly still, it relates to field programmable, and reprogrammable, parking meters, 2. Prior Art of the Invention United Kingdom Patent application GB 2 077 47~
published December 1~, 1981 discloses a vehicle parking meter which differs from previous mechanically operated meters in that the coin registration, timing, and display functions are performed wholly by electronic circuitry. Preferred form of display is of the liquid crystal type.

The power consumption of the apparatus is very low as it consists predominantly of CMOS circuitry and power is provided by a battery whose charge is maintained by light-activated solar cells.

Functions additional to those provided by mechanical meters are provided and include cash totalization, cash display, settable parking charge per hour, settable parking periods, and provision for n5 providing digital information from the meter to an external data-recording device.

Embodiments are described incorporating the RCA
1802 and RCA 1804 microprocessor together with peripheral circuitry.

United States pa~ent number 4,823,928 issued April ~, 1989 to Speas discloses an electronic parking meter system for receiving at least one type of coin or other payment device and having an electronic parking meter and an auditor. The electronic parking meter comprises a power source which may be a solar type power source, as well as, having terminals for connection to an external saurce of power, The meter also has a microprocessor with a memory connected to the power supply. An electronic display is connected to the microprocessor and displays pertinent information for the meter. The auditor may be connected to the 209709~

microprocessor in the electronic meter by means of a direct cable link or by infrared transmission. The electronic parking meter system may have a sonar range finder connected to the microprocessor in the meter 05 which detects the presence or absence of a vehicle in an associated parking space with the parking meter.

Both of the above prior art documents are incorporated herein by reference.

SUMMARY OF THE INVENTION

The present invention endeavors to provide a flexible, software controlled, parking meter. In order to be flexible, the meter must be able to accommodate changes in the coins it will accept after it has been in use in the field. It is also advantageous to be able to update or correct software "bugs" in the field. It is, therefore, a feature of the present parking meter that software can be "downloaded" into it, preferably by wireless data communication, for example by means of intra-red (IR) receive and transmit channels.

20~7099 Accordingly, the present invention provides a method for field programming an electronic parking meter comprising: (a) controlling data processing means of said parking meter by means of separate first and second 05program modules; (b) providing a predetermined interrupt signal to said data processing means; (c) causing said data processing means to request a third program module in response to said predetermined interrupt; (d) said first program module causing said data processing means 10to store said third program module; and (e) causing said data processing means to replace one of said first and second program modules with said third pro~ram module.

BRIEF DESCRIPTION OF THE DRAWINGS

The preferred embodiment of the present invention will now be described in conjunction with annexed drawings, in which:

20Figure l is an overall block diagram of the parking meter of the present invention;

Figure 2 is a block diagram of the block labelled ASIC in Figure l;

Figure 3 is a blocX diagram of the communication 05interface of Figure 2;

Figure 4 is a high level flow-chart of the overall software of the parking meter;

10Figure 5 is a flow-chart of the block labelled "Service IR Interrupt" in Figure 4; and Figure 6 is a flow-chart of the block labelled "Download Software" in Figure 4.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to Figure l of the drawings, the parking 20meter comprises an application specific integrated circuit (ASIC) l0, communicating via DATA and ADRESS
buses with a central processor (CPU) ll, a programmable memory (EEPROM) 12, and a random access memory (RAM) 13.

:

The ASIC 10 also receives inputs from a coin shute 14 re position, size and mass of a coin passing through; and receives and transmits serial data SDIN and SDOUT, respectively, from infra-red receiver (IR RCV) 15 and 05 infra-red transmitter (IR TX) 16. A volta~e regulator and controller (REG) 17 generates voltages VAA and VDD
from battery voltage Vcc. VAA is necessary for pDwering the ASIC 10, while VDD powers the CPU 11, EEPROM 12 and RAM 13. Vcc directly powers the IR transmitter 16 as well as red and yellow LEDS 18 and 19. The ASIC 10 drives the liquid crystal displays (front and back) LCDO
and LCDl.

Figure 2 shows a block diagram of the ASIC lO, which comprises an address bus interface 20, a time-base clock 21 controlled by a 3.58 MHz crystal, a real-time clock (RT~) 22 controlled by a micro-power (watch) 32.768 KH~ crystal, an LCD display driver 23, a programmable In/Out bus 24, a local RAM 25, a CPU
interrupt controller 26, an event counter 27, a coin discrimination interface 28, a universal asynchronous receiver/transmitter (UART) 29, and an IR communications interface 30. All of the above are conventional units, 2~7~9~

whose functions could also be implemented by means of software but are mnre economically implemented by means of an ASIC.

05 Figure 3 illustrates the interface of the IR
communications interface 30 with other components. It comprises a modulator 31 and demodulator 32, a base-band selector 33, and a modulation detector 34, (which is strobed by an 8 millisecond window from the RTC 22 at a rate selectable from 1, 2, 8 or 32 Hz, in order to save power).

Figure 4 shows a flow chart of the overall system software, while Figures 5 and 6 show details of the lS blocks labelled "Service IR Interrupt" and "Download Software", respectively. In order to be able to field program the parking meters, the software has been divided into two distinct units~ the "bootstrap software" and the "application software". Both may be replaced in the field under the control of the existing bootstrap software. Thus for purposes of the present invention the bootstrap software is the essential unit.
The application software serves as the interface between 20970~

the electronic parking meter (EPM) and the user, and should, therefore, be written in a high level language ~such as C) in order to be easily altered to suit differing applications. The bootstrap software, on the 05 other hand, is a low-level program which serves as the interface between the EPM hardware and the application software.

The bootstrap is always the first program to run whenever the EPM goes from "sleep" into operational mode. In general, the primary job of the bootstrap is to quickly jump to the application software if it is present, however, if the application is not present, then the bootstrap will attempt to perform a download of application software.

When the bootstrap is invoked, it first initializes the stack pointer and tests a SLEEP indicator bit in the CPU STATUS CONTROL register to determine if the cause of 2~ the wake up was due to an interrupt (SLEEP bit is set) or to a manual EPM reset (SLEEP bit is clear). If the SLEEP bit is set, the bootstrap tests the application version byte for zero or non-zero to determine if 209709~

application software is present in the EPM. A non-æero version byte will cause the bootstrap to enter the application software, otherwise, the bootstrap assumes control of the EPM. If the SLEeP bit was clear on entry 05 to the bootstrap, the bootstrap initializes the EPM IIO
ports and serial port, and assumes control of the EPM.

When the bootstrap assumes control of the EPM. it immediately loads a software download utility into RAM
and enters it. Placing the download utility into RAM

permits downloading of either bootstrap or application into the EEPROM since software is not executing from EEPROM. The download utility will attempt to download new EPM software (either bootstrap or application) provided a remote terminal is requesting communications with the EPM. Once software is loaded or the communications link is removed the download utility will exit back to the bootstrap. The bootstrap will then retest the application version byte and enter the application if the version byte is non-zero. Otherwise, the bootstrap will enable automatic serial port sampling, display "EOOl" and enter sleep mode.

The process of downloading software requires the use of two basic communication functions: put packet() and get packet(), Both functions transfer data through the serial port in a consistent format to be referred to 05 as a packet, ~etails on packet format are described in Table l below. The put packet() routine assembles and transmits packets of data based on the length and address of the data field passed to it by the calling function. The get packet(~ routine polls the serial receiver looking for a valid packet of data. It will poll the recelver until it receives a valid packet, an erroneous packet, looses the communication link or times out. If a valid packet of data was received, get packed() will use a pointer passed by the calling function to store the data. The calling function will receive status information when get packet() returns to determine if it was successful.

Table l - ~acket Fnrmat Byte Number Content O SYNC

05 2 Packet Length (LSB) 3 Packet Length (MSB) 4 Packet Type Packet Sequence 6 Start of Data Field ~ End of Data Field N+l Checksum N+2 ETX
Notes:

l. Packet length and checksum includes bytes 4 to N.
2. Packet types are either BOOTSTRAP or APPLICATION
3. Packet sequences always starts at zero.

The EPM always show "dddd" on its LCD display while the download utility is operating. The general philosophy of the communications between a remote terminal and the EPM is that the EPM software always initiates data transfers. Therefore, the EPM download utility starts a software download procedure by transmitting "request-for-software" control packets on a regular basis and waiting for a response. The remote - l2 -terminal responds with a "software-initiation" packet that contains information such as software type, start address and the length (in packets and in bytes) of the software to be downloaded. The download utility 05extracts this information and then asks for each packet of software in succession, As each software packet is being received the data is temporarily stored in RAM so it can be sumchecked before committing it to EEPROM. If the sumcheck fails the packet, it will be requested lOagain. During this time, the EPM will display "ddxx"

where "xx" is the number of packets left to be downloaded. After all packets are received, the download utility will exit back to the bootstrap.

15If the software to be downloaded is bootstrap, the number of software packets for the download must be one.
This is done to prevent the possibility of a communications link disruption from leaving a partially loaded bootstrap in the EPM. As a result, the entire 20bootstrap code (1024 bytes or less) will be safely loaded into the EPM RAM before updating is carried out, It should also be noted that new bootstrap will void any application that may have been present in the EPM, 20970~9 Application software can be downloaded with a variable number of packets of variable length. While each packet is sumchecked before it is written to EEPROM, there is a final sumcheck performed on the 05 entire application code in the EEPROM after download is complete. If the code is verified, the download utility will update the application version byte and return to the bootstrap, otherwise, it will restart the download procedure. Should the communications link be removed any time after a download is started, the download utility will clear the application version byte and exit back to the bootstrap.

The bootstrap code which includes the utilities discussed above along with several support functions occupies no~ more than the first 1024 bytes of the EEPROM. The functions which have been included in the bootstrap are shared by the bootstrap and application.
Independence of bootstrap and application is maintained by requiring the application to use a jump table located in the bootstrap to use the bootstrap functions. All shared functions in the bootstrap have been written so that they abide by standard "C" calling conventions:

disable watchdog code() - disables watchdog timer circuit getpacket code(timeout, - gets a packet from the 05 ~buffer) serial port go to sleep code - puts the EPM into sleep (interrupt mask) mode initialize uart code() - initializes the UART
lcdputhex code(hexval) - displays "hexval" in hex on the EPM
memcpy code(*source, - copies "length" bytes *dest. leng~h) from src to dest putpacket code(packet - transmits a packet out len, *buffer3 the serial port reset ~atchdog code() - enable watchdog timer circuit A full pseudo code source listing for the bootstrap software is given in the following fourteen pages.
A suitable hand-held device for wireless (intra-red) communication with the parking meter is comprised of a PSION ORGANISER II, made by Psion (Psionhouse, Harcourt Street, London WlH lDT, England) together with a EXTECH IR COMMS LINK (Part Numbers 767321, 767322, 767324) made by Extech Instruments Corporation (335 Bear Hill Road, Waltham MA 02154).

File BS :
Routine download_software :
05 Load interrupt mask with correct bits Call lcdputhex to display download status Label ask for control packet :
Load reguest packet with data Call request and recelve packet If return value was negative - Jump to ask for control_packet Else lf return value was O
- Jump exlt_no download Else if received packet not correct length - Jump to ask_for_control_packet Else if received packet not correct type - Jump to ask_for control_packet Else if received packet not correct sequence - Jump to ask_for_control_packet Else if going to receive bootstrap and not just 1 block - Jump to ask for_control_packet Else lf battery low - Jump to ask for_control_packet Label set_up_for_download:
Setup pointer to EEPROM location Set packet counter to one Save current packet sequence Label ask for next data_packet :
Call lcdputhex~ to dlsplay status Call request and receive packet If return value negative - Jump ask for_next_data packet Else lf return value zero - Jump exit download_fail Else if not correct packet type - Jump ask for control packet Else if not correct sequence - Jump ask for next packet Increment packet counter Label recelved ne~t data packet :
Setup number of bytes and memory location to read & write Call do eeprom_write to copy data to EEPROM

If still more packets - Jump ask for next data packet If downloaded bootstrap code - Jump bs download ok Setup length, addresses and checksum Call verify_eeprom..`
If checksum not zero - Jump ask for control packet Label write version :
Setup memory address Call do eeprom write to write data to eeprom Clear sleep bit Label exit_no download :
Return to caller Label exit_download_fail :
Clear version information Jump write version Label bs_download_ok :
Jump to address OOOOH
{ }
~40 Routine do eeprom_write :
Set eeprom write enable line Calculate page boundary If number of bytes < 256 - Jump check lsb Label go_to write_page:
Load number of bytes to page boundary Jump write page Label check_lsb:
If number of bytes -> page boundary - Jump got_to_write page Else - Jump write page { _ _ ___________________________________}

~ - 1? -Routlne page mode :
If bytes > 255 - Jump max_page write Else if bytes ~ 0 - Jump exlt page mode Else lf bytes < 32 lo - Jump write_page Label max page wrlte:

Set bytes to wrlte to 32 Label wrlte page :
If not flnished - Jump write page Label wait for write cycle :
If bit 7 at both source and destination not the same - Jump wait for write cycle Else - Decrement counters Jump page_mode Label exit page mode:
Return 35 {_ ___________ _____________________- }
Routine bootstrap :
Setup start of ram If sleep bit clear - Jump bootstrap control Label epm software exists ? :
If Call check version returns zero - Jump go_get_software Label ~ump to software:
Jump to start of software (CSTARTUP in application listing) { }

..
..
. - ` :
:
. .

, ~

Routine bootstrap_control:
Turn on LCD
Setup IO data directions 05 Call initialize_uart_code Delay for hardware Label go_get_software :
Call init ram_funcs~
Call downioad_software , If Call check version~, returns non-zero - Jump ~ump_to software Label bootstrap_ok :
Call lcdputhex_code to indicate status Label bootstrap_sleep :
Call go_to_sleep_code -------}
Routine check_version :
Compare version in eeprom with passed parameter Return with sero flag status { }
Routine init ram_funcs :
Initialize RAM routines and variables.
Copy functions starting at 0000 to ram_func_end to ram.
Return to caller 40 { - ---_______________}
Routine request_and_receive_packet :
Save address of packet we want to get.
Load number of data bytes in request packet.
Call putpacket_code Retreive address of packet to get.
If Call getpacket_code~ for next packet not successful - Jump exit_no_kick Else - Call reset_watchdog_code~
Label exit_no_kick:

Return to caller { }

-- 1" --Routine verify_eeprom :
Save parameter checksum Calculate checksum from ram locations 05 Set carry flag by comparing Return to caller t }
Address ram func_buffer :
declare 200N bytes Address request packet :
Address request type :
declare 1 byte Address request_sequence :
declare 1 byte Address request_data :
declare 17 byte Address ctrl_type :
25declare 1 byte Address ctrl_sequence:
declare 1 byte Address dnld_start :
declare 2 bytes Address version :
declare 4 bytes Address dnld_length :
declare 2 bytes Address chksum :
4 0declare 1 byte Address dnld_type :
declare 1 byte Address num packetsv:
declare 1 byte Address data_packet :
Address data_type :
declare 1 byte Address data_sequence :
declare 1 byte Address data :
declare MAX_PACKET LEN bytes c_________________ }

"

,, .

, ~
File GET :
Routine getpacket_code :
05 Label get SYNC:
Turn on recelve data enable blt.
Turn on baud clock.
o If Call check abort~ , lndlcates abort - Jump exlt_ 108t link If Call packet getc~ gets no character - Jump exit tlmeout Else if character is not what' 8 expected - Jump get SYNC
If Call check abort lndicates abort 2 - Jump exlt lost llnk If Call packet_getc gets no character - Jump exlt timeout Else lf character ls not what's expected - Jump get SYNC
If Call check abort indicates abort - Jump exit lost llnk If Call packet getc gets no character - Jump exit timeout Save character If Call check abort~ lndicates abort - Jump exit lost llnk If Call packet getc~ gets no character - Jump exlt tlmeout Save character, now have length of expected data Setup polnters to where to store the data Inltlalize checksum value Label get next byte :
If Call check abort lndlcates abort - Jump exit lost link If Call packet getc~ gets no character - Jump exit timeout Update pointer to next locatlon Add character to checksum If more data left to get - Jump get next byte - ?1 -Label get_check_sum :
If Call check_abort~ indicates abort - Jump exit lost linK
05 _ _ If Call packet_getc gets no character - Jump exit timeout Save checksum we ~ust got If Call check abort ~~, lndicates abort - Jump exit_lost iink If Call packet getc ; gets no character - Jump exlt timeout Else if not expected character - Jump get_sync If calculated checksum and received checksum not the same - Jump exit bad chksum Jump exit return Label exit lost link :
Set status Jump exit return Label exlt timeout :
Set I02 to output Drive IR enable from I02 Drive IR enable high.
Delay for hardware Drive IR enable low.
Drive IR enable from ASIC RXE line.
Set status Jump exit_return Label exit bad chksum :
Set status Label exit return :
Turn off receive data enable bit.
Return to caller 50 {_______________________ }

- ?~ -Routine packet_getc :
Label check_for data :
05 If no data ln receive buffer - Jump check_for timeout Save new character Clear carry flag for success Jump exlt Label check for timeout :
If Call check abort~ .: indicates abort - Jump exit~
If not timed out yet Jump check for data Set carry flag for failure Label exit:
Return to caller { }

, ~

File MEMCPY :
Routine memcpy_code :
05 Clear carry flag Get address of last BS code space byte Subtract destination from it If illegal destination - Jump exit failure Call init ram funcs~.
Call do_eeprom wrlte'~
Label exit success :
Load register with success for caller Return to caller Label exit failure:
Load register with failure for caller Return to caller { }

- ?r; _ File PUT :
Routine putpacket code:
05 ~urn on baud clock.
If call packet putc ~, to send flrst character of packet fails - Jump exit lost link If call packet putc~ ~ to send second character falls - Jump exit_lost link If call packet putc~-- to send third character fails - Jump exlt lost link If call packet putc~- to send fourth character fails - Jump exit lost link Initalize checksum value Start at first character to transmit Label while buf_not empty :
If no characters left to do - Jump exit Get next character from buffer If call packet putc~ . to send character fails _ Jump exit lost link Add to current checksum Jump while buf not empty Label exit :
If call packet putc to send checksum fails - Jump exit lost link If call packet putc to send last character fails - Jump exit_lost link Load register to indicate success Return to caller Label exit_lost link :
Load re~ister to indicate failure Return to caller { }

- ?~ -Routlne packet_putc :
Delay for hardware 05 Label buf not empty :
If call check abort~ indlcates abort - Jump putc exlt Get status of serial register.
Test transmlt buffer empty.
Wait for buffer to clear (previous char).
Write char to transmit buffer Label putc exit :
Return to caller { }
Routine check abort :
If coin interrupt or clock interrupt or Not IR interrupt - Return abort to caller Return continue to caller { }

~ .

File LCDHEX :
Routine lcdputhex code :
05 Retrieve digits from parameter Point to first LCD register Setup for first nibble Label next hex digit :
-- --Retrleve current nlbble (worklng left to rlght) from parameter Polnt to LCD character to dlsplay.
Get LCD charac~er to dlsplay from lookup table.
Display lt st the current LCD diglt.
Polnt to next LCD display digit.
Increment current nlbble If nibble < 5 - Jump next hex digit Return to caller { }
Address lcdhexchars :
Define variables for each digit O..F
{

Flle SLEEP :
Routine go to sleep code :
Call initlalize uart code~
Mask on the correct interrupts Sleep with IR on, baud clock off.
Make RXE the input to IO2 Clear the sleep bit 4 Wait a blt for system Halt system { }
4 5 File UART :
Routine initialize uart code :
Setup uart with correct baud, parlty etc.
Output character to uart's transmlt register to initialize Delay for hardware to send start bit Return to caller { }

- ?~ -Flle WATCHDOG :
Routine disable_watchdog_code :
05 Get current byte value.
Set watchdog bits to disable value.
Disable watchdog.
Return to caller {___________________________________ }
Routine reset_watchdog_code :
Call disable_watchdog_cod~
Get current byte value.
Set watchdog bits to enable value.
Enable watchdog Return to caller 20 { ____________________________ }

Claims

WHAT IS CLAIMED IS:

1. A method for field programming an electronic parking meter, comprising:

(a) controlling data processing means of said parking meter by means of separate first and second program modules;

(b) providing a predetermined interrupt signal to said data processing means;

(c) causing said data processing means to request a third program module in response to said predetermined interrupt;

(d) said first program module causing said data processing means to store said third program module; and (e) causing said data processing means to replace one of said first and second program modules with said third program module.