Re: Requirement Document generator tool

- Am 29. Jan 2020 um 23:48 schrieb Chris Johns chr...@rtems.org: > On 29/1/20 7:40 pm, Christian Mauderer wrote: >> On 28/01/2020 23:15, Chris Johns wrote: >>> On 28/1/20 10:22 pm, Christian Mauderer wrote: [...] >> If I understood you correctly your main problem with both suggested ones >> (P

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

- Am 3. Feb 2020 um 7:12 schrieb Chris Johns chr...@rtems.org: > On 3/2/20 4:21 pm, Sebastian Huber wrote: >> - Am 3. Feb 2020 um 1:14 schrieb Chris Johns chr...@rtems.org: >> >>> On 2/2/20 1:28 am, Sebastian Huber wrote: - Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems

Re: [PATCH v2 00/10] Rework work area initialization

- Am 3. Feb 2020 um 7:10 schrieb Chris Johns chr...@rtems.org: > On 3/2/20 4:27 pm, Sebastian Huber wrote: >> - Am 3. Feb 2020 um 0:01 schrieb Chris Johns chr...@rtems.org: >> >>> On 3/2/20 12:28 am, Sebastian Huber wrote: [...] >>> I am not sure what the "demand" is and where it is c

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

On 3/2/20 4:21 pm, Sebastian Huber wrote: > - Am 3. Feb 2020 um 1:14 schrieb Chris Johns chr...@rtems.org: > >> On 2/2/20 1:28 am, Sebastian Huber wrote: >>> - Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems.org: >>> On 17/12/19 4:57 pm, Sebastian Huber wrote: > My experi

Re: [PATCH v2 00/10] Rework work area initialization

On 3/2/20 4:27 pm, Sebastian Huber wrote: > - Am 3. Feb 2020 um 0:01 schrieb Chris Johns chr...@rtems.org: > >> On 3/2/20 12:28 am, Sebastian Huber wrote: >>> This change set reworks the work area initialization carried out by the >>> BSPs to >>> initialize the workspace and C program heap on

Re: V5.x porting guide or prototypical example?

Hello Andrei, - Am 3. Feb 2020 um 4:14 schrieb gro...@chichak.ca: > \Good day, > > A while back I put together a BSP for STM32F7 based on the STM32F407 BSP for > an > early version of RTEMS 5. > > Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a bit > and > I need

Re: [PATCH v2 00/10] Rework work area initialization

- Am 3. Feb 2020 um 0:01 schrieb Chris Johns chr...@rtems.org: > On 3/2/20 12:28 am, Sebastian Huber wrote: >> This change set reworks the work area initialization carried out by the BSPs >> to >> initialize the workspace and C program heap only on demand, e.g. in case >> these >> components

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

- Am 3. Feb 2020 um 1:14 schrieb Chris Johns chr...@rtems.org: > On 2/2/20 1:28 am, Sebastian Huber wrote: >> - Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems.org: >> >>> On 17/12/19 4:57 pm, Sebastian Huber wrote: My experience tells me that doing a BSP development without

V5.x porting guide or prototypical example?

\Good day, A while back I put together a BSP for STM32F7 based on the STM32F407 BSP for an early version of RTEMS 5. Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a bit and I need to redo my BSP. Is there a porting guide for 5.0 yet, or is there a shining example of a B

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

On 2/2/20 1:28 am, Sebastian Huber wrote: > - Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems.org: > >> On 17/12/19 4:57 pm, Sebastian Huber wrote: >>> My experience tells me that doing a BSP development without a debugger is a >>> waste of time. >> >> Sometimes getting a working debu

Re: [PATCH] score: Optimize STATUS_BUILD()

On 2/2/20 1:07 am, Sebastian Huber wrote: The patch is being attached. Can they please be inlined? Chrid ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 00/10] Rework work area initialization

On 3/2/20 12:28 am, Sebastian Huber wrote: > This change set reworks the work area initialization carried out by the BSPs > to > initialize the workspace and C program heap only on demand, e.g. in case these > components are used by the application. > > Currently, the workspace is always used, ho

Re: Requirement Document generator tool

On 3/2/20 4:19 am, Christian Mauderer wrote: > like discussed: A ticket for it: https://devel.rtems.org/ticket/3860 > Please take a look at it. Feel free to add something if I missed it. Thank you. I have added a possible hurdle, defining how we test each change as the tool is introduced. Chris _

Re: About Beaglebone Black device tree

On Sun, Feb 2, 2020 at 9:49 PM Christian Mauderer wrote: > > On 31/01/2020 17:43, Vijay Kumar Banerjee wrote: > > > > > > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer > > wrote: > > > > On 31/01/2020 17:25, Christian Mauderer wrote: > > > On 31/01/2020 16

Re: Requirement Document generator tool

On 31/01/2020 19:44, Gedare Bloom wrote: But I think implementing that would be a lot bigger task than the one we are just discussing. One of the first problems would be finding a style checker that can produce _exactly_ the coding style that is defined for score. >>> Agreed. >>

Re: About Beaglebone Black device tree

On 31/01/2020 17:43, Vijay Kumar Banerjee wrote: > > > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer > wrote: > > On 31/01/2020 17:25, Christian Mauderer wrote: > > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote: > >> Hi, > >> > >> While try

Re: [PATCH v2 00/10] Rework work area initialization

- Am 2. Feb 2020 um 16:17 schrieb Gedare Bloom ged...@rtems.org: > On Sun, Feb 2, 2020 at 6:28 AM Sebastian Huber > wrote: >> >> This change set reworks the work area initialization carried out by the BSPs >> to >> initialize the workspace and C program heap only on demand, e.g. in case >>

Re: [PATCH v2 00/10] Rework work area initialization

On Sun, Feb 2, 2020 at 6:28 AM Sebastian Huber wrote: > > This change set reworks the work area initialization carried out by the BSPs > to > initialize the workspace and C program heap only on demand, e.g. in case these > components are used by the application. > > Currently, the workspace is al

Re: [rtems-docs PATCH] user/testing: Add coverage analysis instructions

Thanks for the contribution. There are just a few small grammar errors and a typo. On Sat, Feb 1, 2020 at 8:30 AM Vijay Kumar Banerjee wrote: > > --- > user/testing/coverage.rst | 68 +++ > user/testing/index.rst| 1 + > 2 files changed, 69 insertions(+)

Re: GSOC: Adding FDT infrastructure to RTEMS

- Am 2. Feb 2020 um 12:10 schrieb Niteesh gsnb...@gmail.com: > On Sun, Feb 2, 2020 at 2:55 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello Niteesh, >> >> I am not in favour of a home grown solution. We should not re-invent the >> wheel. Working with device trees m

Re: GSOC: Adding FDT infrastructure to RTEMS

On Sun, Feb 2, 2020 at 2:55 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Niteesh, > > I am not in favour of a home grown solution. We should not re-invent the > wheel. Working with device trees may appear to be simple, however, this > could end up in a multi-person-month

Re: GSOC: Adding FDT infrastructure to RTEMS

Hello Niteesh, I am not in favour of a home grown solution. We should not re-invent the wheel. Working with device trees may appear to be simple, however, this could end up in a multi-person-month project easily. There are several existing solutions for device drivers based on device trees. Wha