ECE 370 — AVR on macOS and Linux

Build your C or assembly program, upload it to the ECE 370 TekBot board, and test it. This guide covers macOS and Ubuntu/Debian Linux; other Linux distributions use different package managers.

Jump to the step you need:

• Install the tools — once per computer.
• Open your lab folder.
• Path A: compile C or Path B: assemble AVR code.
• Upload to the board — the same process for both paths.
• Troubleshooting or quick reference.

Install the tools

Ubuntu / Debian

Open Terminal and run:

sudo apt update
sudo apt install gcc-avr avr-libc binutils-avr avrdude avra make

macOS

1. Install Apple's Command Line Tools, which provide make:

xcode-select --install

Complete the installation dialog before continuing. If the tools are already installed, macOS will tell you.

2. Check for Homebrew:

brew --version

If you see command not found: brew, install it using the instructions at Homebrew's official site. Follow the installer's Next steps to add Homebrew to your shell, then open a new Terminal window.

3. Install the AVR tools:

brew tap osx-cross/avr
brew install osx-cross/avr/avr-gcc avrdude avra

The osx-cross AVR toolchain includes AVR Libc with its GCC formula and depends on AVR Binutils. You do not need to install a separate AVR Libc package on macOS.

Check your installation

On either operating system, run:

avr-gcc --version
avr-objcopy --version
avra --version
avrdude -h
make --version

The tools should print version or help information. avrdude -h displays usage without connecting to the board; it may return a nonzero exit status. If a command is not found, see troubleshooting.

Open your lab folder

Download and extract the files supplied with your lab. Use Terminal to open their folder; for example:

cd ~/Downloads/ECE370-Lab1
pwd
ls

Replace the example path with your folder's location. Put quotes around paths containing spaces, such as cd "$HOME/Downloads/ECE 370 Lab 1". pwd shows your current folder, and ls lists its files.

Choose one build path based on your source filename:

Both paths produce a .hex file: the machine code you will write to the board's flash memory. Keep your source files for editing and submission.

Path A: compile C

A1. Keep the source and Makefile together

Your folder should contain the course-provided Makefile and your C source. Keep any other files supplied for the program too.

ECE370-Lab1/
├── DanceBot.c
└── Makefile

A2. Set the program name

Open Makefile in a text editor and find the PRG setting. It must match your source filename without .c:

PRG = DanceBot

For Lab1.c, use PRG = Lab1. Match capitalization and keep the course's ATmega32U4 target and clock settings. If your Makefile uses a different variable, follow its comments rather than adding a second PRG setting.

A3. Build and check the result

From the lab folder, run:

make
ls -l DanceBot.hex

Replace DanceBot.hex with your program's name. Continue only if make succeeds and the expected HEX file exists. A HEX file left over from an earlier build does not prove that the latest build worked.

The Makefile invokes avr-gcc to compile and link, then avr-objcopy to produce the HEX file. It may also generate .o, .elf, .lst, or other intermediate files; the exact set depends on the Makefile.

After editing: run make again, then upload the new HEX file. If you changed build settings or need a full rebuild, use make clean followed by make, provided the course Makefile defines clean. That target removes generated build files.

What about make program?

Inspect the program target before using it. If it hard-codes /dev/ttyACM0, it will need adjustment for another Linux port or a macOS port. The explicit AVRDude commands below let you choose the detected port without editing the Makefile.

Path B: assemble AVR code

B1. Keep the source and include files together

For the Lab 1 example:

ECE370-Lab1/
├── BasicBumpBot.asm
└── m32U4def.inc

The source includes the device definitions using .include "m32U4def.inc". This file defines ATmega32U4 register and constant names such as PORTB, DDRB, SREG, and RAMEND. Use the course-supplied file and match the filename's capitalization exactly. Later labs may also need files such as LCDDriver.asm.

B2. Assemble and check the result

From the lab folder, run:

avra -o BasicBumpBot.hex BasicBumpBot.asm
ls -l BasicBumpBot.hex

The -o option explicitly sets the output filename so the upload command uses the right file. For another program, change both filenames.

Continue only if AVRA finishes without errors and the expected HEX file exists. Read any warnings too; do not upload an old HEX file after a failed assembly.

After editing: run the same AVRA command again, then upload the updated HEX file.

Upload to the board

Use these steps after either build path. The examples assume the ECE 370 ATmega32U4 / AVR109 board; an ATmega32U4 chip alone does not guarantee that a board has this bootloader.

1. Connect and enter the bootloader

