Skip to main content
Blinky is the canonical first program for any hardware platform — it blinks the onboard LED at 1 Hz and confirms that your toolchain, USB connection, and firmware image are all correctly set up. If Blinky runs, your environment is ready for everything else in the ANX SDK.

​
What You’ll Learn

Working through this example gives you hands-on experience with three fundamental building blocks of every ANX application:
  • ANX SDK application entry point — how app_main() replaces the standard main() function in ANX OS
  • GPIO output control — how to configure a pin direction and drive it high or low
  • Task scheduling with delays — how anx_delay_ms() yields CPU time to other tasks instead of busy-waiting

​
Prerequisites

Make sure you have the following before you begin:
  • ANX CLI installed and available on your PATH (anx --version should print a version string)
  • ANX OS firmware flashed to your dev module (any version 1.0.0 or later)
  • ANX dev module connected to your computer via USB

​
Application Code

The complete Blinky application is fewer than 20 lines of C. Every line is annotated so you can follow exactly what happens from power-on to the first LED toggle.
blinky.c

​
Code Walkthrough

Each function in the example maps to a distinct concept in the ANX SDK. Understanding these four building blocks will carry over into every other example and project you build.
ANX OS calls app_main() after the kernel and all built-in drivers have finished initializing. You never write a main() function in an ANX application — the OS owns that symbol and uses it to set up the scheduler, memory allocator, and peripheral clocks before handing control to your code.
Before you can drive a GPIO pin, you must declare its direction. anx_gpio_set_direction(pin, mode) accepts either ANX_GPIO_OUTPUT or ANX_GPIO_INPUT. Calling this function on a pin that is already configured as an output is safe and idempotent — the hardware register is simply written with the same value.
anx_gpio_write(pin, level) drives the specified pin to a logic high (1) or logic low (0). On the ANX dev module, the onboard LED is active-high, so writing 1 turns it on and writing 0 turns it off. If you connect an external LED with a current-limiting resistor, the same logic applies.
Unlike a busy-wait loop, anx_delay_ms(ms) suspends the current task and returns CPU time to the ANX OS scheduler for the specified number of milliseconds. Other tasks — logging, USB communication, a background watchdog — continue to run during the delay. This makes your application cooperative and efficient even in a tight blink loop.

​
Build and Flash

With your module connected via USB, run the following command from the root of the examples repository:
The CLI compiles the application, packages the firmware image, and flashes it over USB in a single step. After the module resets, you should see the onboard LED begin toggling and the following line appear in the serial output:
Open the serial monitor at any time to view log output:

​
Modifying the Example

Once Blinky is running, try a few quick changes to deepen your understanding of the GPIO and delay APIs. Change the blink speed by adjusting the delay values. Cutting both delays to 100 produces a fast strobe effect; increasing them to 2000 gives a slow, lazy pulse:
Control an external LED by changing LED_PIN to any available GPIO number and wiring an LED with a 330 Ω current-limiting resistor between that pin and GND:
Re-flash after each change with anx run examples/blinky to see your results immediately.
Ready to go further? The Sensor Data example builds on the same application structure to read an analog potentiometer over ADC and a temperature/humidity sensor over I2C — no new toolchain steps required.