Integrating Micromonitor Support Into RTEMS

[Ed Sutter]

Chris Johns wrote:
> Joel Sherrill wrote:
>> Ed Sutter wrote:
>> That would be OK for many uses.  I suspect the Ethernet
>> is where we would get into throughput problems for
>> RTEMS applications.  But if it is light duty use and the
>> application can afford a polling task, it might be better
>> than writing a new driver. :)
> 
> My concern here is what gets reported as through put gets interpreted as 
> RTEMS performance rather than a "useful" implementation.

Not quite sure I follow this... Performance numbers are affected by just
about everything in a given system.  The use of the uMon API simply provides
a quick path to getting started, and in some cases a valid option for
system deployment.  It wouldn't make sense to derive any respected set of
throughput numbers based on a system that uses the API.  But that would be
true for just about any aspect of the design (to include both HW and FW) if
that portion of the design wasn't tuned for performance.

   Here's a blatantly obvious example..
   Assume I use an RTEMS application to pull data off a "gizmo".  I do this with
   a serial port running at 9600 baud.  I then claim that I'm using RTEMS but
   getting lousy throughput.
   Clearly this is a mis-representation of RTEMS's throughput, so the numbers
   need to be qualified by stating that a slow interface is used.

An inefficient driver (HW and/or FW) or inappropriate use of various system
calls could have the same effect and it would mis-represent RTEMS core.  Right?
Any numbers reported as "RTEMS throughput measurements" would have to be
qualified in several ways.

Just to make it clear... Use of the uMon API in ANY embedded platform provides
a common/convenient/portable API at the expense of performance.  That is a given.


Ed