Integrating Micromonitor Support Into RTEMS (more)

[Joel Sherrill]

Ed Sutter wrote:
> 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.
>   
Exactly!!! 
> I do this now but without even using interrupts...
> Obviously limited, but still quite handy at times.
>   
Yep!
> Ed
>
> 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 Makefile.am.
>>>>>
>>>>> Any suggestions?  Thoughts?
>>>>>     
>>>>>           
>>>>   
>>>>         
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>     
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>   


-- 
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