Integrating Micromonitor Support Into RTEMS

[Chris Johns]

Ed Sutter wrote:
> 
> 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.
> 

This was not a comment on RTEMS or umon, rather a possible side effect 
we should comment on and make visible. I think umon is a important 
addition to RTEMS because it add mores hardware to RTEMS. There is a 
definite need for good boot monitors and umon helps fill this niche.

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

My specific concern is a new user who does not know RTEMS takes a BSP 
and tests it to find performance is not what it should be so thinks 
RTEMS is no good.

> Any numbers reported as "RTEMS throughput measurements" would have to be
> qualified in several ways.

Absolutely.

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

Agreed.

Regards
Chris