Design Considerations

Introduction

P.E.T. (Pet Entry Technology) Express is a pet door designed to give pet owners the ability to control and monitor ingress and egress through their pet’s door. P.E.T. Express uses the latest in RFID technology to allow only the pet or pets wearing the recognized RFID tags to enter through the pet door. This is accomplished by utilizing an RFID receiver that monitors the area around the door and sends the tag ID signal datato the microcontroller when a tagged animal walks up to the door, ensuring that unwanted animals cannot access the door. Interfacing a keypad and LCD screen with the microcontroller allows the pet owner to input which pet is able to access the door during certain specified times. The pet owner is also able to monitor the system’s status from a remote location via an embedded web server, thus making it easier for the pet owner to access the system at work or when away from the house. The system will have a backup battery pack that keeps the system operational and maintain memory settings if the main power fails. All of these features allow pet owners to monitor and control their pet’s door from any location at anytime.

In light of firmware and software considerations, P.E.T. Express utilizes a number of solutions. As with any embedded system, software design and implementation is a major factor in producing a successful, usable application. The designer must consider coding strategies such as an interrupt-driven system, space considerations due to limited memory sizes, and compatibility with peripherals. This document will outline the software design criteria and considerations used while designing the P.E.T. Express, discussion on the completed code, and physical listing of the completed code.

Design Considerations

When designing the current solution, Team P.E.T. took a number of considerations into effect concerning the software implementation: considerations pertaining to certain memory models, memory organization, creation of a standalone application, and finally, software organization.

P.E.T. Express utilizes a Motorola MC9S12NE64 with built-in Ethernet controller capability. The NE64 contains 64KB of Flash memory and 8KB of RAM [1]. For the stated application, this amount of memory should suffice. Normally, considerations would have to be made as to the storage locations of data and instruction commands; however, this system is implemented using Code Warrior, which handles all of the memory allocation and organization without troubling the user with complex memory mapping arrays. Figure 10.1 displays a memory map for the NE64.

Figure 10.1: MC9S12NE64 User Configurable Memory Map [1]

Since the software for this application only occupies approximately 45K of the available memory, it is mainly to be contained in FLASH memory of the NE64. Very minimal amounts of data are placed in the RAM such as changeable variables including the dynamically updated web page. Due to the fact that memory is vastly limited in this embedded device, the code does not make use of recursive function calls nor does it include large C libraries (such as string.h).

Because the P.E.T. Express utilizes a web server which is to be periodically accessed, the remainder of the code structure is designed to be as unobtrusive to the Ethernet demands as possible. This means that most of the available time in a loop cycle will be available the Ethernet controller. This was accomplished by creating a master polling loop which simply polls various flags. These flags are set using various interrupt-driven peripherals. The motivation for including both an interrupt-driven portion and a polling loop portion to the code was that the polling loop was not responsive enough to accomplish the necessary functions in a timely enough manner, thus the troublesome functions were moved to an interrupt-driven setup. Figure 10.2 demonstrates a basic block diagram of the software implementation.

Figure 10.2: Software Block Diagram

The creation of a standalone application requires a significant amount of overhead in the area of startup code. Startup code is used to initialize ports and settings so that the microcontroller will be able to function on its own without any support from either other applications or controllers. When the system receives a reset signal, a reset interrupt vector in the vector table redirects the system into the startup code sector of memory. Again, because Code Warrior is being used and due to the fact that the shell of the code was already written for us by Freescale, very little startup code needed to be written or modified. (See Appendix A for startup code.) In addition to the code generated by Code Warrior, the SCI port 0is initialized for transmit (LCD) and receive (RFID) at 9600 Kbps baud, Port J6 and J7are initialized as a set of interrupt pins, Port T is initialized astwotimer channels generating a 1 ms interrupt and a modifiable 0-1 ms interrupt (respectively), Port A is initialized as an output enable for the keypad encoder, andfinally Port Bis initialized as an output for the solenoid driver.

Rather than writing the necessary functions to enable internet communication, an open source solution provided by Motorola is implemented, namely, OpenTCP [2]. This solution facilitated a much quicker time to implementation than authoring our own unique TCP/IP stack protocol and enabled the design team to simply insert a few function calls to gain web functionality. The Open TCP/IP source code includes all the necessary RTI interrupts, timer pool, and function calls to make internet functionality possible.

Software Discussion

The software for the P.E.T. Express consists of three main modules: Web server, interrupt-driven module, and polling loop module. The web server module is actually partially an interrupt-driven module as well, but has been included in its own module because it consists almost entirely of either computer generated or provided code. As mentioned before, the OpenTCP module provides all the necessary functions and function calls to provide the user with a functional web server. In order to personalize the web server application, a few additions had to be made. First, the index.htm file had to be modified to incorporate the P.E.T. Express homepage rather than the example code provided. Figure 10.3 shows a screen shot of the homepage.

Figure 10. 3: P.E.T. Express homepage

The homepage only provides direction for the user to either send information to the microcontroller or to poll the microcontroller for information. The functions for these links had to be established using a combination of means. The TCP/IP stack directs users to their desired locations by means of a hash table (filesys.c), which was modified using a hash calculator to gain the proper redirection for the team’s needs. As discussed earlier, the code was allocated primarily in the FLASH section of the microcontroller’s memory. Web pages that reported current informationfrom the microcontroller had to be dynamically written. Dynamically writing a page is accomplished by simply filling a string or array of characters with HTML formatted text and data. This data included live information pulled from pet name variables and system status variables that were currently loaded in RAM on the microcontroller.