Connect the powered board directly to your computer with a USB data cable. Press the board's Reset button as directed by the board handout and check its Bootloader Running indicator, if present.

The bootloader may be active only briefly. Have the upload command ready; you may need to reset again immediately before running it.

2. Find the bootloader's serial port

Run the command for your operating system immediately after resetting:

Ubuntu / Debian:

ls /dev/ttyACM*

Example result: /dev/ttyACM0. Your board may use /dev/ttyACM1 or another number.

macOS:

ls /dev/cu.usbmodem*

Example result: /dev/cu.usbmodem1101. If nothing matches, try ls /dev/cu.usb*.

If several devices appear, compare the list with the board unplugged and again after connecting and resetting it. The newly appearing port is the candidate to use. A “no matches found” or “No such file or directory” message means no device matched at that moment. The bootloader port may differ from the running program's port and may change after reconnecting.

3. Upload your HEX file

Run one command from the folder containing your HEX file. Replace the example port with the port you just detected.

Ubuntu / Debian — C example:

avrdude -c avr109 -p m32u4 -P /dev/ttyACM0 -U flash:w:DanceBot.hex:i

Ubuntu / Debian — assembly example:

avrdude -c avr109 -p m32u4 -P /dev/ttyACM0 -U flash:w:BasicBumpBot.hex:i

macOS — C example:

avrdude -c avr109 -p m32u4 -P /dev/cu.usbmodem1101 -U flash:w:DanceBot.hex:i

macOS — assembly example:

avrdude -c avr109 -p m32u4 -P /dev/cu.usbmodem1101 -U flash:w:BasicBumpBot.hex:i

4. Check the result and test

Look for AVRDude's successful write and verification messages and no errors. The board should then leave the bootloader and run the program; follow the board handout if a reset or power cycle is needed. Test the TekBot against the lab's expected behavior. A verified upload confirms the transfer, not the correctness of your program.

Troubleshooting

A tool is “command not found”

Return to installation for your operating system. On macOS, complete Homebrew's shell setup, open a new Terminal, and try again. brew info osx-cross/avr/avr-gcc shows information about the compiler installation. For missing make, install make on Ubuntu/Debian or Apple's Command Line Tools on macOS.

make reports an error

Read the first relevant compiler error above the final make failure. A message beginning DanceBot.c:42: points to line 42. Fix the source, check PRG and companion files, then rebuild. “No makefile found” usually means you are in the wrong folder or have not downloaded the Makefile.

AVRA cannot find an include file

Run pwd and ls to check the folder. Keep m32U4def.inc beside your .asm file and match the spelling in .include exactly. Linux and some macOS filesystems are case-sensitive. Check any other include files required by the lab too.

No serial port appears

Check board power and use a data-capable USB cable. Reset into bootloader mode and list the ports again immediately. Try another cable or USB port. On macOS, also try ls /dev/cu.usb*. A remote SSH session cannot normally access a board plugged into your own laptop; run the upload locally.

“Permission denied” on Ubuntu / Debian

If the port exists but you cannot open it, a one-time workaround is to repeat the upload with sudo:

sudo avrdude -c avr109 -p m32u4 -P /dev/ttyACM0 -U flash:w:DanceBot.hex:i

Use your actual port and HEX filename. For repeated use on your own computer, check the port's owning group with ls -l /dev/ttyACM0. If it is dialout, add your account to that group:

sudo usermod -aG dialout "$USER"

Log out completely and log back in before retrying without sudo. On a managed computer, ask the administrator. macOS normally does not need sudo for this workflow.

AVRDude cannot open the port or communicate

1. Check the detected port again; do not assume the example name is yours.
2. Close serial monitors and other programs using that port.
3. Reset into the bootloader and run the upload command promptly.
4. Confirm -c avr109, -p m32u4, and the correct HEX filename.
5. If communication still fails, check the board's bootloader instructions with your TA.

If the device signature is wrong or verification fails, stop and check the board, target, and connection. Do not bypass these checks with -F or -V.

The HEX file is missing, or the board runs old code

Run pwd and ls to check your folder and filename. Rebuild with make or AVRA, resolve all errors, and upload the freshly generated file. An existing HEX file can be stale after a build failure.

Quick reference

Use this once setup is complete. Replace the filenames and port with your own; run only the build command for your source type.

Each time you change the source: edit → build successfully → reset → check the port → upload → test.

References

• Homebrew installation and AVRA formula.
• osx-cross AVR toolchain installation.
• AVRA usage and output options.
• AVRDude option reference.

Use the current lab handout for board-specific reset behavior, clock settings, source files, and submission requirements.