Task description

Emulate a postfix parser using the Basys MX3 development board.

Postfix notation is also known as Reverse Polish notation

Demonstration

Your finished product should look similar to this. The behavior of some of the features can be different, as long as the specification is fulfilled.

Documentation

• Title page
• Declaration of originality
• List of abbreviations and terms (can be omitted if not present)
• Table of contents
• List of figures and tables (can be omitted if not present)
• Description of the program
  • Program flow
  • List all of the error cases and how they are handled
  • List and describe all error codes
  • List and describe all operation codes
  • Explain your data structure
• Summary
  • Write a few sentences about your approach to the task and progression during it
  • Write a few sentences about the task itself and the complexity of it
  • If possible, give an estimate on the workload
  • Would you recommend using this task in the future? Would you change anything about it and if so, what?
  • Additional comments, emotions, thoughts
• List of references (can be omitted if not present)
  • Everything that wasn’t covered within the subject and that you didn’t create on your own.
  • This includes help from a friend or a colleague: https://libraryguides.vu.edu.au/ieeereferencing/personalcommunication
  • If you used AI tools (i.e. ChatGPT), they must also be referenced
  • All references must be precise. References such as stackoverflow.com or google.com are meaningless. It must be directly to the page where you got the information from.

Note: Function documentation also a part of the documentation requirement, which must be written into the code. For every function, detail its purpose, parameters, requirements for parameters, return value and possible side effects.

I/O interaction

• SW dip switches – task selector
• LCD – used to show the values and operations
• 7-segment displays – Used to display the operation and error codes
• LEDs – Used to indicate end of task or error state
• Push buttons – initiate selected task,  open/close settings menu
• ADC – used to change the settings.

General requirements

• The postfix parser must use a stack data structure to store the working data.
• The stack size is 8 (elements).
• The test cases are given as text strings.
  • Space is used as a separator
  • The strings will contain numbers (positive and negative integers) and operations (+ – / *)
• Must be able to handle addition, subtraction, multiplication and division operations
• The results of intermediate steps  and the result can be in between -999 and 999. Numbers out of this range must cause an error.
• Only a single task may be active at the same time
• Operations must be repeatable without resetting the board.

Display of operations and settings

• The default update rate for the board must be 1 second. This is used when the board starts up or is reset. This includes updates for the display and 7-seg indicator when doing operations.
• The update rate must be adjustable.
  • The option to adjust settings must be available when boards starts up, after it has finished a calculation and when it’s in error state.
  • To change the update rate, select a push button on the board that is not being used. A click of that button enters the settings.
  • In the settings, use ADC to control the update rate.
  • Update rate should be selectable between 0.1 seconds to 2 seconds with a precision of 0.01 seconds.
  • You need to use the full range of the ADC to control it. There must not be a dead zone on the end.
  • Second click of that button goes back into operation mode, from where an operation can be started.
  • Holding down the button must not start to toggle in and out of the settings.
  • Document which button is used for this and how did you adjust the ADC range to match the the required precision.
• Each step in the calculation must be shown to the user for either the default time if not adjusted or the time set in the settings.
  • You must display the numbers it pops from and pushes to the stack on the LCD (e.g. Push 75 )
  • You must display the calculation that is being executed on the LCD (e.g. -57 + 3 = -54 )
  • Each operation type  must be shown on the 7-segment displays with a unique code. These codes must be documented.
• Once a calculation finishes, use the 8 LEDs to indicate completion. Figure out a pattern that you want to use and document it. It must be clearly different from the pattern used for the error case described below.

Errors cases

• Must handle stack overflow, underflow, division by 0, improper postfix notation, number range overflow and underflow as errors
• Uniquely identifiable  error codes must be shown on the 7-segment displays. Used codes must be documented!
• In case of an error, all of the  LEDs must blink with an interval of 1 second (infinite / until new task is initiated)
• Initiating a new task must bring the user out of the error state

Debugging statements, features

You are allowed to leave additional debugging features into the final code. E.g. You can use the second row of the LCD and LEDs to display additional information when your program is running (e.g. stack information).

The requirements described before must however be completed and they must not be obstructed by the debugging information, if left in the final product.

Test cases

Configure the solution in a way that every DIP switch would control a test case. Multiple test cases are not allowed to be active at the same time.

Note, the first three tasks will result in a valid answer, while the latter ones will trigger different error cases.

All necessary files for the homework can be found here.

Recommended approach

For this homework, you will need access to the development board. They are available for use in the classroom only.

It’s recommended that at home you will simulate the functionality of your final program. Write your calculation functions in a way that they would have the least amount of side-effects (scanf/printf statements).

Then schedule a time to come to the lab and test the board. Scheduling can be done by contacting the instructor, Hardi Selg either on MS Teams or by e-mail or by writing to Risto Heinsar.

Contact and submitting your task

The supervisor for this task is Hardi Selg (Contact by writing on University MS Teams or e-mail to hardi.selg@ati.ttu.ee). 

Submitting of the homework is in two stages:

1. Upload your solution to Moodle: https://moodle.taltech.ee/mod/assign/view.php?id=339483
2. Write a message to the task supervisor using their preferred method of contact to let them know that the solution has been uploaded. It’s also recommended to include the solution in the message!

You need to submit two files:

1. The documentation (pdf document)
2. Your project directory, as a .zip archive

The supervisor can ask for an on-site defense of the solution.