Integrating Micromonitor Support Into RTEMS

[Chris Johns]

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.

Regards
Chris