Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Qt Lite project – Qt for any platform, any thing, any size

blog.qt.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#31

Post by joezydeco »

n00b101 wrote: post #4

The new configuration system in Qt, allows your define the content you need from each module in much more detail for your project and easily allows for feature based tailoring of the Qt modules. We are starting with enabling this fully for Qt Core, Qt Network, Qt GUI, Qt QML and Qt Quick. You can now fine tune which features from these modules you want to include in your project. There is no longer any need to includ…

"And these devices have graphics displays but they lack GPUs? What device could that be?"

I've deployed Qt HMI projects on Cortex-M3/M4 devices like the NXP LPC1788/4088, and GPU-less A9 cores like the Renesas RZ/A1L. I've even done one on a wacky Chinese MIPS core.

They all use a raster framebuffer + LCD controller. Works just fine for a hell of a lot of things. I have yet to do a HMI project in Qt Quick, nor do I plan to in the future.

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#32

Post by joezydeco »

protomyth wrote: post #2

"At least for now, the configuration tooling will be a part of the Qt for Device Creation product, and not open source." I do wonder how a lot of companies's dual license model is going to interact with the IoT / embedded world.

I'm thinking about avoiding it for my IoT device node work.

I'm prototyping a node project right now for a large customer (>50K deployments) and while Qt helped me get code running quickly there won't be a way to comply with the dynamic linking model on my final hardware. Can't afford the Qt license in my BOM (probably would be 25% of my bill) so out it goes.

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#33

Post by anmorgan »

erichocean wrote: post #17
roymurdock wrote: post #13

Earlier quoted context omitted.

What are possible use cases for a device like this? (I didn't downvote you and I don't know why anyone would)

Certainly, why would you want that vs. a $5 Rapsberry Pi Zero which does have an actual GPU, media acceleration, etc., more RAM, a more powerful CPU, etc.

The main thing that is usually overlooked is that Raspberry Pi is a charity and they do not make commercial products with the intent to make money from it.

Well okay, why would you make the choice to go with something like the STM32F4 ARM Cortext-M processor vs something like the Raspberry PI with an ARM Cortex-A series processor? Well I'm glad you asked.

First you need to ask, what does your device need? Some things to consider: - Power consumption - Real time sensors or I/O - Safety critical - Processing / Computing power - Image / Video processing - 10" display - etc

All of these are at the beginning of making a choice of which processor series you want to use.

But, wait if an Cortex-A Series can be sold for $5 why don't I just got with an Cortex-A series, because, well they aren't. See my first sentence and now my following.

If you compare the higher-end M4/M7 processors from ST (STM32F4xx / STM32F7xx with Chrom-ART / DMA2D Support) vs something like the NXP/Freescale A9 single core (i.MX6Solo) at quantity 1,000, you're looking at between $7-$10 for the Cortex-M4 and $13-$15 for a Cortext-A9.

( http://www.digikey.com/product-search/en/integrated-circuits... )

( http://www.nxp.com/products/microcontrollers-and-processors/... )

Okay, so they aren't that much different in price (depending on who you are and how much the rest of your system costs). So, you need to then compare it even further. Typically on a Cortex-M Series you are looking at an RTOS, whereas on a Cortex-A series you are looking at a real OS (Linux, Android, Windows, etc). Why does this matter? This has to do with hardware support and the core difference between an RTOS and an OS. If your board processor, peripherals, etc are not well supported or you are doing a custom pcb design, you are going to be writing your own drivers which equates to NRE (Non-recurring Engineering), which can be expensive. This cost could be consumed by the company as a business expense or be captured back into the cost of the device. Then you have tool chains, support, and familiarity, and so on.

So, if the above did it's job, that might have helped into understanding why you may or may not go with a Cortex-M or Cortex-A series. And yes you may be right on the edge of going with one or the other.

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#34

Post by akiselev »

erichocean wrote: post #26
yuretz wrote: post #23

Earlier quoted context omitted.

E.g. because of much longer guaranteed support/supply life, which is a must if you are trying to run a serious production. There might be some other reasons too.

> because of much longer guaranteed support/supply life The underlying components in the Pi Zero also have a long "guaranteed" support/supply life. You don't have to rely on the Pi foundation for your components, or the board itself (as I pointed out in another reply in this thread). My primary point is that the cost of a GPU these days is very close to zero, so I see little benefit in picking a platform that doesn't…

Uhhh have you ever dealt with Broadcom? The BCM2835 chip powering the RPi zero isn't something you can buy without negotiating with Broadcom directly and a minimum order size in the tens or hundreds of thousands. That is a far cry from STM parts you can order off of Digikey or Mouser. Even some of my bigger clients won't base products on Broadcom chips for that reason alone.

And no, even in the best of cases where you have great software support from the vendor (ha! as if) and a great reference design, adding a GPU to a design is expensive because of both software and hardware R&D. unless you have an integrated CPU/GPU combo but then you're back to the problem of dealing with Qualcomm/Broadcom.

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#36

Post by kbart »

n00b101 wrote: post #4

The new configuration system in Qt, allows your define the content you need from each module in much more detail for your project and easily allows for feature based tailoring of the Qt modules. We are starting with enabling this fully for Qt Core, Qt Network, Qt GUI, Qt QML and Qt Quick. You can now fine tune which features from these modules you want to include in your project. There is no longer any need to includ…

"GPUs and OpenGL must be more energy efficient at this task than software rendering, and I would imagine that important embedded devices with graphics displays must all have GPUs or will in the future?"

Adding to what was said in other comments, another problem is graphic drivers that mostly come as binary blobs and no source code available. Many projects, especially missions critical ones, avoid having uninspected binary blobs in their systems.

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#37

Post by protomyth »

joezydeco wrote: post #32
protomyth wrote: post #2

"At least for now, the configuration tooling will be a part of the Qt for Device Creation product, and not open source." I do wonder how a lot of companies's dual license model is going to interact with the IoT / embedded world.

I'm thinking about avoiding it for my IoT device node work. I'm prototyping a node project right now for a large customer (>50K deployments) and while Qt helped me get code running quickly there won't be a way to comply with the dynamic linking model on my final hardware. Can't afford the Qt license in my BOM (probably would be 25% of my bill) so out it goes.

Any idea what you are going to replace it with?

Re: Introducing the Qt Lite project – Qt for any platform, any thing, any size

#38

Post by joezydeco »

protomyth wrote: post #37
joezydeco wrote: post #32

Earlier quoted context omitted.

I'm thinking about avoiding it for my IoT device node work. I'm prototyping a node project right now for a large customer (>50K deployments) and while Qt helped me get code running quickly there won't be a way to comply with the dynamic linking model on my final hardware. Can't afford the Qt license in my BOM (probably would be 25% of my bill) so out it goes.

Any idea what you are going to replace it with?

A lot of my smaller devices uses FreeRTOS, it's got a nice simple scheduler and it's easy to work with.

I've also used the uEZ application later from FDI on top of FreeRTOS when I need a more robust application.

Although I'm looking at the Kinetis M3 line for upcoming work, so I might use mbed.

Post reply on HN