Brian Stratman
Software Design Considerations - Group 2
Introduction:
The double deuce alarm system group is simply taking your traditional home security system and adding a new twist. The system features web based monitoring functionality. The focal point of development is centered around the web based functionality. The system has the capability of naming the location of each of the sensors and also identifying which type of sensor it is. This allows for easy identification of where a trouble signal is coming from and what is going on. When there is a trouble signal, an optional email maybe sent to you and/or a monitoring agency. The other key player in software design was the communication protocol with the systems daughter boards. Each of the module boards has a Atmel processor on it, which read each sensor and provides a level of buffering before transmitting to the main freescale HC12 micro. The protocol used was IIC.
Software Design Considerations:
Design considerations for the overall system are pretty straightforward. The majority of the tough choices are handled by the compiler so we never have to worry about them.
Memory Models:
On the Freescale HC9S12NE64 microcontroller we had 64k of flash and 8k of sram to work with. The sample web server and SMTP client was obtained from Freescale’s website and was used as the backbone of our code. The Metrowerks compiler handled the majority of the memory management deciding what and where data is stored. The only part of the memory model that needed to have any sort of precision was where the settings were saved in the flash memory. The way that the system handles flash is in 512-byte blocks. It was crucial that the settings be evenly distributed in a single or multiple block(s) of flash. When flash is written during normal CPU operations the whole block must be erased and rewrote.
The Atmel ATMega88s had no worries about location of code and memory management. All of the code was developed with the intension of letting the compiler do all the dirty work as far as memory management. All of the code is stored in flash and nothing needs to be saved between system uptimes and downtimes.
Memory Mappings:
The HC12 as stated earlier lets the compiler decide most of the important memory decisions. There are a few global variables associated with the web server and the IIC interface, however the rest are handled as local variables native their own function. The variables are stored in the sram while everything else including savable settings are stored in the flash memory. The flash memory is set up as 3 pages of banked 16K flash blocks and one always-available 16K block. There is no eeprom on this particular HC12 derivative, which is why settings are just self reflashed when they change.
The ATMega chip uses only a small amount of its 8K of flash for code storage. The compiler strictly optimizes the onboard sram utilization, and the eeprom is left unused the Atmel chips don’t need to perform any long-term storage tasks.
Startup code:
For both the Atmel and the Freescale chips code samples obtained from the manufacture’s websites contained the appropriate startup code to get the micros going. For the HC12 additional code had to be created to initialize the IIC bus system. However this was extremely easy as the built in functionality of the “Processor Expert” automatically created the needed code.
Organization of embedded application code:
There are 2 different types of micros and 3 different code images used. The main one is on the HC9S12NE64. This CPU has the most software modules as it does the majority of processing. The ATMege88s have 2 different pieces of code. The one handles standard sensors and the other is designed to handle the keypad. The code structure is as follows:
Freescale HC9S12NE64
Startup code
Initialize Ethernet
Initialize HTTP
Initialize IIC
Ethernet
Initialize
Send packets
Receive packets
HTTP
Initialize
Server
Client-side java applet
UDP (light weight internet communications protocol)
Sending
Receiving
SMTP (email client)
Email sending
IIC (external bus communications)
Initialize
Send data
Receive data
Flash Programming
Erase block
Write block
Atmel ATMega88
Normal Sensors
Sensor type identification
Startup code
Initialize IIC
Sensor polling routine
IIC
Initialize
Send data
Receive data
Keypad
Sensor type identification
Startup code
Initialize IIC
Keypad
Receive key press
Store key press
Keypad status led
LED flash
LED on
LED off
IIC
Initialize
Send data
Receive data
Software design details:
Freescale HC9S12NE64:
Startup code – The startup code is pretty straightforward. It simply runs all of the initialization code for the various other blocks. It also sets up a few miscellaneous items such as the COP watchdog and interrupts.
Ethernet – This code was provided to us from Freescale. It allows us to properly read and write Ethernet packets to communicate with other devices.
HTTP – This code was also provided to us from Freescale. It contains all of the code to run the HTTP server. Modifications to store our custom Java applet were made. The Java applet was derived from an Microsoft Active X applet. The new applet allows the user to see the status of each sensor, as well as, individualize each sensor for easy location by anyone viewing the system.
UDP – More code that originated from Freescale. This allows for simple send and receives from the Java applet to the micro. The code was modified to recognize different keywords so it does different operations based on what the user is trying to do.
SMTP – The last key component obtained from Freescale. This module allows us to create and send an email through an external SMTP server.
IIC - The I2C bus routines were generated using a tool that came with Metrowerks code warrior. All functions related to starting, stopping, sending and receiving data were automatically generated for ease of use. Code was added to communicate specifically with our peripheral boards and relay info to web server.
Flash – Two simple functions to erase and write to a block of flash while micro is in service.
Atmel ATMega88:
Sensor type identification – This routine is simply defined to create an identifier for each type of sensor. It also handles any special operations that vary per sensor type.
Startup code – Contains initialization routines for the timer module, IIC, general port I/O.
Sensor polling routine – This function polls the sensors at regular intervals and stores the status in a variable until the next time the micro is polled by the i2c bus.
IIC – This group of functions controls the I2C bus functionality. This module controls intialization routines as well as sending and receiving data.
Keypad – This module controls all of the logic for receiving key presses from the keypad. As presses are read in they are shifted into a buffer. Once the buffer is full, the next time the HC12 polls the micro it will transmit the key presses and wait for a status byte to be returned. Based on the status byte the status LED is flashed, turned on, or turned off.
Keypad status led – These are 3 relatively easy functions. They simply control the status LED to flash, turn on, or turn off.
Software Documentation:
Flowcharts:
See attached figures 1 and 2
Code listing:
See attached pages
References:
Freescale HC9S12NE64 web page:
Atmel ATMega88 web page:
Processor Expert web page:
- 1 -