Integrating Micromonitor Support Into RTEMS
esutter at alcatel-lucent.com
Thu Jun 11 19:46:16 UTC 2009
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.
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.
>> On Thursday June 11 2009, Joel Sherrill wrote:
>>> 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?
More information about the users