The Critical Role of, "EARLY-ON DECISIONS" upon MCU-Based Design/Development.

Greetings,

As noted above - a poster earlier presented:

"I have a project where I want to use the Tiva MCU as the core and an android tablet will be connected to MCU via USB. The MCU will be the USB host and the tablet will be enumerated as 4 USB devices: speaker, microphone, display, and input. The tablet will be powered by the host. The idea is to take advantage of the tablet hardware so that the development can be focused on the function(not the UI part) only."

Several here read/responded - broad experience base seemed to raise the most critical points.

Fofllows my small team's attempt to "duplicate the flavor" of that earlier thread - while steering it (we believe) along a more valuable & productive course...

Friend/Responder Robert noted:

"If you want an HMI, you'd probably be better off actually using one depending on what your exact requirements are. You can get off the shelf HMIs with a wide range of characteristics using relatively simple protocols. You can use ethernet but CANOpen and RS-232/485 Modbus RTU are readily available.

Using a tablet may be trading purchase cost for development time (and might not buy you cost savings depending upon your needs). And if you need a rugged display it's probably not going to be a tablet."

And then 'this reporter (staff really)" added:

"Should not this poster be commended for his imaginative, resourceful & (potentially) disruptive, "Probe for an advantaged solution?" While "weaknesses" exist w/in poster's idea - it does include "powerful, built-in 'Features, Functions & Benefits' - unavailable elsewhere!" 

Usually - when evaluating such a, "Break from the (same old)" it proves wise to, "seriously weigh" the proposal's "pros & cons." The degree to which the poster has progressed in this "weighing" is unknown.

While supportive of the poster in general - my young staff "recoils" from poster's, "I have a project where I want to use the Tiva MCU as the core and an android tablet will be connected to MCU via USB." Should it be mentioned that even a, "50 (USD) tablet" includes an ARM MCU - many times more powerful than (any vendor's) ARM Cortex M4?

So - what to do? (beyond generate a, "Full & Proper" Pro/Con Analysis.) Might there exist some "inspired Hybrid method" - which maintains (and exploits) the tablet's enhanced core - yet accepts "direction" from a lesser MCU?

Is this path not superior - while aligning w/poster's stated goal? (but for the core-reversal horror...)

Leading to Robert's:

"First cb1 has a point about the idea of looking for alternatives is a good idea.

Now as to why I think you probably won't find it advantageous:

There are multiple kinds of HMIs from simple switch, dial and lights to full touch screen running a "proper" operating system. there are in addition SCADA interfaces that are more upper level computer systems with high level remote control and trend and data analysis. Now since we are talking a USB HID slave connection I think I can fairly eliminate these higher systems although there is a subset of these (the display of remote data and tend analysis) that a pad could do well provided you can supply sufficient security. This would not be using a USB interface though.

HMIs vary on multiple fashions. Resolution and size of the display (and whether the display is graphical), whether it has a touchscreen, what physical and logical communications they support. You can get an HMI that is text only, non-touchscreen, room temperature and only supports Modbus RS-485. You can also get an HMI that supports multiple CAN, Ethernet and serial ports running Linux (including Qt) with a graphical touchscreen, buttons and multiple camera inputs that is hardened to work in an outdoor vehicle environment. The price varies accordingly.

There is one characteristic of HMIs that is near universal (and for good reason). The HMI is almost always the 'master' on its communication port. The reason for this is to reduce the communication complexity on the controller. The controller is a real-time system, often with limited resources (which is why modbus RTU is still very popular). Other than communications the HMI does not suffer these restraint. They must, of necessity, have the resources to manage the display and input. This means that they must have relatively powerful processors and significant amounts of memory, particularly for the higher end versions. A pad acting as a USB slave reverses this and places an extra demand on the controller do not only to the task for which it is intended but also it now has to mange the HMI interface. Now this could be reversed but basically by imposing another proprietary protocol on top of the native USB HID protocol but you've just added to your development burden."

Without doubt - that's a simply terrific writing - reveals a "Broad & Well Developed Understanding" of the issue at hand.   (which rises far beyond the "MCU & only the MCU.")   

It should be clearly noted - Robert has not succumbed to the, "Self-Limiting/RESTRICTIVE" tendency - exhibited by this originating poster - yet also by (pardon) "too many" here.   Slamming the "investigative door so early" - is unlikely to enable/encourage optimum results!

Staff will delve deeper - we are among 3 firms out of 24 - who have continued to "Test & Work" from our "Great Lake" adjoining (Chicago) office location.    We contribute here (& elsewhere) as/if (necessary) "Profit Making - time/effort" allows...

Flattering start cb1.

I would start with a higher level system view and determine what the problem is that you are trying to solve and what else your solution has to work with. Marketing has a role to play in this. Not much sense building something just because except for play.

There a couple of critical inputs inputs needed from marketing

• The potential market size you can expect to serve
• The cost target and how rigid that target is.
• The time frame you need to meet

These allow you to filter the approaches but also allow rejecting application you cannot make without revising the marketing requirements.

For instance if you have a single customer with one or two installations than you favour a building block approach with minimal development time for hardware and software. Short allowable development time also favours similar solutions.

OTOH, if you have a market of millions and a long development time you can favour custom hardware and software as needed to minimize cost.

Probably more to come but family calls.

Robert