rtems with matlab autocode problems
Jiri Gaisler
jiri at gaisler.com
Thu Jun 17 14:38:29 UTC 2010
Setting -O0 is equal to wasting ~ 70% of the cpu performance.
Just so you know ....
Jiri.
João Rasta wrote:
> Dear all,
>
> I have finally managed to solve this issue by using the following
> compilation flags *only* on the autocode library:
>
> OPT_OPTS = -O0 -g -fmessage-length=0
>
> I suspect of the ffloat-store and O3 optimization flags placed on the
> library makefile by default by matlab, and mabe my answer to Ralf was
> affected by not touch'ing all the project files before compilation.
>
> I'm extremely grateful for all your valuable help.
>
>
> Best,
> JM
>
>
>
> On Thu, Jun 17, 2010 at 12:56 PM, Manuel Coutinho
> <manuel.coutinho at edisoft.pt <mailto:manuel.coutinho at edisoft.pt>> wrote:
>
> Hi
>
> Are you sure you are using the correct baud rate to comunicate with
> the board (using GRMON)?
> Did you try different baud rates?
>
>
> Regards
>
> Manuel Coutinho
> Software Engineer - Space
>
> EDISOFT, S.A.
> Rua Quinta dos Medronheiros - Lazarim
> Apartado 382 Monte de Caparica
> 2826-801 Caparica Portugal
> Tel: (+351) 212 945 900
> Fax: (+351) 212 945 999
>
>
>
> ------------------------------------------------------------------------
> *From:* rtems-users-bounces at rtems.org
> <mailto:rtems-users-bounces at rtems.org>
> [mailto:rtems-users-bounces at rtems.org
> <mailto:rtems-users-bounces at rtems.org>] *On Behalf Of *João Rasta
> *Sent:* Thursday, June 17, 2010 10:33 AM
>
> *To:* Ralf Corsepius
> *Cc:* rtems-users at rtems.com <mailto:rtems-users at rtems.com>
> *Subject:* Re: rtems with matlab autocode problems
>
> 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>> 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
> http://www.rtems.org/mailman/listinfo/rtems-users
More information about the users
mailing list