3 ms·

What the hell is a 32 bit processor doing on a simple button/light daughterboard?

realo 13y ago
"Steam Operations" did not have a chance to have a good Father-Son conversation with "Steam Engineering" yet. Don't worry... it will come.
bri3d 13y ago
Cortex-M0 is often cheaper in volume than the 8-bit stalwarts, so why not?
hahainternet 13y ago
It's not exactly 32 bit and comes with an onboard USB controller so it was probably a pretty economical option.
jrockway 13y ago
They're dirt fucking cheap, is why. Last I looked, $0.80 a piece. Why screw around with an 8-bit AVR when it's more expensive and you're plugged into the wall and don't care about power? (Oh, and I'll add a tradeoff: the chips are cheap, but they are not as easy to get up and running as an AVR. Programmers and a bunch of Windows software seems to be required; I've given up every time I've tried to use one :)
- PeterisP 13y ago
  Replace a bunch of $0.80 parts with $0.30 parts in any consumer device, and the difference on your profit margin tends to be quite noticeable.
  - jrockway 13y ago
    They made like 300 of these, so that would have saved them $150.
    - PeterisP 13y ago
      Sure, but it's meant to prototype a machine that will be produced in millions - it adds up in volume, and it's not really a drop-in replacement, you have to engineer the whole subsystem with the cheaper parts in mind.
- bri3d 13y ago
  I'm a bit late here but just as a heads up ARM have an officially developed Cortex-M* GCC target which hosts just fine on Linux: https://launchpad.net/gcc-arm-embedded https://launchpad.net/gcc-arm-embedded With OpenOCD and STLink the STM32 family of Cortex processors are easy to use with Linux (arguably easier than in Windows, actually, because the toolchain isn't as shitty). I do agree that using them from Windows in the often-documented "beginner's path" way really sucks.
mbell 13y ago
It's a $1.50 MCU at low volume which probably has off the shelf USB drivers. Why would you build-cost-optimize a prototype for a product you never plan to mass produce? Choosing the path with lowest engineering cost is almost always the correct solution in such a situation.

realo 13y ago

"Steam Operations" did not have a chance to have a good Father-Son conversation with "Steam Engineering" yet. Don't worry... it will come.

bri3d 13y ago

Cortex-M0 is often cheaper in volume than the 8-bit stalwarts, so why not?

hahainternet 13y ago

It's not exactly 32 bit and comes with an onboard USB controller so it was probably a pretty economical option.

jrockway 13y ago

They're dirt fucking cheap, is why. Last I looked, $0.80 a piece. Why screw around with an 8-bit AVR when it's more expensive and you're plugged into the wall and don't care about power? (Oh, and I'll add a tradeoff: the chips are cheap, but they are not as easy to get up and running as an AVR. Programmers and a bunch of Windows software seems to be required; I've given up every time I've tried to use one :)

PeterisP 13y ago
Replace a bunch of $0.80 parts with $0.30 parts in any consumer device, and the difference on your profit margin tends to be quite noticeable.
- jrockway 13y ago
  They made like 300 of these, so that would have saved them $150.
  - PeterisP 13y ago
    Sure, but it's meant to prototype a machine that will be produced in millions - it adds up in volume, and it's not really a drop-in replacement, you have to engineer the whole subsystem with the cheaper parts in mind.
bri3d 13y ago
I'm a bit late here but just as a heads up ARM have an officially developed Cortex-M* GCC target which hosts just fine on Linux: https://launchpad.net/gcc-arm-embedded https://launchpad.net/gcc-arm-embedded With OpenOCD and STLink the STM32 family of Cortex processors are easy to use with Linux (arguably easier than in Windows, actually, because the toolchain isn't as shitty). I do agree that using them from Windows in the often-documented "beginner's path" way really sucks.

mbell 13y ago

It's a $1.50 MCU at low volume which probably has off the shelf USB drivers. Why would you build-cost-optimize a prototype for a product you never plan to mass produce? Choosing the path with lowest engineering cost is almost always the correct solution in such a situation.