Your First Program

Try It — Guess Before You Know

In Project 1 you compiled and ran code that somebody else wrote. Here it is again.

#include <kipr/wombat.h>

int main ()
{
	printf("Hello World!\n");
	return 0;
}

Do not look anything up. Do not ask anyone. Just guess — you will find out in a few minutes whether you were right.

Line 5 is the only line that made something happen on the screen. What do you think the other lines are for?

Line 1 has a # and no semicolon at the end. Every other line looks different from it. Why might that be?

There are exactly two curly braces, { and }. What do you think they are doing?

Learn It — The Template, Line by Line

Every C program you write on the Wombat starts from this same shape. It is called the template.

Semicolons end statements

Look at lines 5 and 6. Both end with a semicolon.

A semicolon does the same job as the period at the end of an English sentence: it says this thought is finished, move on. Leave one out and the compiler runs two statements together, the way a sentence without a period becomes a run-on.

Lines that open a new block — like int main () — do not get a semicolon. The brace does that job instead.

Order matters, and speed is not the point

The controller reads your program like you read a book: top line first, then down, one line at a time.

It is fast. The Wombat’s processor runs at 800 MHz, so it moves from one line to the next far quicker than you can blink. That becomes a problem the moment you want the robot to hold a wheel on, or leave a message on screen long enough to read. You will fix that with msleep() in a minute.

Colors are a hint

The KISS IDE colors your code as you type. That coloring is a free error check — if something is the wrong color, you have made a mistake before you even compile.

Comments

A comment starts with two slashes. The computer ignores everything after them on that line — comments are for people, not machines.

#include <kipr/wombat.h>

int main ()
{
	// You can put a comment on its own line
	printf("Hello World!\n"); // You can also put a comment after a statement
	return 0;
}

Comments have three jobs, and you will use all three:

• Explain what a line does, so you still understand it next week.
• Plan — writing your steps as comments first is called pseudocode.
• Give credit — if you borrow code, you say so in a comment.

Commands you already have

These come with the KIPR library. You do not have to write them. You will meet most of these in later projects — this list is here so you know they exist.

Back to your guesses

Look at what you wrote in Try It. Which guess were you closest on, and which one were you furthest off?

Do It — Make It Yours

Connect to your Wombat the same way you did in Project 1. Open your First Project.

Step 1 — Add a comment and prove it does nothing

Click at the end of the printf line and type:

// Prints "Hello World!" to the screen
printf("Hello World!\n");

Compile. Then run it on the Wombat: from the Home Screen tap Programs, pick your program, press Run.

Why not?

Step 2 — Sign your work

Add three comment lines at the very top, above the #include:

// Author: your name here
// Program purpose: prints text to the screen
// Created: today's date

This is called attribution. From now on, every program you write gets these three lines.

Where else in school are you expected to give credit for someone else’s work?

Step 3 — Start a new project and say hello yourself

Go to Project Explorer, pick your folder, click + Add Project, and name it Printf Statements.

Write a program that prints Hello World! and then prints your own name on the next line.

Plan it as pseudocode first:

// 1. Display "Hello World!" on the screen
// 2. Display my name on the screen

Compile until you see Compilation Succeeded, then run it.

• Both lines showed up on the Wombat’s screen

The two lines appeared at what looked like the same instant. Why?

Step 4 — Slow it down

msleep() pauses the program. The number inside is milliseconds — thousandths of a second.

// Pause for 1 second
msleep(1000);

Fill this in before you write any code:

• My name appeared two seconds after Hello World

Step 5 — Turn your pseudocode into real comments

Good programmers leave the plan in the finished program. Add a comment to the end of each line describing what it does, so your program reads like this:

#include <kipr/wombat.h>

int main ()
{
	// Print "Hello World"
	printf("Hello World!\n");
	// Pause for 2 seconds
	msleep(2000);
	// Print my name
	printf("Hello Sam!\n");
	return 0;
}

Step 6 — Break it on purpose

Now the important part. You are going to make five mistakes deliberately, one at a time, so that when you make them by accident you already know what they look like.

For each one: break it → compile → write down what the error said → fix it → compile again.

• All five bugs broken, read, and fixed — program compiles cleanly

Which of the five bugs would have been hardest to find if you had made it by accident? Why that one?

Professional programmers spend most of their working time debugging. Does that surprise you? What does it tell you about what a bug actually means?

Next

You can now make the robot say things and wait. In Project 3 — Motors and Ports, it stops talking and starts moving.

KIPR · Botball Explorer — Discovery Projects · © KISS Institute for Practical Robotics 1997–2026