ECE 477 Digital Systems Senior Design Project Fall 2006
Homework 10: Software Design Considerations
Due: Friday, September 29, at NOON
Team Code Name: __Smart RFID Poker Team______Group No. ___5___
Team Member Completing This Homework: ___Shawn Ironmonger______
e-mail Address of Team Member: _sironmon__ @ purdue.edu
Evaluation:
Component/Criterion / Score / Multiplier / PointsIntroduction & Summary / 0 1 2 3 4 5 6 7 8 9 10 / X 1
Software Design Considerations / 0 1 2 3 4 5 6 7 8 9 10 / X 3
Software Design Narrative / 0 1 2 3 4 5 6 7 8 9 10 / X 3
List of References / 0 1 2 3 4 5 6 7 8 9 10 / X 1
Appendices / 0 1 2 3 4 5 6 7 8 9 10 / X 1
Technical Writing Style / 0 1 2 3 4 5 6 7 8 9 10 / X 1
TOTAL
Comments:
Comments from the grader will be inserted here.
1.0 Introduction
The smart poker table project is an interesting project when one considers the software design aspect. There is 2 kinds of microcontrollers with a total of 5 in the whole project that code must be written for, see appendix C for the block diagram. There is one central micro and then four modular micros. The project is suppose to be able to track all of the poker chips that are on the playing table. This must be done in a big database that must be stored in the micros ram. Each player must be able to show all statistics on their individual LCDs, which means that all of that data must be transmitted through the software from the central micro to each modular micro. The data that is displayed on the LCDs is controlled by a keypad that must be constantly monitored by the modular micro’s software. This project also requires that the software keep track of which antennas should be active due to what part of the poker game play is in. Over all the software complexity comes from the multiple micros which must all communicate through the I2C bus.
2.0 Software Design Considerations
The main design consideration that is guiding the software development for this project is the fact that there is two microcontrollers. There is the central microcontroller (MC9S12NE64) which must control the rfid readers, control the main database, and relay information to the modular microcontrollers. The modular microcontrollers (DSPIC30f3012) must retrieve data from the central micro and display information on an LCD based on what the user inputs on the keypad.
2.1 Central MC (MC9S12NE64)
Below in Fig. 2.1.1 you will find a diagram of how the memory inside of the NE64 is broken down. Below that in Table 2.1.1 the utilization of that memory and appropriate address mapping is shown relative to our project. Just below that is Table 2.1.2 that shows the address mapping of external interfaces.
Fig. 2.1.1 MC9S12NE64 Memory diagram (reference 1)
Address / Data / Memory type$2000 – $37FF / Variables / Ram
$3800 – $3FFF / Stack / Ram
$8000 – $8FFF / Static variables / Flash
$9000 – $BFFF / Code / Flash
Table 2.1.1 Mappings of memory (reference 1)
Address / Module / External interface$00C8 – $00CF / Serial Communications Interface 0 (SCI0) / Rfid reader bus
$00D0 – $00D7 / Serial Communications Interface 1 (SCI1) / Debug with Computer
$00E0 – $00E7 / Inter IC Bus (IIC) / Modular MC bus
$0120 – $0123 / Ethernet Physical Interface (EPHY) / Web hosting
$250 / PTG / I/O to control atenna relays
Table 2.1.2 Mapping of external interfaces (reference 1)
The code on the NE64 will be a hybrid of interrupt-driven and state machine. Due to the fact that some things are time critical and should interrupt the other processes that are not time critical. We need to capture a chip moving over the rfid reader exactly when it happens. However if we do not respond to a web request in a nanosecond the user will probably not even notice.
Please see flowchart in appendix A.1 for an illustration of the flow of our main program along with the block diagram of the hardware in appendix C.
For debug we plan on using a serial port on the micro to communicate with a pc for initial debug. Once the project is in the final stages we plan on using a maintenance mode and the LCD displays for output.
2.2 Modular MC (DSPIC30f3012)
Below in Table 2.2.1 the utilization of the pics memory and appropriate address mapping is shown relative to our project. Just below that is Table 2.2.2 that shows the address mapping of external interfaces.
Address / Data / Memory type$0801 – $0BFF / Variables / Ram
$0C01 – $0FFF / Stack / Ram
$8001 – $8500 / Static variables / Flash
$8501 – $FFFF / Code / Flash
Table 2.2.1 Mappings of memory (reference 2)
Address / Module / external interface$0200 – $0203 / SDA\I2C / I2C\Data from Central MC
$204 / SCL\I2C / I2C\CLK from Central MC
$02C8 – $02CF / PortB / Keypad
$02E0 – $02E1 / PortF / LCD
Table 2.2.2 Mapping of external interfaces (reference 2)
The code on the Pic will be a hybrid of interrupt-driven and state machine. Due to the fact that some things are time critical and should interrupt the other processes that are not time critical. We need to capture keypad pushes when they happen. However if we do not update the LCD the instant that we receive new data from the central micro the user will probably not even notice.
Please see flowchart in appendix A.2 for an illustration of the flow of our main program along with the block diagram of the hardware in appendix C.
Once the project is in the final stages we plan on using a maintenance mode and the LCD displays for output.
3.0 Software Design Narrative
Note: There is no completed code and therefore there are no “hotlinks” to the code on our web site.
3.1 Central MC (MC9S12NE64)
Please see appendix B.1 for an illustration of the hierarchical arrangement of the NE64’s code. Below is a detailed analysis of each individual module.
· Init ()
o Purpose: To reset all registers and start the MC in it’s normal state and setup the data base for storing all information about chips.
o What it does?:
§ Initialize SP
§ initialize variables
§ setup chip database
§ Starts main ()
o Status: Prototyped
· Main ()
o Purpose: Run the main flow of code.
o What it does?: Steps through all flags and branches depending on flag status.
o Status: Prototyped
· RFID_RTI ()
o Purpose: Setup the RFID_RTI.
o What it does?: Creates a RTI to interrupt on a set time interval to switch from one antenna to the other rotating through all four in a quick enough time to not miss a chip being passed through one of them.
o Status: Prototyped
· Service_RFID ()
o Purpose: Update the database with the new RFID info.
o What it does?: This will determine where the chip has been and where it is going and will update the database appropriately.
o Status: Prototyped
· Send_I2C ()
o Purpose: Update all of the Modular MC with any new data in the database.
o What it does?: Sends any updated data to the modular MCs.
o Status: Prototyped
· Web ()
o Purpose: Run the web server.
o What it does?: This will be in charge of running the web server. It will form Ethernet packets from the database and send them to the requesting PC. This will more than likely consist of many smaller modules that are still to be determined.
o Status: Not picked out yet and developed
o Shareware: Not yet determined, but there will be some included almost for sure.
3.2 Modular MC (DSPIC30f3012)
Please see appendix B.2 for an illustration of the hierarchical arrangement of the NE64’s code. Below is a detailed analysis of each individual module.
· Init ()
o Purpose: To reset all registers and start the MC in it’s normal state and setup the data base for storing all information about the poker chips. Set the LCD to some start up state
o What it does?:
§ Initialize SP
§ initialize variables
§ setup poker chip database
§ Initialize LCD
§ Starts main ()
o Status: Prototyped
· Main ()
o Purpose: Run the main flow of code.
o What it does?: Steps through all flags and branches depending on flag status.
o Status: Prototyped
· Keypad_RTI ()
o Purpose: Setup the Keypad_RTI.
o What it does?: Creates a RTI to interrupt on a set time interval to and scan through the keypad matrix to see if a button has been pressed. It will actively debounce all inputs.
o Status: Prototyped
· Service_Key ()
o Purpose: Take action based on which key was pressed.
o What it does?: Determines which key was pressed and sets up variables for the LCD_Disp () to use.
o Status: Prototyped
· Recieve_I2C ()
o Purpose: Update the database with whatever new data about the poker chips was sent from the central MC.
o What it does?: Determines what variable needs to be updated and updates that variable in the database.
o Status: Prototyped
· LCD_Disp ()
o Purpose: Update LCD display.
o What it does?: If either the user request new information on the screen or the database has been updated then this module will update the LCD display.
o Status: Prototyped
4.0 Summary
This document takes a detailed analytical look at the software implementation for the Smart Poker Table. This document contains detailed mappings of the memory and external port mappings for both the central microcontroller and the modular microcontroller. This document also has organization of the overall code format on each micro with illustrated flowcharts for both. As well as a look at our debug provisions. In addition this document examines the hierarchical arrangement of the code modules and takes a very close look at the details of each module. This document should enable one to easily follow the Smart Poker Table’s software package and rationale behind the coding style.
List of References
[1] MC9S12NE64 Data sheet
\\shay.ecn.purdue.edu\477grp5\public-web\files\spec_sheets\MC9S12NE64V1.pdf
[2] dsPIC30F2011/2012/3012/3013 Data Sheet
\\shay.ecn.purdue.edu\477grp5\public-web\files\spec_sheets\dsPIC30F2011_2012_3012_3013_DataSheet.pdf
Appendix A: Flowchart/Pseudo-code for Main Program
Appendix A.1: Central MC (MC9S12NE64)
Appendix A.2: Modular MC (DSPIC30f3012)
-11-
ECE 477 Digital Systems Senior Design Project Fall 2006
Appendix B: Hierarchical Block Diagram of Code Organization
Appendix B.1: Central MC (MC9S12NE64)
Appendix B.2: Modular MC (DSPIC30f3012)
-11-
ECE 477 Digital Systems Senior Design Project Fall 2006
Appendix C: Schematic Block Diagram of Project
-11-