Integrating Micromonitor Support Into RTEMS

[Joel Sherrill]

Ed Sutter wrote:
> Interesting idea, here are a couple of points...
>
> 1. uMon is inherently single threaded...
>    When running under its own context (no OS running yet),
>    that's not an issue.  It does become a concern; however, when
>    a multi-tasking RTOS tries to use the monitor's API.  There
>    are hooks that can be installed so that all uMon API calls are
>    wrapped with OS-specific lock/unlock functions.
>   
This is easy enough to handle.
> 2. uMon doesn't use interrupts...
>    This makes porting uMon pretty simple, but then if an RTOS is
>    going to re-use the API, it needs to be done with that in mind.
>    Not hard, just means a task would have to poll for input.
>
>
>   
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. :)
> Keeping that in mind, the API has a full suite of basic services
> available for use by the application: console io, network packet-level io,
> flash file system (TFS), frame-buffer output (dynamically sized font
> rendering, plus some bitmap support), etc...
>
>   
:)
> 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.
 
> There's a demo application (in the uMon tarball) that hooks LWIP up
> to uMon's packet interface.  Its not a very efficient hookup, but it
> does show that any target that boots with uMon has an immediate network
> interface.  So Joel, you may be able to use that as an example on how
> to have RTEMS have a uMON-based ethernet driver.
>   
Cool!  Now I just need to get a uMon board to have on hand all
the time here. The csb637 is only here another week.

--joel
> Ed
>
>
>
> Joel Sherrill wrote:
>   
>> Leon Pollak wrote:
>>     
>>> Here, at PLR, we happily use Micromonitor for years to run RTEMS.
>>> We did a BSPs called uMon_8260 and uMon860 which actually do wrapping 
>>> the console to uMon and include Ethernet driver.
>>>
>>>   
>>>       
>> That's interesting.  I hadn't considered pushing this farther
>> and providing some generic uMon drivers to help kick start
>> a BSP.
>> Would you consider submitting those?  I think I have a bit
>> of an idea for a generic uMon BSP. :)
>>     
>>> That is...:-)
>>>
>>> Thanks a lot to Ed Sutter.
>>>   
>>>       
>> Indeed.
>>
>> --joel
>>     
>>> On Thursday June 11 2009, Joel Sherrill wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> I am close to having the Micromonitor application
>>>> support code working completely with RTEMS.  This
>>>> includes the "monlib" functionality which allows
>>>> you to utilize a LOT of functionality provided by
>>>> the monitor as well as Ed Sutter's "TFS RTEMS
>>>> Filesystem".  Micromonitor has its own file system
>>>> and his TFS filesystem allows you to mount this
>>>> and access it via monitor support.
>>>>
>>>> The code will obviously only work on boards with
>>>> Micromonitor but since Micromonitor supports
>>>> many boards across multiple architectures and this
>>>> code is BSP independent, I am feeling a tug to
>>>> put it into CPU Kit since it only requires 1 BSP
>>>> method to support it.
>>>>
>>>> The alternative is to put it in libbsp/shared and
>>>> make every BSP that wants to use it, add rules to
>>>> their Makefile.am.
>>>>
>>>> Any suggestions?  Thoughts?
>>>>     
>>>>         
>>>   
>>>       
>>     


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985