headers
Thomas Doerfler | 5 Apr 2005 07:27
Picon
Favicon

REMINDER: RTEMS Open Class in Munich/Germany

Hello,

this is a reminder for all of you interested: 

An open class is scheduled to start at June 21, 2005 in Munich, 
Germany. 

The open class gives you 4 days filled with up-to-date know how 
on RTEMS BSP and driver development aswell as the Classic and 
POSIX APIs. 

Once again, Joel Sherrill will be the trainer for this class. So 
this training will ensure knowledge transfer straight from the 
developers.

Please also read the official announcment at

   http://www.imd-systems.de/rtems_class_0506_en.html

and 

   http://www.rtems.com

Please send any requests to:

   training@...   

wkr,
Thomas Doerfler.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markku Puro | 9 Apr 2005 15:49

Software FP in RTEMS 4.7 ARM prebuild tools?

Hi Joel,

Is software FP supported in ARM RTEMS 4.7 toolset?

I tried to compile gba BSP with rtems-4.7-arm-rtems4.7-gcc-gcc3.4.0newlib1.12.0-1.i686.rpm
and rtems-4.7-arm-rtems4.7-gcc-gcc3.3.5newlib1.12.0-2.i686.rpm.
-------
make[5]: Entering directory `/usr/tools/build_rtems_gba/arm-rtems4.7/c/gba/testsuites/samples/hello'
arm-rtems4.7-gcc --pipe -B../../../../../lib/ -B../../../../../gba/lib/ -specs
bsp_specs -qrtems -mcpu=arm7tdmi -msoft-float -mstructure-size-boundary=8 -O3    -Wall  -static
-Wl,-Map,o-optimize/hello.map -o
o-optimize/hello.obj o-optimize/init.o ../../../../../gba/lib/no-dpmem.rel ../../../../../gba/lib/no-event.rel
../../../../../gba/lib/no-msg.rel ../../../../../gba/lib/no-mp.rel ../../../../../gba/lib/no-part.rel
../../../../../gba/lib/no-signal.rel ../../../../../gba/lib/no-timer.rel ../../../../../gba/lib/no-rtmon.rel
/opt/rtems-4.7/lib/gcc/arm-rtems4.7/3.4.0/../../../../arm-rtems4.7/bin/ld: ERROR:
/opt/rtems-4.7/lib/gcc/arm-rtems4.7/3.4.0/crtbegin.o uses hardware FP, whereas
o-optimize/hello.obj uses software FP
Success: failed to merge target specific data of file /opt/rtems-4.7/lib/gcc/arm-rtems4.7/3.4.0/crtbegin.o
/opt/rtems-4.7/lib/gcc/arm-rtems4.7/3.4.0/../../../../arm-rtems4.7/bin/ld: ERROR:
/opt/rtems-4.7/lib/gcc/arm-rtems4.7/3.4.0/../../../../arm-rtems4.7/lib/libc.a(ctype_.o)
uses hardware FP, whereas
o-optimize/hello.obj uses software FP
------

Older toolsets have separated hardware FP libraries.
Latest tools seems to use hardware FP libraries by default but there isnt any soft-float libs?

 -Mp

--8<--------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
g_YaneV | 9 Apr 2005 17:16

rtems on m5282lite

  Hello,

 I have m5282LITE bord and I run successfully uclinux on it. But I need a real 
time OS so I look in to rtems. In the CVS there is port to uCdimm board whit 
the same processor(uC5282). I modify   
c/src/lib/libbsp/m68k/uC5282/startup/linkcmds to correct the difference in 
RAM/FLASH base and size, and the value of _DownloadLocation to match my 
board. I set the UART speed to be 19200, and compile. I don't find any ather 
difference between uC5282 and m5282LITE. 
 But when I transfer any of the samples in my board RAM and execute them they 
all start but after a short time  the board hang. I modify hello_world to be 
a simple  loop from 1 to 1000 and each time to print the counter of the loop. 
Each time i run this program it hang on different place(from 5-th to 50-th 
printed messages).
 Where the problem can be? Can someone gave me any advice.

Regards,
Georgi
Permalink | Reply | 1 comment |
headers
Eric Norum | 9 Apr 2005 19:27
Favicon

Re: rtems on m5282lite


On Apr 9, 2005, at 10:16 AM, g_YaneV wrote:

>   Hello,
>
>
>  I have m5282LITE bord and I run successfully uclinux on it. But I 
> need a real
> time OS so I look in to rtems. In the CVS there is port to uCdimm 
> board whit
> the same processor(uC5282). I modify
> c/src/lib/libbsp/m68k/uC5282/startup/linkcmds to correct the 
> difference in
> RAM/FLASH base and size, and the value of _DownloadLocation to match my
> board. I set the UART speed to be 19200, and compile. I don't find any 
> ather
> difference between uC5282 and m5282LITE.
>  But when I transfer any of the samples in my board RAM and execute 
> them they
> all start but after a short time  the board hang. I modify hello_world 
> to be
> a simple  loop from 1 to 1000 and each time to print the counter of 
> the loop.
> Each time i run this program it hang on different place(from 5-th to 
> 50-th
> printed messages).
>  Where the problem can be? Can someone gave me any advice.

Watchdog timer problems?  The RTEMS BSP doesn't include a 'watchdog' 
feeder.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Smith, Gene SEA | 13 Apr 2005 02:07
Picon

Socket calls from timer functions (server based)

If I try to make a socket call, e.g., setsockopt, from inside the server
based timer action function it fails in _CORE_mutex_Seize apparently
because dispatching is disabled in _Timer_Server_body (file
timeserver.c). Is there anyway around this limitation or should I "don't
do that"?

My timer service routine (TSR), which does socket calls, is called right
after _Thread_Disable_dispatch() in _Timer_Server_body(). I was hoping
my TSR could do anything a normal task could do, i.e., networking calls.

Gene
Permalink | Reply | 3 comments |
headers
Chris Johns | 13 Apr 2005 03:58
Favicon

Re: Socket calls from timer functions (server based)

Smith, Gene SEA wrote:
>
> Is there anyway around this limitation or should I "don't do that"?
> 

I use the socket option to set the receive timeout and then have the 
reader thread which blocks in a read wake and perform the required task.

The wiki have doco on the socket receive timeouts:

  http://www.rtems.org/phpwiki/index.php/Receive%20Socket%20Timeout

--

-- 
  Chris Johns
Permalink | Reply | 0 comments |
headers
Ian Caddy | 13 Apr 2005 04:15
Picon
Picon

Re: Socket calls from timer functions (server based)

Hi Gene,

As far as I am aware, the TSRs run in the context of the timer interrupt 
service routine, which means you can only perform operations that are 
safe in interrupts.

Network functions are generally not safe to call from interrupts, as 
most network functions are blocking functions.

You will probably need to find another way to implement this, such as 
sending an event or message to a thread that can perform the setsockopt.

I hope this helps.

regards,

Ian Caddy
Goanna Technologies Pty Ltd

Smith, Gene SEA wrote:
> If I try to make a socket call, e.g., setsockopt, from inside the server
> based timer action function it fails in _CORE_mutex_Seize apparently
> because dispatching is disabled in _Timer_Server_body (file
> timeserver.c). Is there anyway around this limitation or should I "don't
> do that"?
> 
> My timer service routine (TSR), which does socket calls, is called right
> after _Thread_Disable_dispatch() in _Timer_Server_body(). I was hoping
> my TSR could do anything a normal task could do, i.e., networking calls.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Whitfield | 13 Apr 2005 04:58
Picon

Re: Socket calls from timer functions (server based)

Ian Caddy wrote:
> Hi Gene,
> 
> As far as I am aware, the TSRs run in the context of the timer interrupt 
> service routine, which means you can only perform operations that are 
> safe in interrupts.
> 
> Network functions are generally not safe to call from interrupts, as 
> most network functions are blocking functions.
> 
> You will probably need to find another way to implement this, such as 
> sending an event or message to a thread that can perform the setsockopt.
> 

 From the OP's email he is using server based timers
(not present in rtems 4.5).

In this case the timers run in the context of the timer server task.

As noted in OP: In the time server Thread dispatching is
disabled.

The previous advice is probably still the best idea, don't
call network functions from the context of a TSR. Generate
an event or message and call the network function from a
application task.

My reasoning for this is:

TSR's are still "special" functions, they are run
(Continue reading)

Permalink | Reply | 0 comments |
headers
g_YaneV | 14 Apr 2005 18:22

Re: rtems on m5282lite

 Hello,

 I Write a simple program (again based on hello world) that print out some 
registers status, and here is the output:
-------------------------------------
intc0
register  iprh= 0x0
register iprl = 0x0
register imrh = 0xFFFFFFFF
register imrl = 0xF7EF1F7E

intc1
register  iprh= 0x0
register iprl = 0x0
register imrh = 0xFFFFFFFF
register imrl = 0xFFFFFFFF

core watchdog
register wcr = 0x0000
register wmr = 0xFFFF
register wcntr = 0xFFFF
register wsr = 0x0000

wtm
register crsr= 0x80
register cwcr= 0x01
register lpicr = 0x00
register cwsr = 0x00
-----------------------------------
the watchdog's are disabled, and the interrupt sources are UART0-2, DTIN1,
(Continue reading)

Permalink | Reply | 0 comments |
headers
g_YaneV | 15 Apr 2005 15:01

Re: rtems on m5282lite

 Hello,

I find some new info about the issue with the hanging of my m5282lite board.

I set a breakpoint in _uhoh, and YES .... this is why my board hang. STOP      
#0x2700(which is the next instruction) will stop the CPU core with all 
interrupts disabled. Just from  curiosity I remove the assembler code that 
copy the vector table(so I run the program with vector table defined by dBUG) 
and all test programs now run correctly. What the problem can be?

 My dBUG session follows

regards
Georgi 

---------------------------------start-----------------------------------------
dBUG> dn -e p-0.3.nxe
Ethernet Address is 00:CF:52:82:CF:01
Downloading ELF 'p-0.3.nxe' from 10.10.10.4
Program Headers:
 Segment #0 (Vaddr: 00010000, Paddr: 00010000, Size: 0001D520)
Section Headers:
 Section 0 (Type: 00000000, Addr: 00000000, Size: 00000000)
 Section 1 (Type: 00000001, Addr: 00010000, Size: 0001A980)
 Section 2 (Type: 00000001, Addr: 0002A980, Size: 00000910)
 Section 3 (Type: 00000008, Addr: 0002B290, Size: 00002290)
 Section 4 (Type: 00000001, Addr: 00000000, Size: 0000121C)
 Section 5 (Type: 00000001, Addr: 00000000, Size: 00000700)
 Section 6 (Type: 00000001, Addr: 00000000, Size: 00000AA8)
 Section 7 (Type: 00000001, Addr: 00000000, Size: 0001876F)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane