Integrating Micromonitor Support Into RTEMS
chrisj at rtems.org
Sat Jun 13 04:39:13 UTC 2009
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
> 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
> getting lousy throughput.
> Clearly this is a mis-representation of RTEMS's throughput, so the
> 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.
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.
> Just to make it clear... Use of the uMon API in ANY embedded platform
> a common/convenient/portable API at the expense of performance. That is
> a given.
More information about the users