f2022-public-labs

The ECE 36200 Lab Practical

Introduction

This document aims to demystify anything and everything about the lab practical - its administration, the infrastructure involved, and most importantly for you, how to prepare for it.

It is our hope that providing all this information removes the stress that is typical of exams, and allows you to focus on being prepared to tackle any task that we may give you.

What is going to happen in my lab section the week of the lab practical?

Summary

The lab practical will be 2 hours long and will require you to implement a design by configuring a small subset of peripherals (about 2-3) on the STM32 microcontroller you have been using the past 8 labs. Show up to your lab section on time. We may need a bit of time to set up the lab machines and STM32 test breadboards (which will be thoroughly checked and not have any wiring issues) for the practical. The process involves signing into a test account on which we will set up SystemWorkbench and the instruction manual for your specific practical.

Office Hours

Except for Monday, there will be no office hours in the week of the practical (Tue - Thu) to ensure the integrity of the lab space. Please direct any and all questions to Piazza.

24x7 lab access will also be revoked for the week of the practical, so please do not enter the lab without prior authorization.

Piazza

Posts on Piazza during this week will be limited to instructors to ensure no accidental leaking of practical details. (In general, you are expected not to share any details about the practical with your peers before everyone has taken it.)

Do I need my lab kit?

No.

You will need only your OLED display. Your practical will be entirely focused on your coding, and we’ll give you a prebuilt breadboard with all the devices you’ll need. Just bring your Purdue ID (or your digital one on your phone, which you’ll keep in your bag afterwards). We will thoroughly check all of these to ensure you do not have any hardware issues before your practical.

At the beginning of your lab section…

Try to show up early to your lab section, please wait outside until a lab GTA walks out and lets you know that the lab is ready for you to come in. You will then be asked to line up, put all electronic items on your person into your bag. If you have a physical Purdue ID, you may keep that with you, but for digital IDs, show that to your lab GTA before you enter your lab and then immediately put your phone in your bag. Paper and pencil will be provided if you need it. Silence your phone and any other audible devices before you enter.

Your TAs will indicate the designated space where your bag goes, and you will be told which station to go to. Enter and sit at your station quietly, as there may be students already in the section who are taking their practical. Your station will have a LabPractical program open with instructions on what to do - please read it carefully, and do not touch the mouse or keyboard yet. Wait until all students have been seated, and watch for the lab GTA to give you the signal to start.

You won’t need paper + pencils, but if you would like it anyway, ask one of the TAs as you enter.

During the practical

You will then enter your username into the application, click Validate, which will confirm your identity and save it, and enable the button that will allow you to start the practical. Clicking this will close the application, and open SystemWorkbench with a configured workspace and a web browser with the instruction manual webpage. Drag the windows to your liking, and follow the instructions on the webpage to do the practical.

Practical manual page

Doing the practical

The STM32 will be fully wired up with all the devices you may need for the practical. Your focus will be on writing the code in SystemWorkbench, and hitting Run/Debug to flash it to the STM32.

The practical is arranged as steps (similar to your lab experiments), with points and expected behavior for each step. In the event that you cannot complete a step, you do not need to indicate it to your TA - simply do the best you can, and leave your computer as is. Your TAs will assign partial credit based on the correctness of the work you will have done so far.

What if I need a base converter?

If you need a number converter, you may use the in-built calculator on Ubuntu - it comes with a programming mode that allows you to convert between bases. Click the shortcut on the left sidebar, or press Start and type calculator to bring it up.

Do I need to write the entire file from scratch?

You’ll be filling out some empty functions for configuring peripherals. If the functions are interrupt handlers, you need to get the name from a certain file and implement the function yourself (it always has a void/no-args function signature).

The main function will always be prefilled with the function invocations, so you don’t need to worry about that. It’s because there’s also stuff to invoke a grader that will run tests, and other custom code to tie it all together depending on the end goal for the practical.

We’ll provide comment blocks so you know where to put the handlers, and where to find the functions.

Will we be provided a function to test our code?

There will be a grader() function call that will be invoked after invoking the functions you are expected to implement. The grader will print something similar to the following over UART:

=================================
Grader for _________ practical
=================================
step1: _/step1_points
step2: _/step2_points
step3: _/step3_points
step4: _/step4_points
step5: _/step5_points
Final score: _/100

This grader determines your score. If there are any accidental inconsistencies between what the grader reports and what you see on your breadboard, the TA checking you off will make the final call.

