One SBC or two?

I'd like to hear what you folks think about the following question.
First, some setup.  We're looking at a major upgrade of an existing
product.  The existing product is over a decade old and uses a 500MHz
x86 SBC to do a lot of realtime (motor control and other things) and
to run a primitive UI.  The new product would do roughly the same
realtime stuff, but would add a modern GUI, connection to useful
peripherals such as printers, and some level of internet
connectivity.  This may well put us into Linux or some version of
Windows.  Due to the excruciating entanglement of the current UI and
realtime, it would certainly require a major rewrite of the realtime
in any case.  I could tell you such stories...

This is a high-price, low volume product, so cost of the computing HW
is insignificant compared to development cost and time.

Now for the question.  What do you see as advantages and disadvantages
to separating the functionality onto two SBCs, one for realtime and
one (not necessarily the same) for GUI, etc.?  Both approaches (single
SBC or dual) have come up for discussion.  I'd like to hear as many
viewpoints on the question as I can get.  Thanks.

On Tue, 18 Jan 2011 10:58:07 -0800 (PST), KK6GM <kk6gm@att.net> wrote:

>I'd like to hear what you folks think about the following question.
>First, some setup.  We're looking at a major upgrade of an existing
>product.  The existing product is over a decade old and uses a 500MHz
>x86 SBC to do a lot of realtime (motor control and other things) and
>to run a primitive UI.  The new product would do roughly the same
>realtime stuff, but would add a modern GUI, connection to useful
>peripherals such as printers, and some level of internet
>connectivity.  This may well put us into Linux or some version of
>Windows.  Due to the excruciating entanglement of the current UI and
>realtime, it would certainly require a major rewrite of the realtime
>in any case.  I could tell you such stories...
>
>This is a high-price, low volume product, so cost of the computing HW
>is insignificant compared to development cost and time.
>
>Now for the question.  What do you see as advantages and disadvantages
>to separating the functionality onto two SBCs, one for realtime and
>one (not necessarily the same) for GUI, etc.?  Both approaches (single
>SBC or dual) have come up for discussion.  I'd like to hear as many
>viewpoints on the question as I can get.  Thanks.

My own preference is more or less "as many microcontrollers as it takes"
rather than "let one big processor run everything." Plus, with a
sensible internal network, you also get diagnostic control and
monitoring capability almost for free.

-- 
Rich Webb     Norfolk, VA

In message <4856081d-3b13-4f6b-8014-327957d371d2@h17g2000pre.googlegroup
s.com>, KK6GM <kk6gm@att.net> writes
>I'd like to hear what you folks think about the following question.
>First, some setup.  We're looking at a major upgrade of an existing
>product.  The existing product is over a decade old and uses a 500MHz
>x86 SBC to do a lot of realtime (motor control and other things) and
>to run a primitive UI.  The new product would do roughly the same
>realtime stuff, but would add a modern GUI, connection to useful
>peripherals such as printers, and some level of internet
>connectivity.  This may well put us into Linux or some version of
>Windows.  Due to the excruciating entanglement of the current UI and
>realtime, it would certainly require a major rewrite of the realtime
>in any case.  I could tell you such stories...
>
>This is a high-price, low volume product, so cost of the computing HW
>is insignificant compared to development cost and time.
>
>Now for the question.  What do you see as advantages and disadvantages
>to separating the functionality onto two SBCs, one for realtime and
>one (not necessarily the same) for GUI, etc.?  Both approaches (single
>SBC or dual) have come up for discussion.  I'd like to hear as many
>viewpoints on the question as I can get.  Thanks.


You could use  two ARM parts. The same RTOS on both and the GUI on one.

Thus the same dev tools for both SBCs

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

If HW costs aren't important then I would favor a multi MCU design.  It's so 
nice to be able to program hard realtime apps without not having to worry 
about other SW interfering in an RTOS.  You can mix various MCUs for their 
different strong points.  You can also make use of multiple programmers (for 
more cost but doubling up on programming to achieve a shorter schedule) who 
can program in their clearly defined domain (that is, their own chip).  That 
requires a good bit of up-front design to make sure inter-MCU communications 
channels are sufficiently designed to support the application.

And for a completely different approach, perhaps you can find a good 
mulitcore chip that will do the job.  I'm not so willing to suggest that it 
will make programming easier or quicker though.

JJS

On Jan 18, 10:58=A0am, KK6GM <kk...@att.net> wrote:
>
> Now for the question. =A0What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.? =A0Both approaches (single
> SBC or dual) have come up for discussion. =A0I'd like to hear as many
> viewpoints on the question as I can get. =A0Thanks.

FWIW, IME SBC's w/ GUI have high latency, which is NG for RT (Is that
enough abbreviations?)

I see cost as the major disadvantage of a dual-CPU approach.

RK

KK6GM wrote:

> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

Doing everything on one processor is much simpler, cheaper and in any 
ways better then separating the functionality.

Every other programmable device involved in the system is PITA in 
development, production and support. There will be a lot of work to 
define and maintain the interfaces. There will be inevitable 
compatibility issues between the different versions of softwares and 
hardwares for the different parts of the system.  There will be 
development problems because "A" can't work without "B", and "B" can't 
work without "A"; so you will need to develop separate test setups for 
"A" and for "B".

So, my advice is stay with one core. If there is not enough of the real 
time or i/o capacity of the main CPU, use the low-level MCU devices to 
help with it.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jan 18, 1:58 pm, KK6GM <kk...@att.net> wrote:
> I'd like to hear what you folks think about the following question.
> First, some setup.  We're looking at a major upgrade of an existing
> product.  The existing product is over a decade old and uses a 500MHz
> x86 SBC to do a lot of realtime (motor control and other things) and
> to run a primitive UI.  The new product would do roughly the same
> realtime stuff, but would add a modern GUI, connection to useful
> peripherals such as printers, and some level of internet
> connectivity.  This may well put us into Linux or some version of
> Windows.  Due to the excruciating entanglement of the current UI and
> realtime, it would certainly require a major rewrite of the realtime
> in any case.  I could tell you such stories...
>
> This is a high-price, low volume product, so cost of the computing HW
> is insignificant compared to development cost and time.
>
> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

Opinions are cheap, no?  Here's another one.  Do the real time stuff
in an FPGA!  Software will always be hard to debug, especially for
real time stuff.  Consider what happens with a processor... using a
sequential language to programm a sequential processor to emulate a
lot of separate functions happening in parallel.  In an FPGA,
programmed in an HDL, you get exactly that, parallel programs with
parallel execution on parallel hardware!  Every part can be debugged
in isolation without impacting the rest.

I am working on a highly time critical design right now... in fact, it
will be used to define time itself!  I would have done the entire
thing in the FPGA with only the fastest parts being done in PECL.  But
my friend who actually has the contract (I am doing the FPGA part for
the initial phase) wants to use a CPU for the stuff that doesn't have
to be in the FPGA.  In this case the GUI is a clock display with
buttons to set the digits, just like a clock at home.  There is
nothing that couldn't be done in the FPGA, but often people have the
idea that an FPGA is hard to design because it is hardware.  In fact,
it is easier to design and debug because it is all in parallel and it
can be simulated with infinite visibility.

I expect that you can find an FPGA based motor control board which
will attach to whatever processor you wish to use for your GUI.  This
eliminates the risk of not having enough processor capability to meet
your real time requirements.

Rick

On 01/18/2011 10:58 AM, KK6GM wrote:
> I'd like to hear what you folks think about the following question.
> First, some setup.  We're looking at a major upgrade of an existing
> product.  The existing product is over a decade old and uses a 500MHz
> x86 SBC to do a lot of realtime (motor control and other things) and
> to run a primitive UI.  The new product would do roughly the same
> realtime stuff, but would add a modern GUI, connection to useful
> peripherals such as printers, and some level of internet
> connectivity.  This may well put us into Linux or some version of
> Windows.  Due to the excruciating entanglement of the current UI and
> realtime, it would certainly require a major rewrite of the realtime
> in any case.  I could tell you such stories...
>
> This is a high-price, low volume product, so cost of the computing HW
> is insignificant compared to development cost and time.
>
> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

What sort of bandwidth do you need between the GUI and the real-time stuff?

My knee-jerk response is to design the software so that it works as if 
there were a serial link between the GUI and the real-time stuff (i.e. 
with well-defined commands and responses, where the responses aren't 
required to be either immediate or in any particular order).

Whether you do one processor or two then becomes a tactical, rather than 
a strategic decision.  In general if it's a really complicated GUI, and 
if sales and marketing are going to want to continually stir the pot, 
then having a separate processor for the GUI means you can leave the GUI 
software development to a team that maybe isn't as astute with the hard 
real time stuff (and hope they don't manage to screw things up).  OTOH, 
if money ever does become an object, or if your software team is small, 
then you can keep it all on one processor.

Note that the choices of "real time with a real big OS" options that I 
know all devolve down to either Windows or Linux riding on top of a 
'real' RTOS, with all the real-time programming done _outside_ of the 
'big box' paradigm and Windows or Linux running as a fairly low-priority 
task under the RTOS, or an "all in one" big RTOS like VxWorks.

If you go with Windows or Linux, you'll need that "looks like a serial 
interface" API between the real-time part and the GUI no matter what, so 
plan on it.  If you use something like VxWorks, then your GUI will have 
to live in one or more low-priority tasks, and once again you'll need 
that "looks like a serial interface" API, or you'll be handing your GUI 
the power to break your real time control loops.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

KK6GM <kk6gm@att.net> writes:
> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?

My furnace controller has a Linux SBC and *five* additional MCUs (one
for each zone, plus one for the furnace itself) for realtime control.  I
put the MCUs on the I2C bus and treat them like very smart peripherals.

http://www.delorie.com/house/furnace/
http://industrial-embedded.com/embedded-home-climate-control

On 1/18/2011 1:58 PM, KK6GM wrote:
> I'd like to hear what you folks think about the following question.
> First, some setup.  We're looking at a major upgrade of an existing
> product.  The existing product is over a decade old and uses a 500MHz
> x86 SBC to do a lot of realtime (motor control and other things) and
> to run a primitive UI.  The new product would do roughly the same
> realtime stuff, but would add a modern GUI, connection to useful
> peripherals such as printers, and some level of internet
> connectivity.  This may well put us into Linux or some version of
> Windows.  Due to the excruciating entanglement of the current UI and
> realtime, it would certainly require a major rewrite of the realtime
> in any case.  I could tell you such stories...
>
> This is a high-price, low volume product, so cost of the computing HW
> is insignificant compared to development cost and time.
>
> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

It make sense to put all the realtime stuff (motor control) on an 
embedded board
and have the UI separate.  You could even use a desktop/laptop PC for 
the UI,
on an off the shelve PC104+ system (ex: Versalogic.com).  Then when you 
want to
add "new" UI features in a year, (put trend data into a database, or remote
monitoring over the Internet, for example), you can just update the
PC software an not touch the embedded hardware.  Also, with VPN and remote
sessions, you could log in the UI remotely without developing any additional
code.

Running Virtual OS on a multi-core hardware platform is a possible solution
that allows you to split the software, but still using one SBC, but
I'm not particularly keen on that approach as it seems overly convoluted
and relies on some vendors Virtual Hosting approach.

2SBC Adv:
   + independent RT & UI version control, separate updates;
     different types of programmer working independently.
     UI could be developed without motor hardware.
   + UI could be almost anything from a PC (Windows, Linux, QNX)
   + UI flexibility allows for infinite possibility of new features
     in the future without disturbing the solid RT code.
   + Cost not an issue for low volume, high price product.

2SBC DisAdv:
   - Communication Interfaces: Software, (doesn't exist, have to be written)
   - Communication Interfaces: Hardware, (cables across the factory floor?
     or wireless network noise issues).

National Instruments makes a cRIO product that has an onboard SBC with 
VxWorks
and an FPGA that would possibly work for this application, but 
unfortunately they
mainly support LabVIEW as the programming language, which most embedded
programmers, (including me), don't particularly care for.