rtems with matlab autocode problems

Manuel Coutinho manuel.coutinho at edisoft.pt
Thu Jun 17 11:56:13 UTC 2010


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/81c2acc1/attachment-0001.html>


More information about the users mailing list