Integrating Micromonitor Support Into RTEMS (more)

Ed Sutter esutter at
Thu Jun 11 19:57:59 UTC 2009

So, in theory, you could have a uMon BSP that would
only require RTEMS to provide context switching.  Then you would
have one task do the console polling (UART), and another task
poll for incoming Ethernet packets (until the real stuff is tested).
This would provide almost an "instant-up" for an RTEMS app ontop
of a uMon based board.

I do this now but without even using interrupts...
Obviously limited, but still quite handy at times.

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.
> 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.
> 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.
> 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.
> 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
>>>> Any suggestions?  Thoughts?
> _______________________________________________
> rtems-users mailing list
> rtems-users at

More information about the users mailing list