On the other hand, web pages that changed information by means of a user interface were implemented using a static HTML Form stored in FLASH and an accompanying CGI script. CGI (Common Gateway Interface) is a way of interpreting data that the user enters via a web page. In this case, the HTML Form sends a string of encoded data to the web server. The CGI script interprets this string and updates the pet variables and system status variables in RAM accordingly. Below are sample screen shots of the dynamically-created web page and HTML form web page.

Figure 10.4: Dymanically-Created Webpage

Figure 10.5: Sample of Static HTML form

The next major module of the P.E.T. Express software is the interrupt-driven functions. In order to decrease the response time, many of the functions originally implemented in the polling loop where transformed into interrupts, including the SCI, keypad, timers, and solenoid duty cycle. Each of those items has with it an associated interrupt flag. The SCI interrupt is implementedfor the serial receive data port (the RFID reader as the port’s input) andis executed when the receive buffer full flag is set. Upon receipt of the interrupt, the data is read from the buffer and the flag is cleared, allowing the port to continue receiving data. Even though the NE64 has two SCI ports, the system is implemented using only one of the ports. This was done to allow for future expansion to another port as in our case, both of the peripherals requiring an SCI port only needed to use only one direction of data transmission (Transmit line for LCD and Receive line for RFID). In much the same fashion as the serial interrupt was used, the port J keypad interrupt called a function that quickly grabbed the data from the keypad data bus, set a keypad data ready flag and then returned to the main loop. In this method, the processor only checks and captures data from the keypad when it receives data. This opens up a few clock cycles in the main loop.

The NE64 timer channels are used to control a number of things. The microcontroller is equipped with 16-bit counter and four input capture/output compare channels. Due to a strong dependence on time in this system, this application utilized the primary timer channelto generate an interrupt every millisecond. This interrupt serves to update the system time (incrementing seconds, minutes, and hours). Along with this,the timer interruptapplies comparisons checks for engagement time limits for the solenoid and audio feedback. Asecond timer channel was used to control the duty cycle of the engaged solenoid. By setting this channel to 1ms or less, the duty cycle of the port pin driving the solenoids was varied from 100% down to 50% depending on what mode the door was in. (The second channel’s interrupt function disabled the output to the solenoid driver pin while the first channel enabled it, thus by setting the second timer channel’s interrupt to 0.5ms, a 50% duty cycle could be generated). For general operation, the duty is set at 100% for the first second it is engaged and then is reduced it to 50% for the remainder of its engagement.

The final major component of the P.E.T. Express is the polling loop. This is best demonstrated in flow chart style before a written explanation is offered.

Figure10.5: Polling Loop Flow Chart

As is indicated by the flow chart, the main loop starts by checking for an Ethernet link, then controls the solenoid engagement and sets the duty cycle values. Next, the door access control routine checks for access permissions, the buzzer control routine sets the audio signal on or off based on the time, and finally menu navigation and keypad data are processed in the two menu routines which then display the correct menu information. Each of these steps will now be discussed in further detail.

The Web Server routine first checks for an active Ethernet link, then if it finds one, advances into a series of function calls. The first function called is Wait_for_UpdTcp, which tries to receive an Ethernet Frame. The next function it calls is arp_manage, a function that manages arp cache tables. Finally it calls https_run and tcp_poll functions which checks the TCP sockets and performs the action prescribed by the TCP socket. If there is no link, the routine will continue without entering any of the aforementioned functions.

The next routine in the loop is solenoid control, which sets the solenoid duty cycle by changing the value stored in the Timer channel 6 register, the register that the timer counter compares.

The Access Control routine is called, which consists of a number of function calls. First, the override switch, input Port J0, is checked for assertion. If it is asserted, the solenoids are enabled and the duty cycle is set to 100%; if not, the solenoids are disabled. As long as the system is not in the default menu, the access controls are disabled to RFID tags. If this criterion is met, and the RFID flag is set, Permissions_Check is called. This function checks for a valid RFID tag (one that has been preprogrammed into the system), and if a valid tag is found, calls a secondary function entitled Check_Times to check the access times. Check_Times uses an algorithm to convert the various times, which are stored as ASCII arrays, into integers. These integers are then analyzed to determined if the current time is within the boundaries during whichthe system is accessible for that RFID. Again, if this criterion is met, the display changes to “Valid Detect!”, the solenoids are enabled, the duty cycle is set to 100% and the RFID interrupt is disabled by turning off Port J6. If this criterion is not met, however, the display changes to “Pet Denied” and a denial alarm is enabled. The Access Control routine does one final check before completing; it disables the solenoids if the timers have expired and the system is not in override.

After completing the Access Control routine, the system moves into the Buzzer Control routine where it checks the keypad beep and denial alarm timers and disables Port B6 or B7 respectively.

The final two routines, Menu Navigation and Menu Display, are entered only if the keypad flag is set. Menu Navigation and Menu Display are essentially Moore-model state machines; their output is determined by both the current state and the current input. The Menu Navigation routine contains all the actions of the state machine, in that, it assigns new menu levels to the system in the intermediate levels and calls the various functions at the bottom levels based on the keypad input. If the system is not at a bottom level, then Menu Navigation simply assigns the next menu level to go to, but if it is on a bottom then it will incite a function associated with that level, for example, time change, name change, assign RFID. The Menu Display routine, on the other hand, only has one function, namely to display the information associated with the current menu level. Once this function is complete, the polling loop is complete and the system begins iteration.

The menu navigation and display modules may best be understood in algorithm form and shall therefore be listed:

1. Check for key press:

1. if present, move into menu functions go to 2.
2. if not, continue polling loop to completion.

1. Read keypad value and perform corresponding action by setting the menu level or performing the corresponding function.
2. Read the menu level and display appropriate menu
3. Continue polling loop to completion.

References

[1] MC9S12NE64 Data Sheet

[2]Web Server Development with OpenTCP