Hello,
is this 32KiB for code and data?
You should also disable the Newlib reentrancy:
#define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
Try to add:
CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
LDFLAGS = -Wl,--gc-sections
to the *.cfg file of the BSP. You need a proper linker command
Thanks for you answer. I will try to implement this.
On Thursday 18 of December 2014 08:20:44 Sebastian Huber wrote:
> Hello Олег Мороз,
>
> this duplicates code of the standard report function. I would instead
> do the following:
>
> 1. Add an argument to the visitor function in
> rtems_iterat
On 17/12/14 16:26, Gedare Bloom wrote:
This also changes the synchronization of the MRSP_Rival::status to use
interrupt critical section for writing instead of atomic operations. I
guess it is ok?
Yes, this is ok, since this code section uses the Giant lock. There are
also comments in MRSP_R
Hello Олег Мороз,
this duplicates code of the standard report function. I would instead
do the following:
1. Add an argument to the visitor function in
rtems_iterate_over_all_threads() and rename this function to
rtems_task_iterate().
2. Use rtems_task_iterate() to implement the previous
Sorry, my bad. Briefly description. The patch adding possibility to retrieve
CPU usage data as array of typed structs when you have no stdout devices or
you need to telemetry this data from you spacecraft or from aircraft or from
some other embedded device.
On Wednesday 17 of December 2014 17:43
Hi,
I have just pushed some configuration files to rtems-tools.git so you
can printk trace malloc, calloc, realloc, and free. We have been chasing
down an allocation bug and I thought it would be interesting to see what
happens with the RTEMS trace linker. The updated rtems-tools repo and
thi
But that test doesn't use c++ nor use exceptions, but you will see this
problem if you do a objdump over the binaries.
On Wed, Dec 17, 2014 at 2:47 PM, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
>
> Maybe it's worth to mention the 20k or so EH-related buffers?
> I think they go a
Maybe it's worth to mention the 20k or so EH-related buffers?
I think they go away when building the STL without EH and RTTI support,
right?
On Wed, Dec 17, 2014 at 2:44 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:
>
> That particular test I could see it uses like four tasks. The p
That particular test I could see it uses like four tasks. The problem we
had in the past is that the predefined size for the stack for each task was
set to 4k for our architecture (arm cortex m3). We proposed a patch in
order to make the default stack size for each bsp configurable. Im not sure
if
We were able to downsize RTEMS to about 9k for the LPC1768.
Marcos, could you give a hint?
On Wed, Dec 17, 2014 at 1:34 PM, Joel Sherrill
wrote:
>
>
>
> On December 17, 2014 8:00:50 AM PST, Hesham Moustafa <
> heshamelmat...@gmail.com> wrote:
> >Hi all,
> >
> >I am working on reducing RTEMS size
On December 17, 2014 8:00:50 AM PST, Hesham Moustafa
wrote:
>Hi all,
>
>I am working on reducing RTEMS size to fit into <32KB as every Epiphay
>core has only 32KB of local memory. I was able to get hello and
>minimum samples with aggressive size reduction by manually removing
>un-needed code. C
Hi all,
I am working on reducing RTEMS size to fit into <32KB as every Epiphay
core has only 32KB of local memory. I was able to get hello and
minimum samples with aggressive size reduction by manually removing
un-needed code. Currently I only use libcsupport, sapi, score, rtems
built for cpukit o
This also changes the synchronization of the MRSP_Rival::status to use
interrupt critical section for writing instead of atomic operations. I
guess it is ok?
-Gedare
On Wed, Dec 17, 2014 at 10:14 AM, Sebastian Huber
wrote:
> The previous timeout handling was flawed. In case a waiting thread
> h
The previous timeout handling was flawed. In case a waiting thread
helped out the owner could use the scheduler node indefinitely long.
Update the resource tree in _MRSP_Timeout() to avoid this issue.
Bug reported by Luca Bonato.
---
cpukit/score/include/rtems/score/mrsp.h | 35 ++--
cp
>From 3918fcb958e14e0d325901f90538f31c8cda940a Mon Sep 17 00:00:00 2001
From: "Moroz.Oleg"
Date: Wed, 17 Dec 2014 17:26:19 +0300
Subject: [PATCH 2/2] Adding CPU usage statistic get for usage in user code
---
cpukit/libmisc/cpuuse/cpuusagereport.c | 115 +
cpukit/
On December 17, 2014 3:43:59 AM CST, Sebastian Huber
wrote:
>
>On 17/12/14 09:55, Daniel Krüger wrote:
>> I am porting the openPOWERLINK stack (Industrial Ethernet protocol
>> implementation) to RTEMS. Because RTEMS includes the POSIX layer, I
>> tried to reuse most of the Linux implementatio
Hello,
I added some very simple benchmark code here:
https://github.com/sebhub/rb-bench
On 06/11/14 07:53, Sebastian Huber wrote:
Hello,
I have a new item for the list:
Very desirable
==
+ Since red-black trees are now used to implement the priority queues
and they will play an
On 17/12/14 09:55, Daniel Krüger wrote:
I am porting the openPOWERLINK stack (Industrial Ethernet protocol
implementation) to RTEMS. Because RTEMS includes the POSIX layer, I
tried to reuse most of the Linux implementation of openPOWERLINK.
When it came to the timers, I discovered some differen
Hello,
I am porting the openPOWERLINK stack (Industrial Ethernet protocol
implementation) to RTEMS. Because RTEMS includes the POSIX layer, I
tried to reuse most of the Linux implementation of openPOWERLINK.
When it came to the timers, I discovered some differences of the POSIX
timer behaviour
19 matches
Mail list logo