- Home
- Software
Software
Software you can remix.
A Koala board is not finished when it ships. A firmware profile decides what it actually is - and swapping the profile turns the same hardware into a different useful instrument.
The idea
One piece of hardware, many useful behaviours
Most development boards are sold once and used for one thing. A profile is the opposite bet: the same board, deliberately given several genuinely different jobs, each one documented well enough to trust.
A profile is three things
A firmware build, the configuration that shapes it, and the documentation that explains both. Ship one without the others and it is not a profile.
Configuration before code
Most changes should be a setting, not a rebuild. When you do need the source, the seams are documented so you know where to cut.
Reversible by design
Every profile documents how to get back - re-flash, recover, or return the board to a known state. A board should be hard to lose permanently.
The kinds of jobs a profile can give a board
These describe the categories being planned, so you can see what “many behaviours” means in practice. They are not released firmware, and none of them can be downloaded yet.
Logging
PlannedRecord measurements over time, to storage or to a host, with timestamps you can trust.
Control
PlannedDrive outputs from inputs and rules, on a schedule or a threshold, without a computer attached.
Sensing
PlannedRead a sensor properly - calibration, filtering and units - and present the result in a usable form.
Test
PlannedTurn the board into a bench instrument: a signal source, a bus sniffer, a simple checker for other hardware.
Library
Firmware profiles
Nothing matches that combination
Clear a filter or two and try again.
No firmware published yet
There is nothing to download, and we are not going to invent a version number to make this page look busier. The first profiles arrive alongside the first boards.
Format
What every profile has to document
A profile is only finished when all of this exists. Fields with nothing verified behind them stay visibly empty.
- Profile name
- What it is called, consistently, everywhere.
- Compatible hardware
- The exact boards and revisions it runs on.
- Purpose
- The job it gives the board, in one sentence.
- Maturity
- Stable, beta, experimental or planned - stated plainly.
- Last updated
- The date of the current release, or “not yet published”.
- Setup instructions
- From an unopened box to a working board.
- Release notes
- What changed, what broke, what to do about it.
- Known limitations
- The things it does not do yet, written down before you find them.
- Flashing and recovery
- How to load it, and how to get back if that goes wrong.
- Source
- A link to the repository, once the GitHub organisation exists.
Flashing
Each profile will name the exact tools and the exact steps for the board it targets - not a generic instruction that assumes you already know. Where a step can damage something, it will say so at that step.
Recovery
Every profile will document the way back: how to re-enter the bootloader, how to reflash from a known state, and what a board looks like when it genuinely cannot be recovered.
Open development
A GitHub organisation is coming
It does not exist yet, so there is nothing to link to and nothing to star. When it is created, this is what will be in it.
Firmware source
The code behind each profile, and the configuration that shapes it.
Example applications
Small, complete, readable programs meant to be copied and changed.
Issue tracking
A public place to report a bug and see whether anyone has answered it.
Tagged releases
Downloads that correspond to a specific commit, with notes attached.
Contribution guidance
Enough detail that sending a pull request is worth the effort.
