Digital Systems Design Using Microcontrollers¶

Course Overview¶

• Institution: Cornell University
• Course code: ECE 4760 / ECE 5730
• Track: Capstone Design and Engineering Practice
• Tier: S
• Role: Mainline
• Level: Advanced
• Last reviewed: 2026-07-28

Cornell University's Digital Systems Design Using Microcontrollers provides a current capstone spine around RP2350 and Pico 2, complete laboratories, and a long-running archive of student projects that connects embedded implementation, measurement, testing, and public project evidence.

Why choose this course

Mainline course. A particularly complete and well-structured option for this track. Review note: S+

Before you start

• Recommended foundation: Introduction to Electrical Engineering
• Recommended foundation: Electronics Laboratory and Measurement
• Recommended foundation: Programming and Engineering Computing

Verifiable learning outcomes

• Explain the core models in Capstone Design and Engineering Practice, including their assumptions and limits
• Solve representative derivations and problems, checking units, limiting cases, or numerical results
• Complete a reproducible experiment or implementation with raw data, parameters, versions, and verification

Workload and pacing

13 weeks at 11 hours/week. This maintainer planning estimate is derived from course role and the density of public practice and labs; it is not a provider workload promise. Pilot two weeks while logging instruction, practice, lab, and review time, then adjust the remaining plan when actual effort differs by more than 25%.

Safety level

Low energy. Keep work isolated, current-limited, and low energy; verify ratings, grounding, short-circuit risk, and emergency shutdown before power-up.

Course Resources¶

Software, hardware, and cost

Software

• Maintainer-suggested open-source/free verification path: Git, Markdown, automated tests, and a project-appropriate KiCad, FreeCAD, Python, or HDL toolchain
• The resource inventory lists public code coverage; pin interpreter, dependencies, toolchain, datasets, and PDK versions where applicable

Hardware

• The resource inventory lists lab coverage; prefer borrowing or sharing the following equipment: prototype components, current-limited power, measurement equipment, safety controls, and spares selected after requirements and risk review. Verify ratings, authorization, and safety conditions only after the provider lab manual explicitly calls for them

Cost note

The suggested software stack is available open source or free; this is not a provider requirement or bill of materials. The actual boards, components, fabrication, and instruments—and their costs—depend on the provider lab manual, region, and local availability; prefer simulation, borrowing, or sharing before purchase.

Public resource coverage

Resources and access

“Listed by official page” means the link was discovered on a successfully fetched official source on the verification date; it does not guarantee that every region or account can open the target directly. Access does not grant redistribution rights. Re-check the provider page, target link, and third-party notices before downloading, adapting, or publishing material.

Practice and Verification¶

Practice loop

Digital Systems Design Using Microcontrollers · Cornell University ECE 4760 / ECE 5730: Requirements-to-Verification Safe-System Digital Prototype

This is a maintainer-suggested self-study project for Digital Systems Design Using Microcontrollers · Cornell University ECE 4760 / ECE 5730, not an official course assignment. Complete a cross-circuit, software, or control digital prototype for Capstone Design and Engineering Practice, connecting requirements, architecture, cost, risk, tests, and postmortem while keeping every high-risk physical element in simulation.

Origin: Maintainer-suggested project

Deliverables

• At least ten traceable requirements plus stakeholders and boundaries, architecture, interfaces, risks, and cost baseline
• Digital-prototype sources, interface contracts, test fixtures, and continuous-integration configuration
• Requirements-to-test traceability matrix, raw test, performance, and cost data, and change log
• A final design report, demonstration video, and project postmortem with root causes and follow-up actions

Verification

• Link every requirement to at least one repeatable test and pass 100% of critical requirements
• Cover startup and shutdown, minimum and maximum input, interface loss, timeout, and resource exhaustion
• Recompute at least five key metrics with an independent checker and match the report
• Inject one cross-module fault and show monitoring or degradation reaches the declared safe state in time

Reproducibility

• Commit all requirements, designs, sources, tests, BOM or cost evidence, and a README
• Pin toolchain, dependencies, configurations, data versions, seeds, and one-command build and verification
• Preserve raw test data, build-artifact hashes, change and decision records, and the generated report

Safety boundary: Simulation only — Default to a digital prototype; do not physically implement mains, high voltage, high current, energy storage, RF power, lasers, moving machinery, vacuum, chemical processing, or human-related work unless moved to a compliant facility under qualified supervision and a new risk approval.

Risks, gaps, and boundaries

The current RP2350 and Pico 2 sequence assumes prior C programming, digital systems, and basic electronics.

Completion evidence

• Weekly learning log with time, questions, corrected errors, decisions, next steps, and links to that week's reproducible artifacts
• Design-review package with requirements and constraints, trade-offs, editable sources, applicable ERC/DRC/timing/stability checks, exports, and a reproduction test
• Code repository with pinned dependencies and toolchain, a minimal run command, tests or waveform/benchmark checks, expected output, and license notes
• Experiment package with schematic/setup, calibration record, raw data, uncertainty, safety checks, failed runs, and steps to rebuild plots from raw data