* Cost. Maker-grade stuff costs 10-100x what a production embedded does. You're leaving a lot of money on the table.
* There's no guarantee of long-term support; RPi and Arduino both regularly change form factors. They make no guarantees that they will continue manufacturing what you're already committed to.
* Maker vs. production system architectures are totally different. Linux is rare among production systems. It just needs too much hardware (see Cost). So you have to rebuild the thing anyway when cost-reduction time comes.
'Production' means different things to different people, of course. I'm thinking of a world where you want to ship 10k+ units of a device. If you're only shipping 100 units, your concerns are very different.
The Arduino itself might cost 10-100x of something that could go into production, but couldn't you prototype with an Arduino and use cheap Atmel chips with the bootloader installed in production?
You absolutely could. But many, many startups suck at this step, and get stuck at the "systems integration" phase, able to connect purchased components like Arduinos to other purchased components with wires, but unable to transition to purchasing the raw parts and connecting them using printed circuit boards.
The difference is that in software, you can go very far into production with an AWS account and a few blog posts on devops. There is no need to hire a specialist in wiring server racks or negotiating traffic peering deals up front.
All the IoT boards have made prototyping hardware accessible to "software people", but unlike AWS there is no smooth scaling curve from 10 to 10k to 10M customers.
I'm also pretty confused here. Are the "startups" in the ancestor threads more like college hackathon projects? Like I put a raspberry pi in my toaster and know nothing else about embedded systems, now how can I sell a million of these?
Yes, that tends to be how startups come off - even the "sophisticated" ones. They tend to have minimal knowledge of the steps necessary to turn their prototype into a mass produced thing: DFM/DFF, supply chain management, identifying/negotiating with component/bare board suppliers, etc. Generally speaking, they need lots of hand holding through the entire process, and that makes it take way longer for everyone.
The nature of stateside electronics manufacturing doesn't help startups much in that regard, in that shops are kinda either set up for NPI and rapid prototyping or not. Sierra Circuits is good for that, but idk how well they'd fit with a startup budget. Beyond that, the low-complexity nature of most IoT products means they're more cost effectively manufactured in China, as most US shops focus on low to mid volume runs of high complexity boards, as opposed to high volume low complexity runs. Figuring out how to manufacture in China can be a big obstacle for any company, especially smaller ones.
Yes, but I'd like to add to other's points that unless you get your hardware architecture juuuuust right, you might start getting bugs in your code as you make the transfer. Furthermore, there are difficulties if you don't judge properly your run of production, need to have another go, and find out that maybe some dumb little module is no longer available in exactly that forma, causing you to use a slightly different one, causing another fracture in your code base. Now you're supporting two, and developing on a third, etc. I've never experienced this, but it's come up at iot conferences as I talked with folks.
But if you start off on something like an Arduino, you'd "just" convert it to a custom board running an AVR (or ARM with the newer ones?) on the way to production, or are those that bad to use in serious designs?
It's more a problem if you start on something big like Artik/RPi/Edison and try to downsize later. You'll find yourself locked in to that vendor's software stack.
Or if you try to ship 10k devices with whole RPis inside.
A lot of maker stuff is either bog-standard parts that you can buy in quantity off AliExpress, or open source with all designs and layouts freely available. Software'sopen source also.
Using a whole Rpi 3 as part of a solution? Yes I agree that there's a risk in supply; but if making 10k devices, you are talking about a raw cost of at least 300k USD, right? So spending 30k for a few months of engineering time to make it production ready (idea: make sure that the OrangePi knockoffs also work, so you have 2 sources of supply) is feasible in the case you mention.
Linux SoC based designs are fairly complex in terms of engineering cost - if you're only building 10k of something, you might in fact be better off using something like the RPi Zero or Compute Module (or another system-on-module, like Variscite or etc.) rather than trying to integrate the Broadcom part yourself. Not to mention that RPi is getting much better prices on things like the SoC and the HDI PCB than a startup producing 10k of something is likely to get, so it may even be a wash on unit cost. And the supply risk is likely manageable; 10k is a high enough volume that it would be foolish to rely on distributor stock/spot prices for components, so you're already worrying about leadtimes; I don't see why a wholesale contract with RPi would be that much riskier. (Yes, it's true that the leadtime would increase a bit since RPi needs to purchase components themselves and convert them into modules.)
Now if your product is Arduino based (or another microcontroller platform) the barriers to doing a fully custom design are a lot lower, the markups on the Arduino board are a lot higher, and so the cutoff volume for where it makes sense to do a custom design is going to be much lower than 10k.
Big one for me is shape. A lot of the stuff that I work on has to fit in pressure cases that are already pretty cramped. That means that there is no room for a bunch of breakout boards and whatnot.
These are mostly true, but it's pretty trivial to design your own Atmel AVR board.
> Linux is rare among production systems.
AFAIK, Arduino has no OS, let alone Linux. It's a giant wrapper around "setup(); while (true) loop();" Which is itself a gigantic problem for power savings. Fortunately there exist alternative platforms, and some even run on the same Arduino platform: https://github.com/jmattsson/tinyos-arduino
Personally, I like FreeRTOS. I got an ESP8266 and starting writing programs right away. There's no VMM, no true multitasking, but it's better than raw arduino. I managed to port Zork in an afternoon.
You can use the standard AVR sleep modes and interrupts on Arduino. Put the uC to sleep and have it wait for a pin to change or a timer to elapse before waking instead of idling at full power. See the Arduino docs (or the Atmel datasheets, which are easy to read):
There are libraries that do this automatically on Arduino too, allowing you to schedule [cooperative] multitasking and sleep the uC between tasks. E.g.
is really good, I've used it before. You basically queue up a list of task callbacks and a schedule in your `setup()` and then do a call to `tasks.execute()` in `loop()`, which pops off the next task that is due in a queue or sleeps otherwise. It's simple, but much more straightforward than manually using `if millis() - last > delta1... else sleep()` and not as rigid as using the timer ISRs (which really serve a different purpose).
On more complex platforms you can also use an RTOS, which is kind of like a more beefed up version of this model. Actually you can do this on AVR too, but I haven't ever seen anybody actually use FreeRTOS/ChibiOS/whatever on AVR.
Bear in mind that while what he said is correct, there are other concerns on an assembled board, as opposed to the bare chip. Arduino has a voltage regulator that is always consuming current. The Power LED is always consuming current. You should be sure to set pin 13 (the indicator LED) as an output and turn it off, since even as an input, there will be leakage current through the LED. The other active components on the board have their own quiescent current levels, etc.
You can get an AVR device to run on a coin cell for months or years (I have a design that does just that). You'd have to modify an Arduino significantly to do the same.
Very true, though there are some better Arduino variants. The Pro mini is the canonical "low power" Arduino as it uses a very efficient LDO regulator. I also use bare ATTiny's for a lot of uses, they don't require any passives and can run directly from a LiPo as long as you use a protected cell or connect a feedback line to the ADC.
An arduino is a microcontroller with a few conveniences added. There are plenty of microcontrollers inside of devices that last for years on tiny coin cell batteries. You can program it to go into an ultra low power sleep mode and wake the instant you press a button or on a predefined schedule, do whatever business you want it to do for a few moments, then go back into ultra low power sleep. Some microcontrollers are more optimized for this use case than others, but plenty of ordinary ones are and they've gotten incredibly good at it.
Some Arduino IDE-compatible boards are pretty small, like the Teensy[1] line - though if you needed to cram other boards in with one it'd still be cozy I imagine.
In the case of teensy you've pretty much got just a chip with breakout (and maybe an FTDI chip) - it's pretty much a reference design. At that point you'd just board-down that entire layout, there's little benefit to buying a module with a mini USB connector that might or might not be in a usable position and high-pitch headers that take up a lot of space.
I'm a little confused here too; obviously an arduino-inna-box is not a proper solution and for production run you should design your own board with an Atmega328 on it, so what's unsuitable about the Atmega?
Provisioning more than one ethernet PHY is an issue. There aren't a lot of choices for two or more PHYs at a reasonable (singe $ digits in medium quantities) cost
