Studio vs the C SDK
You can build on tiles two ways, and they run on the exact same hardware. Studio is the fast, visual path; the C SDK is the full-control path. Most people start in Studio.
Studio
Compose & simulate in the browser.
- • Visual composition + a high-level behavior language
- • Live firmware simulator — test without hardware
- • Builds a real binary; flash from the browser
- • Nothing to install
C SDK
Write firmware directly in C.
- • Full control via the
core_*APIs - • Your editor, your toolchain, your build
- • Every peripheral, every register, no ceiling
- • Standard ARM embedded workflow
Which should I use?
Reach for Studio when you want to move fast, you’re prototyping or exploring, you don’t have hardware in hand yet, or you’d rather not manage a toolchain. It gets you from idea to a running simulation in minutes.
Reach for the C SDK when you need full control — tight timing, a custom peripheral configuration, integration with existing C code, or a production firmware you own end to end.
How they relate
They’re not separate worlds. Both sit on the same tiles and the same open-source drivers; Studio compiles your design down to firmware built on the same SDK you’d write by hand. So a project that starts in Studio isn’t a dead end — you can graduate to the C SDK when you outgrow the visual layer, without changing hardware.
- Same hardware — tiles, Cores, and buses don’t change.
- Same drivers — the platform-agnostic tile drivers underpin both.
- One direction of travel — Studio → C SDK when you need more, never a rewrite from scratch.