PC/104

[bob]

<snip>
>
> > The arm, mips and powerPC have a very steep learning curve, depending on
> > what you're trying to do. And they are appropriate for running a complex
> > program, but not for some simple control tasks.
>
> Of course.
>
> > For example, I recently came across a system where *everything* is
> > controlled by a central PC board. This required complex multitasking
> > real-time software running under Linux that was very difficult to debug.
> > The genius who designed this has of course left the project.  The PC
> > software included such low-level tasks as operating a stepping motor and
> > detecting when a shutter is closed.
>
> Linux wasn't designed for real time at all.  Some people try to make it
> work for it, but I am not sure it will ever be a good fit for that.
>
> > It's much better to partition the system into low-level tasks that are
> > handled by microprocessors (not necessarily ours ;). The microprocessors
> > then communicate with the master PC host via some sort of com link such
> > as RS232 or CAN bus. So the PC issues a command to 'close the shutter'
> > and then the microprocessor reports back when the shutter is closed. Very
> > simple to implement and debug.
>

I can add my 2cents worth to this discussion.    I have found the approach 
espoused by Peter above to be exactly right when are talking about custom 
data acquisition projects in the 50-10000 I/O point range.

One of my associates makes a hugely capable, low power, network appliance for 
I/O (www.io-anywhere.ca) based entirely on the 8bit Rabbit microprocessor.  
I'm continually amazed at the capabilites that can be rammed into that 
appliance.

The time to market for custom systems based on a Linux server and a network of 
smart dedicated appliances can't be beat.

A few years back I had first hand experience with one of my clients.   The 
client was convinced that his polling RS485 application was best served by a 
PC-104 based controller with a Pentium classed microprocessor,  a custom 4 
port serial card and a custom 485 driver/handler.    They invested more than 
2 man years getting all this operational.     A skunk work project with a 
stock IOA took about 2 man weeks to string together,  including some 
customizations to the on board firmware.   Not only did the IOA plug and play 
with the Linux server and the existing software,  it offered several other 
features such as 485 line cut protection and 485 autodetect ... and came in 
at a much superior cost point per 485 point.


bob
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists