posix function (read/write) unusual beavior

2014-07-21 Thread Gabriel Ibarra
Hi, I have a simple loopback program in my board (bsp lpc_176x), It reads information from a tty and returns it through the same tty (using POSIX functions), I tested it sending characters with a PC's terminal and I saw the ECHO on the terminal, I found an unusual behavior with some bsp configurati

capture engine use of workspace_allocate

2014-07-21 Thread Jennifer Averett
The capture engine currently uses a mixture of malloc and rtems_workspace_allocate. We don't think the workspace accounts for this, and would like to propose changing it so that malloc is used for all memory allocation. Does anyone see any reason this shouldn't be done? --jennifer __

Re: Zynq BSP

2014-07-21 Thread emanuel stiebler
On 2014-07-18 18:54, Chris Johns wrote: >> We still use the U-Boot to load it? > I do not use uboot, rather we have a taken the Xilinx FSBL and reworked it. Could you at least share this part? And thanks for this already, I thought that I had to use u-boot. (which I don't mind, it just one more

Re: posix function (read/write) unusual beavior

2014-07-21 Thread Sebastian Huber
On 07/21/2014 04:42 PM, Gabriel Ibarra wrote: In this example, when i press 0123456789 the output looks like: ]�\ B�\^0123456789 I said "with some configurations" because I found that if I define maximum devices to 4 (#define CONFIGURE_MAXIMUM_DEVICES 4) it works well, but with #define CONFI

Re: capture engine use of workspace_allocate

2014-07-21 Thread Gedare Bloom
Either account for it in workspace sizing or use malloc. On principle, I guess any dynamic allocated memory that isn't mandatory to get RTEMS to work should come from malloc. -Gedare On Mon, Jul 21, 2014 at 10:41 AM, Jennifer Averett < jennifer.aver...@oarcorp.com> wrote: > The capture engine c

Re: capture engine use of workspace_allocate

2014-07-21 Thread Joel Sherrill
On July 21, 2014 10:44:15 AM CDT, Gedare Bloom wrote: >Either account for it in workspace sizing or use malloc. > >On principle, I guess any dynamic allocated memory that isn't mandatory >to get RTEMS to work should come from malloc. With one malloc and two workspace allocates, I assumed we sho

[PATCH 3/3] rbtree: Do not set node off-tree in extract

2014-07-21 Thread Sebastian Huber
--- cpukit/score/include/rtems/score/rbtree.h | 11 +-- cpukit/score/src/rbtreeextract.c | 3 --- testsuites/sptests/sprbtree01/init.c | 5 + 3 files changed, 14 insertions(+), 5 deletions(-) diff --git a/cpukit/score/include/rtems/score/rbtree.h b/cpukit/score/includ

[PATCH 2/3] rbtree: Remove superfluous NULL pointer checks

2014-07-21 Thread Sebastian Huber
--- cpukit/score/include/rtems/score/rbtree.h | 7 +++ cpukit/score/src/rbtree.c | 3 --- cpukit/score/src/rbtreeextract.c | 10 -- cpukit/score/src/rbtreeinsert.c | 3 --- testsuites/sptests/sprbtree01/init.c | 3 --- 5 files changed, 3 inse

[PATCH 1/3] rbtree: Format

2014-07-21 Thread Sebastian Huber
--- cpukit/score/src/rbtree.c| 7 +- cpukit/score/src/rbtreeextract.c | 152 +-- cpukit/score/src/rbtreefind.c| 7 +- cpukit/score/src/rbtreeinsert.c | 69 ++ cpukit/score/src/rbtreeiterate.c | 12 ++-- cpukit/score/src/rbtreen

Re: [PATCH 1/3] rbtree: Format

2014-07-21 Thread Joel Sherrill
There could be something wrong here but I don't see it on a quick review. On 7/21/2014 11:31 AM, Sebastian Huber wrote: > --- > cpukit/score/src/rbtree.c| 7 +- > cpukit/score/src/rbtreeextract.c | 152 > +-- > cpukit/score/src/rbtreefind.c| 7 +

Re: [PATCH 2/3] rbtree: Remove superfluous NULL pointer checks

2014-07-21 Thread Joel Sherrill
One comment inline. On 7/21/2014 11:31 AM, Sebastian Huber wrote: > --- > cpukit/score/include/rtems/score/rbtree.h | 7 +++ > cpukit/score/src/rbtree.c | 3 --- > cpukit/score/src/rbtreeextract.c | 10 -- > cpukit/score/src/rbtreeinsert.c | 3 ---

Re: [PATCH 3/3] rbtree: Do not set node off-tree in extract

2014-07-21 Thread Joel Sherrill
Unless the chain has changed to have the property of "dangerous to extract if not on", this should be OK. My thinking is that higher level code would be checking a state of some sort and know whether to extract from the underlying chain or rbtree container. Is this true? If so, this looks OK. O

Re: [PATCH 2/3] rbtree: Remove superfluous NULL pointer checks

2014-07-21 Thread Sebastian Huber
On 07/21/2014 06:59 PM, Joel Sherrill wrote: -/** @brief Extract a Node (unprotected) >- * >- * This routine extracts (removes) @a the_node from @a the_rbtree. >- * >- * @note It does NOT disable interrupts to ensure the atomicity >- *of the extract operation. >- */ Is it assumed that

Re: [PATCH 3/3] rbtree: Do not set node off-tree in extract

2014-07-21 Thread Sebastian Huber
On 07/21/2014 07:23 PM, Joel Sherrill wrote: Unless the chain has changed to have the property of "dangerous to extract if not on", this should be OK. My thinking is that higher level code would be checking a state of some sort and know whether to extract from the underlying chain or rbtree cont

Re: [PATCH 2/3] rbtree: Remove superfluous NULL pointer checks

2014-07-21 Thread Joel Sherrill
On 7/21/2014 12:52 PM, Sebastian Huber wrote: > On 07/21/2014 06:59 PM, Joel Sherrill wrote: >>> -/** @brief Extract a Node (unprotected) - * - * This routine extracts (removes) @a the_node from @a the_rbtree. - * - * @note It does NOT disable interrupts to ensure the atomici

Re: [PATCH 3/3] rbtree: Do not set node off-tree in extract

2014-07-21 Thread Joel Sherrill
On 7/21/2014 12:54 PM, Sebastian Huber wrote: > On 07/21/2014 07:23 PM, Joel Sherrill wrote: >> Unless the chain has changed to have the property of >> "dangerous to extract if not on", this should be OK. >> >> My thinking is that higher level code would be checking a state >> of some sort and kno

[PATCH v2] RTEMS: Add multilibs for ARM

2014-07-21 Thread Sebastian Huber
This change is necessary to support Cortex-M4 and Cortex-R based chips in RTEMS. This patch should be applied to GCC 4.8, 4.9 and mainline. I do not have write access, so in case this gets approved, please commit it for me. gcc/ChangeLog 2014-07-21 Sebastian Huber * config/arm/t-rtem

Re: [PATCH 1/3] rbtree: Format

2014-07-21 Thread Gedare Bloom
One issue with rbtree formatting is in some places if/while conditional expressions are put on the same line as the conditional statement. We should prefer to put them explicitly on separate lines, since that is the prevailing style of score and I have added such a convention to our style wiki page