Dear MCU vendors:

In my firm, I decide whether or not we use your kit. And sure, right now, we're an STM32 shop, but we're not married to that family. (We're not even married to the ARM architecture family!)

The last week and a bit I've been evaluating a Cortex-M0+ chip for a project. It's not going well. I'm sure the chip is just fine ... but I can't tell. In the end we're probably not going to go with it, even though it's cheaper than its alternatives.

Here's how to avoid this.

(1/n)

# Documentation

It needs to be available, even if it's beta quality. A data brief doesn't cut it. Your sample applications (for which q.v below!) don't cut it. I need documentation and I don't like having to fight for it. Supply it with your eval board, don't make me hassle you for it!

I get it: you're still ramping up this new chip and everything's in flux and in beta and the documentation is probably shit. But shit documentation is better than *no* documentation (if only barely)!

(2/n)

# Examples (I)

You need them. But don't give me example apps for Cortex-M core components. There's approximately 65 bajillion lines of code out there for that already.

What I need are example apps for each of your peripherals, and if there's inter-peripheral operations (timer triggering, say, or DMA) I need those as well.

And the examples have to work. Build them. Put them in your eval board. TEST THE GOD-DAMNED THINGS! Non-working examples are worse than no examples.

(3/n)

# Examples (II)

Your examples need to be documented. At least there should be a comment block before your mainline that explains what to expect. Better would be a README file that explains the application and gives a quick summary of what each file is for.

The example should also be well-commented (and by this I don't mean having random lines of code commented out!). If you set a register to 3, the comment should say what it means. Don't make me look it up!

(3/n)