[ale] Linux vs XP Embedded

[John Mills]

Joe, ALErs -

I can't compare Linux and XP, but I have a couple of anecdotal data 
points.

On Tue, 24 Feb 2004, Joe Knapka wrote:

> Does anyone have any further suggestions or alternatives?  Also, is
> anyone here in a position to evaluate the relative strengths of Linux
> vs XP Embedded?  Personally I feel that the "Embedded" part of that
> name is probably pure marketing hype, but I could be wrong.  It is hard
> to see how Linux could possibly be a *worse* choice then XP in this
> domain, though.

At a previous site we worked on a server app where low latency was an
issue. We got poor results from tests written and run within Linux (vs.  
Win2K), then realized our response latency was quite low, but the _test_ 
_reports_ were based on Linux's 'generic' time-slicing interval.

On the same project I evaluated the free downloadable versions of TimeSys
Linux for both the 'Wintel' PC and PPC (on a mother-board that essentially
duplicated a PC environment). This was [IIRC] TImeSys version 2.4, approx.  
8/2002. I found the PPC installation easy to set up with TFTP and
NFS-exported disk space from my RN-7.3 host.

I found the Wintel version crunched badly when used as a dual-boot target
in a Wintel RH-7.2 box, but didn't try it as a "stand-alone" setup.

The mixed boot/NFS/debug environment worked pretty well for me. You wrap 
the mother board's serial port back to your host, connect with 'minicom' 
or something similar, and can use it as remote emacs/gdb target.

I just followed the directions in the download (interpolated for a
different PPC target) and was up and running in a few hous.

One advantage of a native Linux platform is you have good debugging tools.  
Be sure you consider this in any embedded project.

There was one specific problem: our app depended heavily on the ACE 
software infrastructure which [apparently] pushes threading pretty hard. 
That version of TimeSys was [apparently] not really thread safe and as a 
result a number of the ACE validation tests failed. The failed identically 
in PPC and Wintel setups, whether I built them with native or cross tools. 
At the time Ampro was in TimeSys validation tests of the PPC product, so 
TimeSys repeated my tests and got my results. TimeSys also reported their 
new, not-yet-free library version handled ACE properly and passed as many 
tests as the stock out-of-the-box RH-7.3, but we weren't willing to buy a 
sample ("development support" is what they actually offered, with no 
forecast date of delivey), so I never got to try that one.

My current project is a Linux-hosted server for low-rate (1-5/sec) JPEG 
frames. The developers are a Windows house and would have used Windows, 
but their product can't support the license costs of MsWin servers for 
'enough' clients. Look into licenses in your comparison.

Note for many embedded products you will need to develop or purchase a 
"Board Support Package" for your specific target. That may influence your 
evaluation.

The year before, I looked into the SH-2 build of RTEMS (now from
"www.rtems.com", I think).  If you want multiple and/or mixed sets
processors, look at RTEMS. It exports a number of APIs, including Linux.

I like RTEMS' approach - huge number of configuration variables and
packages as-you-need-em. You did need a fair amount of "real" RAM -
c.200MBy - to link the beast. You may have to buy or 'roll your own' BSP.

I was stuck with Hitachi's MsWin monitor debugger, a poor specimen at
best: Hitachi wanted to sell their "big-ticket" ICE system, and I didn't
have a fully functional gdb 'shim' to use from Linux. It still worked much
better with my Linux/GCC-built code than with the Hitachi compiler/linker
setup - that code crashed and locked the MsWin debugger 'tigher than a
tick' and couldn't see the source code (but could see the GCC source).

Happy trails.

Did I mention debuggers? @#$!!

 - John Mills
   1884 Ridgewood Dr, NE
   Atlanta, GA 30307-1166
   404.377.2577
   john.m.mills at alum.mit.edu