Choosing a touch screen platform for in-home display product

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.

Find and buy a ready-to-use small Android-based tablet from a China manufacturer. I think I can found a similar thing at 25-20$ for 1k-5k pieces. The price would be very good and I can decide to use the original cabinet or adapt a new one.

My doubts are for the OS. Android is oriented for smartphone (calls management) that I don't need and let the user to install apps and make many things. I worry the user will be able to install its applications, customize settings and so on.

How is Android "lockable" from the developer so the user can use *only* his application?

Reply to
pozz
Loading thread data ...

Do your own build. Deselect the drivers for wifi, USB, whatever, and the phone dialler, contacts, etc etc. Then you have a version of Android with no support for hardware you don't want.

If it's a China special, extracting the Android sources could be a bit tricky (say 'GPL violation' and they just laugh). However you could probably pick a tablet with GPL compliance. The other pain will be maintaining continuity of supply because the models will change every few months. (And don't forget you'll have to distribute your own GPL sources).

If you want to prevent the user 'hacking' their system (which could be finding a way to reflash new firmware, or even poking about with JTAG ports) then you need a proper security model. But maybe simply locking it down by not installing stuff is enough. (Arguably, the hackability of abandoned hardware can save it from landfill so has a social function. Though is a bit of a headache as far as support goes).

Theo

Reply to
Theo Markettos

If you can't do Wifi & Phone, what can you do with it? OP wants in-home display of something. I don't think it's just for simulations,

Reply to
edward.ming.lee

Look at some digital picture frames. They have less stuff in them than android tablets, and are cheaper.

Reply to
Paul Rubin

critto:

display of something. I don't think it's just for simulations,

It will be connected to a proprietary wired RS485 bus, so I definitevely *d on't need* WiFi and Phone.

Reply to
pozzugno
:
h

This seems nice, but is there a ready-to-use platform that shows this process? A demo that let me use and experiment with Android, starting from build my own OS.

How simple is it?

Do you know something of it?

I know, I know.

Should all the Android-based applications GPL released?

ts)

by

Yes, it will be enough.

Reply to
pozzugno

And what about changing the original firmware? Are there open-source digital picture frames?

Reply to
pozzugno

Have a look at CyanogenMod. It builds the full OS from scratch, and works on quite a number of devices.

Fairly straightforward - not Cyanogen, but I've built Android Open Source Project (AOSP) for the Nexus 7. You download a huge tarball of tools, follow the instructions, type make, it fetches everything it needs from git and builds the whole OS (insert lots of CPU time here). It then starts the image on an emulator to test it out before deploying on real hardware.

Nexus hardware is fully supported by Google which makes it less painful, but if you get a Cyanogen-supported device it may be equivalently straightforward. However they're not always the bargain-basement hardware. (There's lots of third-party ports of CM to other hardware, but that might not be enough support for you)

Not tablets, but Chinese manufacturers like Oppo are better at playing nicely with the GPL rules.

If you've modified the kernel sources, yes. If you haven't you still need to provide sources on request. You can do that by pointing at someone else's server, but you still need a copy of the sources in case that server goes away.

Theo

Reply to
Theo Markettos

Digital picture frames are not likely to have touch or non-touch inputs. E ven for tablets (or subset like DPF), they might not be able to boot from e xternal devices. First thing to think about is how to load your stuffs in it, perhaps JTAG.

Reply to
edward.ming.lee

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.

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 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

Reply to
Theo Markettos

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.

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!)]

Reply to
Don Y

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'.

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

Reply to
Theo Markettos

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 
 Click to see the full signature
Reply to
Randy Yates

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.