Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

EEET2246 – Engineering Computing 1 – Week 5 and 6 Laboratory Tasks

Overview:

Laboratory Exercise 2 consists of two sets of Laboratory Tasks (defined in this document) and one Laboratory Code Submission assignment (Laboratory Code Submission 2). The Laboratory Tasks are designed to help you build your code solution for the corresponding test. Part A is designed to be completed in week 5, whereas, Part B should be completed in week 6. Your combined report for Part A (worth 5%) and Part B (worth 5%), as well as your Laboratory Code Submission 2 submission (worth 10%) are due in week 7 via Canvas. The total combined value for Laboratory Exercise 2 is 20% of your final mark for EEET2246. Remember that the Lab code submission is a separate assessment and should only be a single *.cpp file.

All assessment items for Laboratory Exercise 2 are due by Friday, Week 7 at 11:59pm.

Assessment:

There are two types of tasks – explanation- and code-based. Explanation questions require you to provide a diagram, pseudocode, written descriptive answer and/or screen captures based on the question in your report. These types of questions will have a heading of Explanation based.

Code-based means you will need to submit a working standalone *.cpp file. This type of question can be identified by the heading Code CPP file Required. The submitted *.cpp files must be fully functional and compile without modification to achieve full marks. Each question that is marked as “Code CPP file Required” requires a separate *.cpp file to be submitted. The naming convention is as follows: ‘s1234567_PartA_TaskAx.cpp’, where s1234567 is your student number and PartA_TaskAx corresponds to the actual question you are answering. You may also need to supply some screen captures of your program under different situations and a brief description in your lab report to assist your tutor running your code or describing its operation, etc. Without this you may not get a mark for a submitted piece of code unless it is extremely obvious how it is meant to work. However, please do not put screen captures in your report that have unnecessary information in them that does not relate directly to the question.

IMPORTANT: Lab Report Page Limit will apply to this assessment item. Your combined Lab Report for week 5 and 6 Tasks should be no longer than 10 pages long (including all diagrams and images). The shorter and more succinct the report the better. That is, if you can answer all questions in 3 to 5 pages, then please do so. Any answers that go over the page limit will be ignored by the tutor, hence you will lose marks (unless you have prior approval from your lab tutor).

Note: All tasks are marked on a scale, however, if code is not submitted for a given task (when required) or if it does not compile, you will not score marks for that item.

Regardless of the study mode, please use the Collaborate Ultra Lab session or the face-to-face lab sessions as a Q&A to work through the tasks. Your lab tutor will not mark any work during any of the online or face-to-face sessions and will only be available during the laboratory class session time to answer questions and provide assistance.

Submission Process:

THE FIRST PAGE OF THE REPORT MUST SPECIFY: Your full name, Student number, number of *.cpp files submitted, enrolled Laboratory session time slot and tutor name. The report along with *.cpp files must be uploaded via Canvas before the deadline to avoid any late penalties.

Suggested Lab Report format:

Part A – Week 5 (5%)

An essential requirement for Engineers is the ability to write software that will interface with a wide variety of hardware systems. In the EEET2246 laboratories we will be using the OUSB Board to demonstrate how software can interact with hardware and the influence that this has on the software we will be developing. For students that do not have access to a physical OUSB Board, the OUSB Board Simulator can be used. Note that the OUSB Board interface software (ousb.exe) and the Simulator (ousbsim.exe) only work under a Microsoft Windows based PC environment and must be used with a directory pathing that is on a local hard drive with no white space characters in the path name (i.e., avoid using networked drives and default user profile locations). The details of the OUSB Board interface software and the OUSB Board Simulator can be found on the course ‘Canvas’ website under the OUSB Board Resources page.

NOTE: All Laboratory Exercise 2 Tasks and Code Submission 2 can be completed with the ousbsim.exe simulator alone. Just remember to rename the simulator to ousb.exe so that you only use the ousb command in the Lab Code Submission.

This laboratory will require you to perform the following tasks with the OUSB Board:

This week you are encouraged to build up your code solutions sequentially (where appropriate) as you move through each task, however you should keep a copy of each solution as a standalone piece of code by using block comment (/* */) to save the code for future reference.

Tasks

1. To communicate with a OUSB Board, an intermediate program is required (ousb.exe). This file can be downloaded from the EEET2246 Canvas shell website by navigating to the Modules page and then selecting ‘OUSB Board Resources’ page. Once on the “OUSB Board Resources” page, download the ousb.exe file by clicking on ‘ousb.exe’ link. For your application to access the ousb.exe file, it must be placed in the same folder (directory) as your *.cpp file. However, initially, we will explore the various command-line options of the ousb.exe application by sending it commands via the console command window. To do this, create a new Visual Studio Project and place the ousb.exe file in the same folder as the projects *.cpp file. Open a command prompt (using the techniques developed in laboratory exercise 1 tasks) and navigate to the folder containing your Visual Studio project with the ousb.exe file in it. Run the executable by typing ‘ousb’ and then press enter at the command line console. You should be displayed with a screen similar to Figure 1.

Figure 1 – ousb.exe Command Line Options which is used to communicate to a Physical OUSB Board

Figure 2 – ousbsim.exe Simulator Command Line Options which is used to communicate to a Virtual OUSB Board

Regardless of if you are using a Physical OUSB Board or using the OUSB Simulator, it is helpful to understand what the simulator is trying to emulate. Below is a picture of a Physical OUSB Board showing the DIP switches connected to PINC and the 8 LEDs connected to PORTB.

Figure 3 - OUSB Board showing the DIP switches connected to PINC and the 8 LEDs connected to PORTB.

The LEDs on the OUSB Board are connected to the individual bits of PORTB, from bit 0 through to bit 7. Hence PORTB can represent the values 0 to 255 in binary (0b00000000 – 0b11111111). Similarly, each switch is connected to the input of PORTC. However, as these bits are setup as inputs, you would need to read the value of the DIP switches using the PINC register (pronounced as “Port In C”). Additionally, the wiring of the DIP switches inverts the logic on the port. This results in the settings shown in Figure 2 having a value of 254 (0b11111110) as bit 0 is set to ON (which is grounded). 

Given the description of the parameters in Figure 1 through to Figure 3, determine the command line arguments that would be required to turn on every second LED (Most Significant to Least Significant) on the  using either the ousb.exe or ousbsim.exe application. In the case of the simulator, the value you will want the simulator to write to the portb.txt file will be the decimal equivalent of 0b10101010 or 0b01010101.

Hint: What value is required to turn a LED on and how can you determine the value in binary? You can also use the OUSB Board reference manual to determine the name of the register that is connected to the 8 LEDs on the board.

Explanation based

Explanation based

4. The tasks up until now have utilised the command line to run the ousb.exe (or ousbsim.exe) executable. Whilst demonstrating how the application/s operate and the parameters required, this technique needs to be extended for the Laboratory Code Submission 2. One method that can be utilised to communicate with an external application from your program is by utilising a construct known as a ‘pipe’.

You can think of a ‘pipe’ as a method of transferring data from one application to another. Utilising a ‘pipe’ allows commands to be sent to the ousb.exe application and for the data produced by the ousb.exe application to be returned back through the pipe (to the original program that opened the pipe).

As a starting point, it is suggested that you download the ‘OUSB_getting_started_code.cpp’ file from the Canvas shell (under ‘Week 5 and 6 Laboratory Tasks’ page). This code example contains the all the basic code required to communicate to the ousb.exe or ousbsim.exe executable via a C/C++ pipe.

For this task, identify the code that is responsible for writing to ‘PORTB’ via the ousb.exe or ousbsim.exe executable. Write a program by copying the relevant OUSB commands from Question 1 into your program and use a program control statement to automatically increment the value of ‘PORTB’ from 0 to 100 with a step size of 1. Note that you should open and close the pipe (_popen() and _pclose()) every time you attempt to read / update the values of the LEDS.

Hint: Consider using the _itoa_s() function. Take a screenshot of the console window (and/or photo of the board) demonstrating that the OUSB board is being updated.

Hint: You might also find the ‘OUSB_Multi_read_write_example.cpp’ file useful too, however you should write the pipe code within a for loop instead of coping it over and over again to get full marks to overcome the issues presented in the ‘OUSB_Multi_read_write_example.cpp’ file. [2 marks]

Explanation based

Code CPP file Required and Explanation based

Extend your program to read the value of 'pinc', convert the characters into an integer and then add 12 to it before displaying the final value on 'portb' and on the console. Explain in your report what the maximum value of pinc can be before you have issues writing the final value to portb. (i.e. relate your discussion back to the maximum value that can be displayed on portb).

Once you have finished these tasks you are free to start your week 6 lab tasks. You can also start write your solution to the Laboratory Code Submission 2 assessment item. Make sure that you download and read the Laboratory Code Submission 2 proforma *.cpp file which is available on Canvas. 

Part B – Week 6 (5%)

To date, many of the programs that you have written are based around the use of program control statements and converting user input (in the form of command line arguments) into numerical form. However, as you begin to write more complex programs additional functionality will be required. Whilst most processes can be developed based on the material we have covered, one of the key benefits of using a programming language such as C++ is the ability to incorporate code that has been written by others. In C++, we can do this by utilising a concept known as functions.

A function (definition) consists of three core components which are the function name, function parameters and the function return type. If we take a C++ function atof() that we have been using throughout this course, the full function definition is written as: ( http://www.cplusplus.com/reference/ ) double atof (const char * str);

Using the C++ reference website ( http://www.cplusplus.com/reference/ ) determine how the abs() function can be used. What are the function parameters and the return type? Write a small program that defines a negative integer (between -1 and -255), converts it to a positive value and then displays it on the console window. Place a table in your report indicating the specific values you applied to your code as well as an example of the output. [2 marks]

Via the command line arguments enter the value of 168. Write a small program to determine if the input argument is truly numerical by stepping through the argument via a 'for' loop using the two different methods: a compounded logical expression and the isdigit() function. At the first invalid digit your program should display an error message and exit. Change the command line argument to 45a21 to check your result.

Week 6 laboratory tasks would have most likely exposed you to the following code expressions/statements:

Part B - Summary of Code Expressions: