One SBC or two?

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, 

Why not use some slow (by today's standard) and hence low power x86
SBC to run the RT part, which would simplify any backup power and
cooling requirements.

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

If 24x7 operation is required, the combination of Internet
connectivity and Windows is a bit problematic. While current Windows
versions are quite stable, the Internet connection would require
frequent installations of security updates, which would require
frequent reboots. If the RT part is on a separate processor, it could
ride through the UI side reboots.

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

Does the current UI consist of mechanical switches, potentiometers and
indicator lights or some on screen simulation of these ?

Would it be possible to leave the current UI as a backup and the
simply letting the new UI send (e.g. via serial line) commands
simulating the actual button operations ? Of course, handling of the
most complex functionality should be removed from the RT side and
replaced with a sequence of simpler commands.

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

With such products, existing and functioning parts should be reused as
much as possible, which may cause some ugly interfacing situations.
However, if the expected new product family life time is a decade or
more, it might make sense to improve the interface between the
systems.

Keeping the RT and UI systems as separate is a good idea, if the RT
system can remain the same for the rest of the product family life
time, but it may be necessary to upgrade the UI side 1-2 times during
the same period (e.g. due to consumer demand) both HW and/or SW.

Thanks for the replies so far.  One thing I should make clear (many of
you have alluded to it) is that if we do go with one processor, there
will be an "as-if-through-a-wire" interface between the two sections.
The GUI will have a very controlled and limited view of the innards of
the realtime component, and vice versa.  So the effort to develop an
interface is probably close to a wash between the one and two
processor approaches.

On Jan 19, 9:06=A0am, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> Thanks for the replies so far. =A0One thing I should make clear (many of
> you have alluded to it) is that if we do go with one processor, there
> will be an "as-if-through-a-wire" interface between the two sections.
> The GUI will have a very controlled and limited view of the innards of
> the realtime component, and vice versa. =A0So the effort to develop an
> interface is probably close to a wash between the one and two
> processor approaches.

WinSystems.com has done a fair job of getting the 'horsepower' up
lately so a single SBC might not be as slow at handling a more comples
set of tasks and they (probably others too) have an evaluation system
so you could check out a bd or 2 for probably not much more than
shipping costs.

On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
> 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. =A0We're looking at a major upgrade of an existing
> > product. =A0The 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. =A0The 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. =A0This may well put us into Linux or some version of
> > Windows. =A0Due to the excruciating entanglement of the current UI and
> > realtime, it would certainly require a major rewrite of the realtime
> > in any case. =A0I 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. =A0What do you see as advantages and disadvantage=
s
> > to separating the functionality onto two SBCs, one for realtime and
> > one (not necessarily the same) for GUI, etc.? =A0Both approaches (singl=
e
> > SBC or dual) have come up for discussion. =A0I'd like to hear as many
> > viewpoints on the question as I can get. =A0Thanks.
>
> Opinions are cheap, no? =A0Here's another one. =A0Do the real time stuff
> in an FPGA! =A0Software will always be hard to debug, especially for
> real time stuff. =A0Consider what happens with a processor... using a
> sequential language to programm a sequential processor to emulate a
> lot of separate functions happening in parallel. =A0In an FPGA,
> programmed in an HDL, you get exactly that, parallel programs with
> parallel execution on parallel hardware! =A0Every 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! =A0I would have done the entire
> thing in the FPGA with only the fastest parts being done in PECL. =A0But
> 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. =A0In this case the GUI is a clock display with
> buttons to set the digits, just like a clock at home. =A0There 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. =A0In 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. =A0This
> eliminates the risk of not having enough processor capability to meet
> your real time requirements.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

In fact I am completely open to using an FPGA where it would be
appropriate.  In fact I would go further and say that it's very likely
there will be an FPGA in the new realtime design - just a question of
in what capacity.  Now the real question is, VHDL or Verilog? :)

On Jan 19, 10:43=A0am, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > 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. =A0We're looking at a major upgrade of an existing
> > > product. =A0The existing product is over a decade old and uses a 500M=
Hz
> > > x86 SBC to do a lot of realtime (motor control and other things) and
> > > to run a primitive UI. =A0The 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. =A0This may well put us into Linux or some version of
> > > Windows. =A0Due to the excruciating entanglement of the current UI an=
d
> > > realtime, it would certainly require a major rewrite of the realtime
> > > in any case. =A0I 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. =A0What do you see as advantages and disadvanta=
ges
> > > to separating the functionality onto two SBCs, one for realtime and
> > > one (not necessarily the same) for GUI, etc.? =A0Both approaches (sin=
gle
> > > SBC or dual) have come up for discussion. =A0I'd like to hear as many
> > > viewpoints on the question as I can get. =A0Thanks.
>
> > Opinions are cheap, no? =A0Here's another one. =A0Do the real time stuf=
f
> > in an FPGA! =A0Software will always be hard to debug, especially for
> > real time stuff. =A0Consider what happens with a processor... using a
> > sequential language to programm a sequential processor to emulate a
> > lot of separate functions happening in parallel. =A0In an FPGA,
> > programmed in an HDL, you get exactly that, parallel programs with
> > parallel execution on parallel hardware! =A0Every 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! =A0I would have done the entire
> > thing in the FPGA with only the fastest parts being done in PECL. =A0Bu=
t
> > 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. =A0In this case the GUI is a clock display with
> > buttons to set the digits, just like a clock at home. =A0There 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. =A0In 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. =A0This
> > eliminates the risk of not having enough processor capability to meet
> > your real time requirements.
>
> > Rick- Hide quoted text -
>
> > - Show quoted text -
>
> In fact I am completely open to using an FPGA where it would be
> appropriate. =A0In fact I would go further and say that it's very likely
> there will be an FPGA in the new realtime design - just a question of
> in what capacity. =A0Now the real question is, VHDL or Verilog? :)- Hide =
quoted text -
>
> - Show quoted text -
Hmmm, my "in fact" key seems to be stuck in the down state...

KK6GM schrieb:
> 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.

Since modern SBCs are likely to be multi-core processors I would try to 
get away with on SBC and dedicate one core to the GUI part and one core 
to the real-time processing. But maybe there are some folks here around 
that have more experience with these kind of designs than me...

Greetz,
Sebastian

Chris H wrote:

> 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

You say that the product is high value, low volume. In which case the 
software development costs will be lessened if you adopt a sensible 
architecture with multiple processors. You didn't state how many 
actuators/motors are attached to the system but I tend to favour one 
processor per actuator keeping the individual systems very simple. Usually 
smaller less expensive processors can be used. A suitable network to connect 
them along with some interlocking will usually keep the various systems in 
sync and safe.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On Jan 18, 1:58=A0pm, 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.

Like others I would favour separating into multiple processors.  This
mirrors the industrial approach with PLCs and HMIs.

Besides the advantage of being able to update the GUI relatively
easily and separately you can do the same with the control  IE you
could change the motors from HALL sense commutated BLDC to sensorless
switched reluctance with a 'simple' change of drive control.  Or you
could change the size of the motors and retain the same GUI.

It does, however, place high value on defining the network interface
well at the beginning.  Ways to get ID information and status from the
real-time components.  Control definitions that are not limited
(either defined as unitless [motor speed as percent of full speed] so
they scale with the peripheral or with units that don't saturate
easily [motor speed as rpm in some sort of floating point
representation]).  And consider adding signals out of band to the
normal communications such as stop etc...  And make sure the
definition is expandable so it can grow over time.

The other advantage of having the GUI separate is that it is a lot
easier to make it remote, or provide additional status displays.

Whether you can easily separate the various realtime co-ordinates will
depend on how closely they have to be synchronized.  The latency
requirements are stiffer for controlling a pair of motors driving an x/
y table to follow an arc then they are for a motor running a mixer and
a second running a feed screw.

Robert

On Jan 19, 1:43=A0pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > Opinions are cheap, no? =A0Here's another one. =A0Do the real time stuf=
f
> > in an FPGA! =A0Software will always be hard to debug, especially for
> > real time stuff. =A0Consider what happens with a processor... using a
> > sequential language to programm a sequential processor to emulate a
> > lot of separate functions happening in parallel. =A0In an FPGA,
> > programmed in an HDL, you get exactly that, parallel programs with
> > parallel execution on parallel hardware! =A0Every 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! =A0I would have done the entire
> > thing in the FPGA with only the fastest parts being done in PECL. =A0Bu=
t
> > 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. =A0In this case the GUI is a clock display with
> > buttons to set the digits, just like a clock at home. =A0There 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. =A0In 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. =A0This
> > eliminates the risk of not having enough processor capability to meet
> > your real time requirements.
>
> > Rick- Hide quoted text -
>
> > - Show quoted text -
>
> In fact I am completely open to using an FPGA where it would be
> appropriate. =A0In fact I would go further and say that it's very likely
> there will be an FPGA in the new realtime design - just a question of
> in what capacity. =A0Now the real question is, VHDL or Verilog? :)

As we speak, er, write, I am helping a friend with a similar issue.
He is a good embedded engineer and has done small PLD designs before,
but nothing as grand as an FPGA, if you can call FPGA design "grand".
He asked me to get him up and running on a project he has on a short
fuse.  I am writing the code for the first phase for him and will turn
it over to him for the subsequent phases with a little hand holding.
I asked a few questions and decided it would be best if his project
were done in Verilog.  My expertise in Verilog is not as good as VHDL,
but I sincerely  believe that VHDL would take him much more time to
come up to speed on.  My only reservation with Verilog is that there
are a number of ways that you can shoot yourself in the foot without
even knowing it until most of your blood has drained out.  That can be
a problem with a relative newbie.

As for someone who has the time to learn properly and isn't afraid of
some strong typing (just how much of a man are you anyway?) I still
prefer VHDL at this point.  But ask me again when I am done with this
project.

I am pretty certain that your work will move ahead more quickly and
give you a lower cost, lower power and smaller size solution using a
combined FPGA - CPU approach than a pure CPU approach will.  There are
a number of very low power and tiny x86 CPU boards out there.  If you
move the real time work off the CPU, the UI becomes very easy.  With
tons of parallel processing, the real time work is very easy in an
FPGA.

BTW, if you find you want any help with the FPGA, that is my
specialty.  If you can't find a board that does what you want, I am
sure I can whip something up for you pretty easily.

Rick

On Jan 19, 2:08=A0pm, rickman <gnu...@gmail.com> wrote:
> On Jan 19, 1:43=A0pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
>
>
>
>
> > On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > Opinions are cheap, no? =A0Here's another one. =A0Do the real time st=
uff
> > > in an FPGA! =A0Software will always be hard to debug, especially for
> > > real time stuff. =A0Consider what happens with a processor... using a
> > > sequential language to programm a sequential processor to emulate a
> > > lot of separate functions happening in parallel. =A0In an FPGA,
> > > programmed in an HDL, you get exactly that, parallel programs with
> > > parallel execution on parallel hardware! =A0Every part can be debugge=
d
> > > in isolation without impacting the rest.
>
> > > I am working on a highly time critical design right now... in fact, i=
t
> > > will be used to define time itself! =A0I would have done the entire
> > > thing in the FPGA with only the fastest parts being done in PECL. =A0=
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. =A0In this case the GUI is a clock display with
> > > buttons to set the digits, just like a clock at home. =A0There 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. =A0In fac=
t,
> > > 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. =A0Th=
is
> > > eliminates the risk of not having enough processor capability to meet
> > > your real time requirements.
>
> > > Rick- Hide quoted text -
>
> > > - Show quoted text -
>
> > In fact I am completely open to using an FPGA where it would be
> > appropriate. =A0In fact I would go further and say that it's very likel=
y
> > there will be an FPGA in the new realtime design - just a question of
> > in what capacity. =A0Now the real question is, VHDL or Verilog? :)
>
> As we speak, er, write, I am helping a friend with a similar issue.
> He is a good embedded engineer and has done small PLD designs before,
> but nothing as grand as an FPGA, if you can call FPGA design "grand".
> He asked me to get him up and running on a project he has on a short
> fuse. =A0I am writing the code for the first phase for him and will turn
> it over to him for the subsequent phases with a little hand holding.
> I asked a few questions and decided it would be best if his project
> were done in Verilog. =A0My expertise in Verilog is not as good as VHDL,
> but I sincerely =A0believe that VHDL would take him much more time to
> come up to speed on. =A0My only reservation with Verilog is that there
> are a number of ways that you can shoot yourself in the foot without
> even knowing it until most of your blood has drained out. =A0That can be
> a problem with a relative newbie.
>
> As for someone who has the time to learn properly and isn't afraid of
> some strong typing (just how much of a man are you anyway?) I still
> prefer VHDL at this point. =A0But ask me again when I am done with this
> project.
>
> I am pretty certain that your work will move ahead more quickly and
> give you a lower cost, lower power and smaller size solution using a
> combined FPGA - CPU approach than a pure CPU approach will. =A0There are
> a number of very low power and tiny x86 CPU boards out there. =A0If you
> move the real time work off the CPU, the UI becomes very easy. =A0With
> tons of parallel processing, the real time work is very easy in an
> FPGA.
>
> BTW, if you find you want any help with the FPGA, that is my
> specialty. =A0If you can't find a board that does what you want, I am
> sure I can whip something up for you pretty easily.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

Thanks again for the comments.  I was just having a bit of fun with
the VHDL v. Verilog comment - I've seen some of your posts on the
various fpga newsgroups so I knew it was a bit of a hot topic for
you.  I'm already working to build up some competency in VHDL.  By way
of background I think that Ada is far superior to C and C++, so
perhaps you can understand my choice in HDL.  But I'm derailing my own
thread, so I'll be quiet now.