rtems with matlab autocode problems
João Rasta
freakforever at gmail.com
Thu Jun 17 14:32:22 UTC 2010
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> 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] *On Behalf Of *João Rasta
> *Sent:* Thursday, June 17, 2010 10:33 AM
>
> *To:* Ralf Corsepius
> *Cc:* 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>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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100617/686917c4/attachment-0001.html>
More information about the users
mailing list