Pre-class Assignment
- [ ] Complete challenge activities 4.3.1, 4.3.2
- [ ] I recommend completing challenge activities 4.2.1, 4.2.2, but will not be grading them
- [ ] Keep working on lab 1
Announcements
- Lab 1 is out and due Feb. 11
- Office hours: by appointment (email me if none of those times work)
- Tenure track search interviews in EE today (2/3) and 2/10, 2/12, 2/17
- AI Policy, Governance, and Responsible AI!
- The group will examine issues surrounding the societal adoption of AI, spanning the infrastructure such as AI models and data centers as well as application domains including healthcare and education. We will also explore approaches to governing these technologies by analyzing the current AI policy and governance landscape, as well as concepts and theories behind them. We will meet once a week (Thursday 3:00-4:00 pm in Martin 022) to discuss selected topics. You can view our WIP syllabus here. No prior experience with AI is required — we aim to foster a community that reflects various aspects of this topic, so we encourage you to join us if you’re interested regardless of your background.
- To learn more about the group and participate, please sign up using the form below: https://forms.gle/6ztCc4tAKKY3BJS49
- Best regards, Reishiro Kawakami ’26 and Linda Huber (The Aydelotte Foundation Postdoctoral Fellow)
Learning Outcomes
By the end of this lecture, you should be able to...
- Explain the difference between a blocking operation and a non-blocking operation, and when to use them
- Use timers in both a blocking and non-blocking fashion using
Timer , LowPowerTimer , and Ticker
- Explain when to use
pc.write instead of printf and why
Lecture Content
<aside>
💡 This is not content that is required to be implemented for Lab 1 (aside from the short line about timers at the end of the lecture). We’ll be using this for Lab 2 which will be released next week.
</aside>
Blocking vs. Non-blocking Operations
The way that we’ve implemented our code for the keypad, we are using what is called a blocking operation. We are waiting for a key press, and our code can’t do anything else while we are waiting:
// get keypress
char buff;
pc.read(&buff,1);
pc.write(&buff,1);
This makes sense in this particular case because we only have one thing to do! However, this might not be desirable in other circumstances. For example, let’s say we also want to toggle an LED once every other second:
#include "mbed.h"
#define WAIT_TIME_MS 500
DigitalOut led1(LED1);
char buff;
int main()
{
// needed to use thread_sleep_for in debugger
// your board will get stuck without it :(
#if defined(MBED_DEBUG) && DEVICE_SLEEP
HAL_DBGMCU_EnableDBGSleepMode();
#endif
printf("This is the bare metal blinky example running on Mbed OS %d.%d.%d.\n", MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION);
while (true)
{
pc.read(&buff,1);
pc.write(&buff,1);
led1 = !led1;
thread_sleep_for(WAIT_TIME_MS);
}
}