rtems with matlab autocode problems

[Jiri Gaisler]

João Rasta wrote:
>>From the rtems user_c doc:
> 
> Some of the reasons that rtems/confdefs.h may reserve too much memory
> for RTEMS are:
> • All tasks/threads are assumed to be floating point.

This might apply for the stack space, but not for enabling the
FPU on the SPARC port ...

I would try this define:

#define CONFIGURE_INIT_TASK_ATTRIBUTES    RTEMS_FLOATING_POINT


Jiri.

> 
> 
> Best,
> JM
> 
> On Thu, Jun 17, 2010 at 12:51 PM, Jiri Gaisler <jiri at gaisler.com
> <mailto:jiri at gaisler.com>> wrote:
> 
> 
>     Since you are using floating-point operands (%f8), you need to
>     enable FPU support
>     in the Init task ....
> 
>     Jiri.
> 
>     João Rasta wrote:
>     > Well, i'm using regular printf. I would not point to the encoding
>     since
>     > it allways prints the same thing no matter what i pass to printf().
>     >
>     > I removed the 3 optimization in the gcc flags and removed the
>     other ones
>     > and the same problem occurs. If i remove the printf the application
>     > exits on the following instruction
>     >
>     > IU in error mode (tt = 0x2b)
>     >  4000ca8c  d127bfec   st  %f8, [%fp - 0x14]
>     >
>     > . I'm initializing rtems with:
>     >
>     > #define CONFIGURE_INIT
>     > #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>     > #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>     >
>     > #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 10
>     > #define CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE (300*1024)
>     >
>     > #define CONFIGURE_MAXIMUM_POSIX_THREADS             10
>     > #define CONFIGURE_MAXIMUM_POSIX_MUTEXES                10
>     > #define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES            5
>     >
>     > #define CONFIGURE_POSIX_INIT_THREAD_TABLE
>     >
>     > I think i have enough stack space.
>     > Also, if i point CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT  to a
>     function
>     > declared on the autocode the printfs do not work well, which does not
>     > happen if i point it to a function declared on the main code.
>     >
>     > The autocode is compiled with sparc-rtems-gcc and a library
>     libgnc.a is
>     > created which is then passed to the compiler at link time with -lgnc.
>     > The library is created with
>     >
>     > ar ruvs libgnc.a *.o
>     >
>     > Does it make sense that there may be a problem with the compiled
>     .o's of
>     > the library? If so, how can its declared functions be messing up with
>     > memory operations and not on the main code? They use the same
>     compiler..
>     >
>     >
>     > Best,
>     > JM
>     >
>     > On Thu, Jun 17, 2010 at 4:18 AM, Ralf Corsepius
>     > <ralf.corsepius at rtems.org <mailto:ralf.corsepius at rtems.org>
>     <mailto:ralf.corsepius at rtems.org <mailto:ralf.corsepius at rtems.org>>>
>     wrote:
>     >
>     >     On 06/16/2010 07:48 PM, João Rasta wrote:
>     >
>     >         Yes, here goes
>     >
>     >         // dummy printf test code
>     >         int upa(void)
>     >         {
>     >             int i = 0;
>     >
>     >             for (i=0; i<  20; i++)
>     >                 printf("B\n");
>     >
>     >             exit(0);
>     >
>     >         }
>     >
>     >         And the result is:
>     >
>     >
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >             ¬ÖUf
>     >
>     >         Program exited normally.
>     >
>     >     Hmm, I am seeing "4 characters per line" instead of "1 or 2
>     >     characters per line" as one would expect.
>     >
>     >     Are you sure your code uses the right printf? 4 chars instead of 1
>     >     could indicate using UTF8 or UTF16 encoding instead of ACSII.
>     >
>     >
>     >         sparc-rtems-gcc -c -O3 -g3 -ffloat-store -fPIC   -DUSE_RTMODEL
>     >         -DMODEL=gnc
>     >         -DRT -DNUMST=1 -DTID01EQ=0 -DNCSTATES=0 -DUNIX -DMT=0
>     -DHAVESTDI
>     >         O   -I. -I../../rtwlt/matlab/simulink/include
>     >         -I../../rtwlt/matlab/extern/include
>     -I../../rtwlt/matlab/rtw/c/src
>     >         -I../../rtwlt/matlab/rtw/c/
>     >         src/ext_mode/common -I. -I.. -I../../rtwlt/matlab/rtw/c/libsrc
>     >         ../../rtwlt/matlab/rtw/c/src/rt_sim.c
>     >
>     >
>     >     ... -O3 -g3 -ffloat-store -fPIC
>     >     certainly leave room for speculation on incompatibility.
>     >
>     >     -03 ... switches on dangerous optimizations
>     >     -ffloat-store ... could be incompatible to rtems-gcc/newlib
>     >     -fPIC ... unneeded, unused by the rtems-toolchains, unknown
>     >       side effects on rtems-gcc/newlib
>     >
>     >     Ralf
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > rtems-users mailing list
>     > rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>     > http://www.rtems.org/mailman/listinfo/rtems-users
>     _______________________________________________
>     rtems-users mailing list
>     rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>     http://www.rtems.org/mailman/listinfo/rtems-users
> 
>