Am 12.10.2017 um 19:42 schrieb Chris Johns:
> On 12/10/17 9:36 am, Christian Mauderer wrote:
>> Am 12.10.2017 um 18:06 schrieb Chris Johns:
>>> On 12/10/17 12:00 am, Sebastian Huber wrote:
@@ -4,7 +4,6 @@ RTEMS_CPU = arm
CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-
On 12/10/17 16:24, Chris Johns wrote:
On 11/10/17 11:30 pm, Sebastian Huber wrote:
milestones 4.13 and 5.0 don't fit the new version scheme:
https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tick
On 12/10/17 20:45, Joel Sherrill wrote:
- RTEMS_PROXY_BLOCKING = 28
+ RTEMS_PROXY_BLOCKING = 29
I would not change existing status code values.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax
Update #3182.
---
testsuites/psxtests/Makefile.am| 1 +
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxclockrealtime01/Makefile.am | 19 ++
testsuites/psxtests/psxclockrealtime01/init.c | 304 +
.../psxclockrealtim
Hi
For RTEMS to participate in Google Code-In, we will need mentors. Being a
GCI
mentor is different from being a GSoC or SOCIS mentor. The tasks are not
large
like the summer projects in those programs. They are small tasks which any
RTEMS user or developer (including GSoC students) can provide
Yes the physical state can vary depending on the configuration of the RFS.
But that is not my point here.
Let's see an example:
Assuming
- set = physical 1, so RTEMS_RFS_BITMAP_ELEMENT_SET = UINT32_MAX
- map[index]=0b
1110
On 12/10/17 11:46 am, Fan Deng wrote:
> Thanks Chris!
>
> First of all let's make sure a few points are clarified:
>
> 1) What should rtems_rfs_bitmap_map_set(control, bit) do?
> - 'control' is a handle to the bitmap.
> - 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in the
Thanks Chris!
First of all let's make sure a few points are clarified:
1) What should rtems_rfs_bitmap_map_set(control, bit) do?
- 'control' is a handle to the bitmap.
- 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in
the range of [0, control->size - 1].
2) How does the b
This impacts rtems_task_mode() and rtems_task_create().
Closes #3000.
---
c-user/directive_status_codes.rst | 4
c-user/task_manager.rst | 8
2 files changed, 12 insertions(+)
diff --git a/c-user/directive_status_codes.rst
b/c-user/directive_status_codes.rst
index 420a0a
This impacts rtems_task_mode() and rtems_task_create().
updates #3000.
---
c/src/ada/rtems.ads | 3 ++-
cpukit/rtems/include/rtems/rtems/status.h | 10 --
cpukit/rtems/src/statustext.c | 1 +
cpukit/rtems/src/taskcreate.c | 19 ++
On 12/10/17 9:36 am, Christian Mauderer wrote:
> Am 12.10.2017 um 18:06 schrieb Chris Johns:
>> On 12/10/17 12:00 am, Sebastian Huber wrote:
>>> @@ -4,7 +4,6 @@ RTEMS_CPU = arm
>>>
>>> CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
>>>
>>> -CFLAGS_OPTIMIZE_V = -O2 -g
>>>
On 12/10/17 10:05 am, Fan Deng wrote:
> Hi Chris,
>
Thanks for quick response.
> Based on my understanding, the patch in your email is different:
>
> 1) rtems_rfs_bitmap_map_set:
> By changing negating the if condition, the updated logic only modifies the
> element map[index] when the original
Hi Chris,
Based on my understanding, the patch in your email is different:
1) rtems_rfs_bitmap_map_set:
By changing negating the if condition, the updated logic only modifies the
element map[index] when the original value of map[index] is
RTEMS_RFS_BITMAP_ELEMENT_SET.
This is not quite right, as
Hi,
Many thanks for post the patches. The other patches look fine. I am wondering
is this is equivalent to what you have?
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index 15a9050133..d14082691a 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bit
Am 12.10.2017 um 18:06 schrieb Chris Johns:
> On 12/10/17 12:00 am, Sebastian Huber wrote:
>> Module:rtems
>> Branch:master
>> Commit:16fcd56a42dfdef514350ab6297137e2c863afa1
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1
>>
>> Author:
On 12/10/17 12:00 am, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:16fcd56a42dfdef514350ab6297137e2c863afa1
> Changeset:
> http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1
>
> Author:Christian Mauderer
> Date: Wed Oct 11 15:38:
On 11/10/17 11:30 pm, Sebastian Huber wrote:
>
> milestones 4.13 and 5.0 don't fit the new version scheme:
>
> https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
>
>
> I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tickets to 5.1.
>
A change t
Add wpa_supplicant lib support and shell command support in RTEMS.
---
builder.py | 1 +
freebsd/contrib/wpa/src/utils/os_unix.c| 11 +-
freebsd/contrib/wpa/wpa_supplicant/config.h| 3 +
freebsd/contrib/wpa/wpa_supplicant/main.c
Add fork command for wpa supplicant to start a new task.
---
freebsd/contrib/wpa/wpa_supplicant/main.c | 65 ++
libbsd.py | 1 +
libbsd_waf.py | 1 +
rtemsbsd/include/machine/rtems-bsd-comm
Add wpa supplicant command in media01.
---
testsuite/include/rtems/bsd/test/default-network-init.h | 3 ++-
testsuite/media01/test_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h
b/tes
20 matches
Mail list logo