[Development] Qt and IoT infographic

Thiago Macieira thiago.macieira at intel.com
Tue Aug 29 18:00:36 CEST 2017


On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
> And yet it has a web server for serving up either a human-readable page or
> JSON on demand, and it also pushes data to a central server periodically.

Is that a static JSON? Because if you need to compose the data on the fly, you 
may also want to replace JSON with something simpler. See 
	https://github.com/01org/tinycbor/

You'll find that the maintainer is familiar :-)

As for the part about "pushes data to a central server", I hope it's a server 
on the local network, not on the Cloud.

> After
> reading about CoAP I think it would be a much better fit than HTTP for such
> a device, so I hope I find the time to try.  But then again, browsers don’t
> have CoAP yet, so I wonder if there could be a web client that uses JS to
> talk to it.  Having to build a dedicated Qt client for it would be a step
> backwards in a way, but also nice for a desktop widget or some such.

Firefox has a CoAP addon.
https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

As for Chrome, I'll cat with Alexis and see what he thinks about the chances 
of adding it by default to the browser.
 
> Qt for IoT is maybe primarily for devices that have graphically-rich
> screens.  But they can be clients reading data from truly-embedded sensors,
> and they might also have data of their own to serve to other clients
> (consolidated results, or just extra sensors that happen to be attached).

Good point on the data of their own.

I really do think we need to reevaluate our position that Qt is for clients 
only. I'm not against the HTTP server stack. I'm just saying it's a much more 
complex beast. And unlike the server that serves a single page, any Qt 
solution that makes to API would need to be a lot more capable.

Otherwise, just lift the MiniHttpServer from the many unit tests.

> There are some PLCs powerful enough to run Linux, though, like these:
> https://www.bachmann.info/en/products/controller-system/  Some industrial
> applications can afford to use them, and so can the shipping industry, as I
> learned a couple of years ago on a certain consulting gig… and so they can
> afford to use Qt too, just for network comms, even though there is no GUI.

Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a 
kernel at 1 MB, but then there's nothing left for your application. Shrinking 
the kernel further is possible, but it depends on whether the upstream would 
accept such changes -- for example, disabling TCP and leaving only UDP 
enabled. The kernel network maintainers currently have the position that they 
don't want this and you should just switch to a microcontroller RTOS at that 
point.

For Qt, we have to make sure it runs comfortably at 128 MB and we should 
strive to make it possible for 32 MB of RAM.

But the question is whether this is worth the effort. Are there devices that 
have memory in this range? One anecdote I've heard is that you can't buy DRAM 
at less than 512 MB -- since there's just not enough volume for them, their 
prices went up, causing people to stop buying them, further causing the prices 
to go up...

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




More information about the Development mailing list