EE192: Mechatronics Design Lab

Checkpoint 1 (draft 1-30-2020)

!!!WARNING: The (Piazza post (link, click here)) is the most updated material for this post!!! The following is for reference.

Checkoff Requirements

You may complete and demonstrate these requirements using any processor board, hardware, toolchain, and debugger - though preferably the ones you will be using for the rest of the project. However, we will be unable to provide support for nonstandard hardware, and we may ask you to explain what you are doing with a nonstandard debugger. This lab is designed to introduce you to embedded programming and ensure you have the toolchain and debugger set up in preparation for future labs. Please make sure you start early, in case you need help getting things working. It might be more time-consuming than you think! The checkpoint routine will be as follows:

• C1.1: controlled by a microcontroller, blink an LED at 1Hz, 75% duty cycle. That is, 750ms on, 250ms off, repeating. If using the BeagleBoneBlue board, any of the onboard LEDs are fine.

• C1.2: detect when a switch is pressed, and change the LED (or LED color, if you have a multicolor LED) being blinked. If using the BeagleBoneBlue board, any of the onboard switches are fine.

  • C1.2.1: Timing during the transition is not critical, as long as it's sane. Don't worry about switch bounce, as long as you can usually trigger a single press.

  • C1.2.2: Both LEDs should never be on simultaneously, regardless of when the switch is pressed. We will do our best to rigorously test this.

  • C1.2.3 (updated 1/25): you may interpret “pressed” as either “held down” or “clicked”

• C1.3: Display a text message, such as through the printf console, when the switch is pressed.

  • C1.3.1: The text message must include at least one non-whitespace character.

• C1.4: Set a breakpoint at an event of our choosing, such as the LED turning on or the switch being pressed, as long as it reasonably correlates to a line in your code.

  • C1.4.1: While breakpoint-ed, show us the value of a control variable in your code through the debugger.

• C1.5: The code must be pushed to a git repository that we can see. You may find the librobotcontrol API documents useful. Also, note that while rc_button_get_state takes two arguments, rc_button_get_state(RC_BTN_PIN_PAUSE) (as shown during discussion) works because RC_BTN_PIN_PAUSE is a macro that expands to 2, 5 and macro substitution is based on dumb string substitution instead of being type-safe. I'll note that while this is expedient, this may not be generally accepted best practice - which would be to define a different type completely (like a struct) that encapsulates the relevant data.