Pacemaker Challenge on AVR/Butterfly Boards

The design and development of safety-critical embedded systems demand a rigorous methodology that ensures reliability, timing accuracy, and correct functionality under all conditions. This article presents an in-depth commentary and technical walkthrough of a model-based development framework centered around the use of AVR/Butterfly boards, heart simulators, and pacemaker controller systems. We explore the theoretical modeling, software implementation, and hardware interfacing necessary for prototyping safety-critical systems such as artificial pacemakers. With a combination of model-driven design, formal validation, real-time control, and embedded programming practices, this project serves as a valuable case study for medical-grade embedded applications.

Introduction: Model-Based Development for Critical Systems

In domains such as medical electronics, aviation, and automotive control systems, safety is paramount. Any software controlling these systems must be verifiable and deterministic. To meet these goals, this project employs model-based development (MBD) as its central methodology. MBD enables the creation of formal models that can be verified for correctness, safety properties, and functional validity before deployment on hardware.

The key phases in this workflow include:

• Formal model creation using simulation tools and specifications,

• Verification of properties through formal methods and simulations,

• Automatic code generation from the model, ensuring fidelity,

• Validation via real hardware tests, particularly on AVR/Butterfly microcontroller boards.

Embedded Development Concerns and Timing Constraints

When working with safety-critical embedded systems, two primary concerns dominate:

• Real-time responsiveness, especially under deterministic constraints, such as a pacemaker reacting within milliseconds to heartbeats.

• Resource-constrained hardware, which necessitates careful programming to avoid timing delays, memory overflows, or signal misreads.

These concerns are amplified in biomedical applications, where precise, repeatable timing is not just a matter of performance, but of life and death.

Implementation Architecture

The architecture of the system involves a combination of simulation models and physical hardware:

• Heart Simulator: A model that either generates random heartbeats or responds to pacing signals.

• Pacemaker Controller: An embedded control logic that triggers pacing if the heart doesn’t beat on its own.

• AVR/Butterfly Board: The hardware platform that interfaces both simulation and control units.

• Signal Communication: Achieved by reading/writing port values between AVR boards representing the heart and the controller.

Four core components are orchestrated:

• VPace and APace: Represent ventricular and atrial pacing.

• VBeat and ABeat: Represent detected beats.
  Signals are transmitted via GPIO ports on the AVR/Butterfly boards, simulating real electrical communication between the pacemaker and the heart.

The Heart Simulator: Behavior and Extensions

The Heart Simulator mimics two essential behaviors:

1. Autonomous Beating: Random timing between 100ms and 1900ms simulates natural heart rhythm.

2. Resettable Timer: When externally paced, the simulator resets its internal clock to simulate a biological response to artificial stimulation.

To enhance realism, extensions include simulating both ventricular and atrial chambers. This duality allows the system to represent complex timing relationships in DDD pacemaker modes.

The Pacemaker Controller

At the core of the system is a software module responsible for:

• Monitoring beat signals from the heart simulator,

• Initiating pacing if a heartbeat is not detected within a prescribed interval.

Extensions provide advanced features such as:

• DDD Mode: Dual-chamber pacing and sensing.

• Hysteresis: Allowing the heart to beat slightly slower before pacing.

• Rate Smoothing: Preventing abrupt changes in pacing intervals.

This mimics modern pacemaker algorithms and encourages students or developers to explore real-world challenges in biomedical engineering.

The AVR/Butterfly Board Platform

The AVR Butterfly board serves as the hardware backbone of the project. Key features include:

• ATmega169 MCU: Low-power microcontroller with embedded peripherals.

• LCD Display: For real-time feedback and monitoring.

• Sensors: Light and temperature sensors offer opportunities for adaptive responses.

• 4Mbit DataFlash: Used for data logging.

• Buttons and Joystick: For manual input during testing or simulation.

• Speaker: Allows for audio alerts or simulations of pulse signals.

Access to standard header pins and RS-232 further extends the board’s connectivity for additional testing or communication.

Development Environment Setup

Programming and debugging the system requires:

• AVR Studio 4.18 with Service Pack 1: Provides an intuitive IDE for writing and flashing code.

• WinAVR: A GCC-based toolchain that allows embedded C programming for the AVR platform.

The correct installation sequence is crucial: install AVR Studio first, followed by WinAVR to ensure toolchain integration.

Using the bf_gcc Sample Program

To expedite development, the project employs the bf_gcc sample code, which is a GCC-compatible version of the AVR Butterfly demo. This codebase includes usage examples for:

• LCD output,

• Button inputs,

• Power-saving modes,

• Sleep behavior.

Available at Siwawi AVR Projects, this resource provides a foundational codebase for modification.

System Logic and Behavior

The main program logic follows this pattern:

• Initialization: PowerSave, clocks, state pointers, etc.

• Main Loop:

  • Display current state on LCD.

  • Capture button input.

  • Transition to new states if needed.

  • Enable AutoPowerSave or SleepMode if idle.

  • Use AutoPress logic to account for short button holds.

This system enables responsive interaction with minimal power consumption—an essential feature in battery-powered embedded devices like pacemakers.

Hardware Interfacing and Feature Implementation

Joystick Handling

Button inputs are captured via getkey() and mapped to:

• KEY_ENTER, KEY_NEXT, KEY_PREV, KEY_PLUS, KEY_MINUS.

LCD Control

Functions such as:

• LCD_puts() – displays string,

• LCD_UpdateRequired() – signals LCD refresh,

• LCD_Clear() – clears screen content,

• LCD_Colon() – toggles colon display.

These abstractions enable rapid interface development.

Port I/O

AVR ports are manipulated in two steps:

1. Direction Configuration:

   • Example: DDRB = 0xF0 sets upper bits as output.

2. Data Handling:

   • Read: PINB, Write: PORTB.

Similar logic applies to PORTD, keeping in mind that not all pins are accessible due to board layout.

Real-Time Clock and Software Delays

Two methods are employed for timekeeping:

• RTC with Interrupts:

  • Accurate and efficient; used for periodic tasks.

• Busy Waiting with Delays:

  • Less precise; uses util/delay.h for small delays.

Clocks are also used to time music playback, by linking audio functions to timer interrupts.

Generating and Playing Sounds

Sound generation is performed by:

• Defining frequency, tempo, and duration,

• Sending waveform signals to the speaker via OC1A pin,

• Registering sound functions to timer interrupts to synchronize tones.

This mimics auditory alerts that would be useful in medical alarms or alerts in real pacemakers.

Conclusion

This project exemplifies the synergy between model-driven software design and embedded hardware control in the context of safety-critical applications. The AVR/Butterfly board, with its accessible interface and powerful features, enables rapid prototyping of complex control systems like artificial pacemakers. By modeling, verifying, and validating software before deployment, engineers can ensure safety and correctness—a necessity in the medical field. The extensions in pacing logic, user interaction, and signal handling make this a rich project for both academic research and hands-on embedded systems education.

Source: Pacemaker Challenge on AVR/Butterfly Boards