[Development] Qt and IoT infographic

[Thiago Macieira]

On Wednesday, 30 August 2017 07:32:42 PDT Jason H wrote:
> > For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And
> > a lot of Raspberry Pis too.
> > 
> > For production runs, that number goes very quickly to zero.
> 
> I guess this comes down to whom you are marketing. I can understand Intel
> and TrollTech (whatever you call current incarnation) wanting those high
> volume customers. But I think the innovation space is not those high volume
> customers. It's kickstarters, hobbyists, etc. 

Note I did not talk about innovation. I talked about the actual products.

Regardless of who innovates and what platforms they innovate on, they don't 
use Arduinos and Raspbery Pis for the products once they move on from 
prototypes. Specifically on the case of Arduino, since the Arduino API is not 
available on the next device, there's almost always a full rewrite of the 
software when this happens.

For bigger devices, we should hope that, like Eddy said, that the application 
written with Qt can just be run on the production-quality hardware almost 
unchanged.

> The knowledge required to go
> from a Qt level knowledge to a dedicated MCU is as big a gulf - as big a
> difference as in the hardware specs. It's far easier to pick up Qt and
> spend a few more $ on your board than to learn about interrupts and all
> that stuff. The market play here is to use the OSS license, get them to
> develop their stack on Qt and have them pay for a license later. You'll get
> far more things for your showcase.

That's a good point. This is a contrast a colleague of mine explained as a 
simple matter of what costs more: a day or a byte. That is to say, when time 
to market is more important than the device's BOM cost being a few dollars 
more, you'll do exactly that and you'll use bigger but easier frameworks that 
allow for rapid prototyping. Qt's competitor here is, as others have noted, 
Node.js.

When the dollars matter more and you do need to constrain your BOM to a 
certain price range, then you'll spend as much time as needed to shrink your 
software and optimise it to fit. I don't think Qt fits this market right now -- 
except as the alternative to something much bigger, like replacing an HTML5 
engine.

> I don't know much about 3D but thanks to QtQuick and Qt3D, I can use 3D in
> my software. I'd like a similar experience for IoT people. I don't know
> much about video over USB but I don't need to, QML's Camera works with it.

Now let's do video over IP so we can get that video from a networked camera, 
and add support for OpenCV so we can actually process that image.

> I was recently working on an embedded project where we had a couple options.
> One was essentially a Pi Zero, with reduced memory and storage, providing a
> REST interface to the data. Quantities in 10k increments, about 10k per
> year. Because that was judged to be too much work to get running, we ended
> up not using Qt on the device, but Qt to get the video frames on a
> connected computer.

Exactly the type of scenario I mentioned above and I expect to happen more and 
more often.

> These situations may be anecdotal, but I think they'll be more common and
> I'd like Qt to be ideally positioned for the next million innovators.

No, you're probably onto something.

Qt will not run on the MCUs and the final endpoint devices on your network 
(often a mesh network). But Qt will communicate with them and will do 
processing on the data received from them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center