Command line arguments

[Joel Sherrill <joel@OARcorp.com>]

Steve Strobel wrote:


> At 02:08 PM 10/14/2004 +0200, you wrote:
> 
>>Hello Ed
>>
>>Thanks for your reply.
>>
>>On Thu, Oct 14, 2004 at 07:30:26AM -0400, Ed Sutter wrote:
>>
>>>Lars,
>>>I beleive this is boot loader specific.  At the time of command
>>>line entry, the boot loader is still the active program, so it 
>>>must provide the ability to deal with arguments.  In MicroMonitor,
>>>this is very easy to do and pretty much independent of the CPU/RTOS.
>>>
>>>Command line arguments established when the application starts up
>>>are stored in the monitor's environment, then through a monitor
>>>API call, they can be retrieved from anywhere in application
>>>space (assuming the application doesn't disallow access to the
>>>monitor's API because of MMU-based protection).
>>>
>>>In most uMon-based applications, this API call is made prior to main()
>>>so that argc/argv are populated just like a normal program; however,
>>>this isn't a requirement.
>>
>>Yes, I know of the monConnect and mon_getargv calls to uMon, but my
>>problem is not getting the arguments from the boot loader. My problem is
>>to get the arguments from the bootcard function into my task.
>>
>>Thanks
>>Lars Munch
> 
> 
> 
> We are using uMon, but ran into the same problem.  We retrieved the command line arguments in rtems_main, but didn't have a clean way to get them into the thread that needed them.  We probably could have waited to retrieve them from uMon until we were in that thread, but we used a couple of global variables instead.  Some of the relevant code follows.  Please let me know if you need more information about what we did, or if you have a cleaner way of doing it.
> 
> Steve
> 
> P.S.  Should this kind of thing go in the wiki?  If so, where?

If there is a MicroMonitor entry, it would seem to be the appropriate
place to add it.

If there is a generic way to get the arguments to a user "main",
it might be nice to distribute it with RTEMS.

Ed.. would it make sense to have an RTEMS helper library that is
separate from either Micromonitor or RTEMS?  You know you are using both 
so you can build your TFS code, some helper code for getting arguments 
to a main, etc?

I think the .h dependencies make it necessary to build this after both 
RTEMS and MicroMonitor.  So it would be best to avoid including it 
directly in either build.

> // don't know how to pass argc and argv through the tread starting 
> // mechanism, so using globals to bypass it
> int global_argc = 0;
> char **global_argv = 0;
> 
> // this function exists only to get the argument and return values right
> rtems_task rtems_call_to_rlc_main(rtems_task_argument argument)
> {
>   // don't know how to pass argc and argv through the tread starting 
>   // mechanism, so using globals to bypass it
>   rlc_main( global_argc, global_argv );
> }
> 
> // from example in c_user.pdf
> void start_rlc_in_thread(int argc, char **argv)
> {
>   rtems_id tid;
>   rtems_name name = rtems_build_name( 'R', 'L', 'C', 'T' ); // RLC Task
> 
>   // don't know how to pass argc and argv through the tread starting 
>   // mechanism, so using globals to bypass it
>   global_argc = argc;
>   global_argv = argv;
> 
>   rtems_status_code status = rtems_task_create( name, 100,
>     RTEMS_MINIMUM_STACK_SIZE * 2,    // Since we are allocating more than 
>                                      //the minimum stack size, we need to 
>                                      // account for it by defining 
>                                      // "CONFIGURE_EXTRA_TASK_STACKS" to the 
>                                      // appropriate value in rtemscfg.h
>     RTEMS_PREEMPT | RTEMS_TIMESLICE, 
>     RTEMS_FLOATING_POINT | RTEMS_LOCAL, &tid );
> 
>   if ( status != RTEMS_SUCCESSFUL ) 
>   {
>     debug_printf( "rtems_task_create failed with status of %d.\n", status );
>     exit( 1 );
>   }
>   status = rtems_task_start( tid, rtems_call_to_rlc_main, 0 );
>   if ( status != RTEMS_SUCCESSFUL ) 
>   {
>     debug_printf( "rtems_task_start failed with status of %d.\n", status );
>     exit( 1 );
>   }
> }
> 
> 
> ---
> Steve Strobel
> Link Communications, Inc.
> 1035 Cerise Rd
> Billings, MT 59101-7378
> (406) 245-5002 ext 102
> (406) 245-4889 (fax)
> WWW: http://www.link-comm.com
> MailTo:steve at link-comm.com
> 


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