information about resources of actual application

[Fernando RUIZ CASAS]

Hi.

> -----Mensaje original-----
> De: Jan.Suchotzki at de.abb.com [mailto:Jan.Suchotzki at de.abb.com]
> Enviado el: jueves, 27 de septiembre de 2001 15:08
> Para: fernando.ruiz at ctv.es; rtems-users at oarcorp.com
> Asunto: RE: information about resources of actual application
>
>
>
> Hi,
>
> >With CPU_usage_dump() you can see this.
> >With malloc_dump() you can see the memory usage.
>
> The function CPU_usage_dump() works fine and helps a lot.
>
> But I run in trouble with malloc_dump(). When I call this
> function nothing happens. I saw that I went into a version of
> malloc_dump()
> with an empty body (only return) while debugging my application.
> I recognised, that the right version (which makes some output) of
> malloc_dump()
> will be called only if RTEMS_DEBUG is defined.
> I have compiled and installed my Snapshot with VARIANT=DEBUG and
> compile my
> appilcation with make debug. I´ve included rtems/libcsupport.h for
> malloc_dump().

This was my way to locate any errors. Patch the sources.

>
> Can somebody tell me why it didn´t work? I try to execute it with the
> m68k-efi332 bsp.
>
> >In my shell.c I can exec interactively these functions and tasks and more
> >to examinate the cpu load, task list, memory usage, number of resources
> >used...
>
> I´ve tried it out, but also here are some problems. I´ve found an example
> application you posted to the list on 7.9.2001. It´s for a pc386 BSP but I
> think
> with some modification it should work on a m68k BSP too.

Of course.

> The first problem was the configure_memory_overhead 16386. I´ve deleted
> this line
> because my application crashed. When I run the example I see one line on
> the console
> with some hieroglyphic characters. But I didn´t see a prompt and
> I can´t do
> some
> inputs.
>
> Do you have an idea what happens?
>
Is you console ready to show characters before call the shell_init()?
The hieroglyphic are usually a problem of baudrate, parity, etc...
Printf a "hello world" and flush the stdout before call shell init() and
test this problem.

Execute a termios test in the tests subdirectory and try that your driver
is a real termios driver.

A little patch has been sended to Joel in order to avoid a
test in NULL file pointer when the password is read.


--------------- EMAIL -----------------------------

Hi,

In file c/src/libmisc/shell/shell.c near line 292 I think there should be a
check to make sure that FILE* out is not NULL before calling
tcdrain(fileno(out)) (out is NULL when entering a password).

Unless I'm mistaken (again!) this is still a problem in snapshot
ss-20010816.

Regards,
Andy

/* ----------------------------------------------- *
 * TODO: Add improvements. History, edit vi or emacs, ...
 * ----------------------------------------------- */
int shell_scanline(char * line,int size,FILE * in,FILE * out) {
  int c,col;
  col=0;
  if (*line) {
   col=strlen(line);
   if (out) fprintf(out,"%s",line);
  };
  tcdrain(fileno(in ));
  if( out )
    tcdrain(fileno(out));


Surrey Satellite Technology Limited
http://www.sstl.co.uk
The views expressed in this email are my own(isn't that reassuring?)


---------------- EMAIL ----------------------------

* shell_scanline(FILE * in,FILE * out) doesn't test the NULL case for the
password read.
(libmisc/shell.c)

In tasks.c in rtems core a little bug produces a crash when the shell task
is finished.

Pass the 'forever' parameter always TRUE to avoid this.

Have you build the pc386-rtems?. Cheap, easy and wonderful to try the
software.
A Grub image diskette (MS-FORMAT). you put the init.exe file and reboot the
machine.
You can test the software in other environment before searching the bugs in
your sources.

My first developement was for the sh-rtems. There the shell was developped
and once developped
it was moved to rtems generic tree.

Fernando RUIZ CASAS
home: correo at fernando-ruiz.com
work: fernando.ruiz at ctv.es