Integrating Micromonitor Support Into RTEMS
chrisj at rtems.org
Thu Jun 11 22:45:38 UTC 2009
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.
>> Long term, it seems to me that the user is better served to run with
>> the more efficient direct hookup to RTEMS device interface; however, it
>> could provide a stop-gap in certain situations.
> I agree with you 100%. I see a few useful scenarios for this.
> + ease bringing up RTEMS on a uMon based board. You could
> start with a full set of "generic uMon/RTEMS drivers" and replace
> them as required.
> + generic uMon/RTEMS drivers could be used on any
> uMon based board so you could always have the functionality.
> In many cases, it may be good enough.
> I am thinking that the uMon based console would be good
> enough when all you want is debug IO. And the TFS and LCD
> support would likely be good enough for most RTEMS applications.
With this in mind I would prefer the BSP support to be in libbsp/umon so
references are easy to find and control. The README for the BSP could
have the comments Ed has made.
More information about the users