To see the output via UART from the grader, we will provide a Serial Port application. Click the terminal shortcut on the side (or press Start and type in ‘serial port’), and it will open a terminal window. If it is blank, press the reset button on your STM32 to see the output from the grader. Keep this window open so you can see the output from the grader every time you flash your STM32.

Heisenbugs/Unexplainable Technical Phenomena

Your data is saved on persistent storage even if the computer somehow freezes or crashes, so even if we have to forcibly restart the machine, you should be able to pick up where you left off when we set it up again. We’ll give you extra time if that rare situation happens.

The webpage will contain its own instructions, links to all reference material, and a step-by-step guide on what to do for your specific practical. Read the instructions carefully, use the reference material as needed, and implement the design as per the steps in SystemWorkbench. You should be able to build/run/debug the STM32 and see the results of your code on the test breadboard.

If you are stuck with anything technical, you may ask the lab TAs for help, but keep in mind that the TAs will be instructed to not give you any hints or help you in any way.

Once you are finished…

Raise your hand so that a TA can come over and confirm the functionality of your code on your STM32. The instruction manual will tell them what to check for. Your TA will perform an evaluation based on the circuit, tell you your score, and record it. At that point, follow the instructions to end the practical, pick up your belongings, and leave the lab quietly.

If you did not manage to finish the practical on time, type a comment into your code with your username, leave your lab station as it is, and exit the lab quietly.

In doing this practical, you are expected not to share any details about the practical with your peers before everyone has taken it. Sharing any details will be considered academic dishonesty. This is to ensure a fair lab practical experience for everyone.

What will I be tested on?

The practical will be limited to configuring the same peripherals you have been using the past 8 weeks. If something isn’t familiar, look through the associated lab manual to refresh your memory. Use that to identify the portions of the datasheet to look at for a specific peripheral and its function.

As well as the following “concepts”, not necessarily tied to a specific peripheral:

How do I practice for the practical?

There’s a lot of content to cover, which is why it is worth reminding you that configuring a peripheral should not require you to memorize how to configure it. It’s about knowing where to look for the information you need to configure it. This is why we will provide you with the following:

As much as possible, do not practice using tools on the Internet (eg. Google, ChatGPT) - you will not have access to it during the practical, and the purpose of the practical is to test your ability to configure peripherals based on the given datasheets, not those tools.

Form a process for figuring out how to configure a peripheral

To set up a mock practical, take a lab you’ve already done, and see how much time you can do it in without asking for help, and making use of only the resources that will be given to you in the practical (no Internet, no past code, and most importantly, no other individuals). If it takes longer than your allotted practical time at this point, you need to determine a process for using the tools at your disposal to quickly learn what you need to do to configure a peripheral, and then practice that process so you can do it quickly. Here’s an example of such a process in the worst case.

Let’s say you have some random peripheral, RAND. You did a lab in which you configured RAND to send data out on pin PC1, and receive data on PC2. You see it again in the practical, and you’re told that you need to echo back the data you receive on PC2 back out on PC1. In general for any peripheral, you need to know how to set up the peripheral first, i.e. filling out some init_rand() function, so that it can be used to transmit/receive data.

Your first resource may be the lab manual for the lab in which you used RAND, or the lab prep slides which may have example code you can use. Ideally, it may have the bullet-by-bullet instructions for what to do to configure RAND, but in the less-than-ideal situation that it only tells you how to configure RAND but not enable interrupts, then we need to consider the other resource, i.e. the lab prep slides if you used the lab manual, or vice-versa.

Now that we have the list of instructions on what to do, we need to determine how to translate it into code. This is where the reference manual comes in. It will tell you what registers to set, and what values to set them to (and in a rare case, how to set it). Your knowledge of how to clear/set bits correctly should help you here. If you don’t remember what the name of a certain macro was, Ctrl-Click on any of the defined macros and use Ctrl-F to find it.


Now that our code is written and implemented, we give it a try by running it on the STM32, and inevitably nothing happens. This is where debugging comes in. First do a thorough visual inspection of the code you’ve written so far, looking for things like:

Then, use the debugger to check that values are being set when you set them. An example of something you can catch this way is the SPI data register - if you set it all to 0, that’s an invalid value, forcing the bits to get set to 0111, so you should make sure to reset only the bits you want, not all at once.

Anything else you’d like to be covered?

If you’d like us to check your process and offer advice, ask if anything is covered/not covered on the practical, or any other such questions, please ask on Piazza - we may update this document with an FAQ section if we get enough of the same questions.