Choosing a touch screen platform for in-home display product

Hi Theo,

On 6/6/2014 8:53 AM, Theo Markettos wrote:
> pozzugno@gmail.com wrote:
>> Il giorno venerdì 6 giugno 2014 03:40:11 UTC+2, Theo Markettos ha scritto:
>>> The other pain will be
>>> maintaining continuity of supply because the models will change every few
>>> months.
>>
>> I know, I know.
>
> I should add, I think this is going to be your biggest problem.  Any work
> you do could be eliminated by the manufacturer changing things overnight.
> Unless you're prepared to use the device completely stock (which is unlikely
> given what probably comes on it) you may have to do customisation at short
> notice.

The only "contract" that the manufacturer provides the user (assuming
you don't qualify to be treated as a SPECIAL USER or an OEM) is at
the API level.

There actually can be merit to treating the device as a generic
platform and not "customized" for your needs.

E.g., the visual displays that I use in my automation system tend
to be "closed" devices.  So, the only practical recourse I had was
to "write an app for that"  (:>) just assume the device is now
dedicated to that "app" and design the app to provide the services
that your system needs.

Of course, you now no longer have the customer by the short hairs...
you can't charge him $200 for a $50 COTS tablet just because it's
been "customized".  So, add your value *elsewhere* and *give*
the display business away (i.e., make a modest markup on the
devices -- still probably less than the user buying retail -- for
the "service" of having preinstalled the "app").

If volumes (eventually) merit, you can elide the "COTS" portion of
the device for a customized version -- e.g., with your "app"
preinstalled in "ROM" (and other options disabled).  This will
probably be a lot more "future safe" (given that the vendor will
still? be supporting the API) option.

> I'd suggest this approach might be feasible if:
> Your volumes are small enough that you can do a 'lifetime buy' from the
> beginning, so you know all your stock is good, or

That buy also has to handle returns/repairs -- including on those
devices that you haven't yet "sold"!  Heaven forbid your product
"takes off" and you *can't* find a continuing supply of "old stock"!

[I know a business that based it's product on an Apple II -- long
after that device's hayday.  They had to resort to purchasing
machines from anyplace tehy could *find* them (as Apple no longer
*made* them!)]

> Your volumes are high enough to make a deal with the manufacturer direct
>
> The place in the middle isn't a good spot to be.
>
> Theo

Don Y <this@is.not.me.com> wrote:
> The only "contract" that the manufacturer provides the user (assuming
> you don't qualify to be treated as a SPECIAL USER or an OEM) is at
> the API level.
> 
> There actually can be merit to treating the device as a generic
> platform and not "customized" for your needs.

Yes.  If you can cope with 'stock' Android completely out of the box, you
might be OK.  But even something as simple as rooting it (to remove the
vendor's bundled apps, for example) might be subject to change if the
manufacturer changes things.  Or a new Android version could come out that
breaks your app (4.4 does unexpected things to SD cards, for instance).

But I'd suggest the genre of 'Android tablet' is so broad that you're
probably going to want to do some customisation, and that's the time when
you start depending on implementation details beyond 'plays Angry Birds'.

> E.g., the visual displays that I use in my automation system tend
> to be "closed" devices.  So, the only practical recourse I had was
> to "write an app for that"  (:>) just assume the device is now
> dedicated to that "app" and design the app to provide the services
> that your system needs.

This is fine, unless you want to lock down the device as the OP required.
That counts as 'customisation', and is where the trouble starts.

Theo

pozz <pozzugno@gmail.com> writes:

> I'll design a typical "in-home display" product with a small (4-6")
> touch screen display. The application will be generic, mostly oriented
> to security and/or home/building automation.
>
> The human-machine interface is important (beautiful graphics, fast
> responses, sensible touch, ...) and the *low cost* too!!!
>
> Does someone give me suggestions on some good platforms to start with?
>
> Of course I have two choices.
>
> Design the hardware (choose the microcontroller, the display, design a
> board, connectors...) and write the firmware from the scratch. Maybe I
> can use some good graphics libraries on the market (QT?) or from the
> manufaturer (Microchip Graphics Library, ...).
> Anyway I have some doubts about the result.

I would roll my own, but that's me. Obviously it's going to require a
lot more NRE.

What doubts?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com