Re: Requirement Management tools

[Sebastian Huber]

On 11/03/2019 13:42, Jose Valdez wrote:

Concerning the Requirements Management Tool, do you would find useful that the 
tool selected for RTEMS SMP to be compatible with the ReqIf standard? What do 
you think?


An export to ReqIF would be useful I guess. I am not sure if we want to 
use it as an internal format, e.g to manage the requirements.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Requirement Management tools

[Jose Valdez]

Hello all,

I am José Valdez from EDISOFT.

I am working for the RTEMS SMP project which aims to pre-qualify RTEMS SMP for 
space missions.

I am investigating tools which may partially automate the software development 
process, i.e: Requirements Management, Design and Unit test tools and source 
code analysis and metrics tools.

Currently I have been investigating myself and also requested Sebastian Huber 
for some tools he knows. With this information I am building an excel sheet 
with the summarized information about the tools (not yet complete). Could you 
please help in this discussion, indicating, as far as you know:

è if do you know other open source Requirement Management Tools

è if do you know the tools provided and if they are/are not suitable for RTEMS 
SMP

è if do you remember any tool feature not listed in excel sheet, that is 
relevant or if do you know any feature not listed that may block its selection 
for RTEMS SMP

As far as I have currently discussed with Sebastian Huber, we have the 
following ideas:

è Tools which use databases are to be avoided

è Deprecated tools ("dead projects") are to be avoided

è Could be interesting to have a tool which can import/export ReqIf standard 
file

Looking forward for your suggestions

Best regards

José


requirement tools.xls
Description: requirement tools.xls
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Management tools

[Joel Sherrill]

On Mon, Mar 11, 2019 at 7:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 11/03/2019 13:42, Jose Valdez wrote:
> > Concerning the Requirements Management Tool, do you would find useful
> that the tool selected for RTEMS SMP to be compatible with the ReqIf
> standard? What do you think?
>
> An export to ReqIF would be useful I guess. I am not sure if we want to
> use it as an internal format, e.g to manage the requirements.
>

The commercial tool we have been looking at for a non-RTEMS project with
certification requirements can import a number of formats including ReqIF
and CVS.

My gut feeling is that if Doorstop is sufficient and this becomes an issue,
we can add a ReqIF exporter to it. Chris already mentioned to me privately
that adding a Rest output format to it would be desirable so we get the
Requirements documents in our native documentation format rather than in
just its own HTML reports.

In general, if we adopt Doorstop, we will find ourselves helping improve it
to suit our needs.

--joel


>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Management tools

[Joel Sherrill]

Thanks Jose.

I think we would like reports to be in Rest so we can use Sphinx and
include them with the RTEMS Documentation Suite. I doubt any of the tools
will meet this requirement.  I posted just before this that if we go with
Doorstop, I can see adding this capability.

I like the concept of managing supporting artifacts the same way the code
is. This means we want the files managed in git, able to be version
controlled and ideally diffed. This puts a negative factor on binary
formats. Binary formats also have a tendency to lock you into tools.

I assume we will want to be able to submit fixes. Make sure the tool is
really open source.  If I looked at the right repo, the eclipse.org ProR
source looks stagnant while a commercial product which appears to be open
source is active. I am unsure where recent changes go. Just be a bit
cynical.

I know it is premature but are there any thoughts yet on how to implement
fully traceable requirements? To source and then to tests?

--joel

On Mon, Mar 11, 2019 at 8:24 AM Jose Valdez  wrote:

> Hello all,
>
>
>
> I am José Valdez from EDISOFT.
>
>
>
> I am working for the RTEMS SMP project which aims to pre-qualify RTEMS SMP
> for space missions.
>
>
>
> I am investigating tools which may partially automate the software
> development process, i.e: Requirements Management, Design and Unit test
> tools and source code analysis and metrics tools.
>
>
>
> Currently I have been investigating myself and also requested Sebastian
> Huber for some tools he knows. With this information I am building an excel
> sheet with the summarized information about the tools (*not yet complete*).
> Could you please help in this discussion, indicating, as far as you know:
>
> è if do you know other open source Requirement Management Tools
>
> è if do you know the tools provided and if they are/are not suitable for
> RTEMS SMP
>
> è if do you remember any tool feature not listed in excel sheet, that is
> relevant or if do you know any feature not listed that may block its
> selection for RTEMS SMP
>
>
>
> As far as I have currently discussed with Sebastian Huber, we have the
> following ideas:
>
> è Tools which use databases are to be avoided
>
> è Deprecated tools (“dead projects”) are to be avoided
>
> è Could be interesting to have a tool which can import/export ReqIf
> standard file
>
>
>
> Looking forward for your suggestions
>
>
>
> Best regards
>
>
>
> José
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beagleboard BSP Framebuffer

[Gedare Bloom]

On Sun, Mar 10, 2019 at 7:31 PM Joel Sherrill  wrote:

> The MINIX license is BSD with advertising clause as I read it. That is
> less preferable to a 2-paragraph BSD license that you are likely to find in
> Freebase. Try there.
>
> The license is fine if you find nothing else. I assume Joel meant FreeBSD.

Study the framebuffers in i386 and raspberrypi code bases.


> It is usable in RTEMS though. We just try to avoid pushing the advertising
> requirement
>
>
>
> On Sun, Mar 10, 2019, 12:47 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 8, 2019, 12:35 AM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I was reading up and trying to figure out the steps to achieve this
>>> project. Here's
>>> what I came up with :
>>>
>>> 1. BBB uses TD19988 HDMI Framer, so the first step is to get an HDMI
>>> output,
>>> read EDID info and set the videomode according to the info. After some
>>> searching,
>>> I found a driver in minix that might be helpful. Is the minix license
>>> compatible?
>>> (
>>> https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/03ac74ede908465cc64c671bbd209e761dc765dc/LICENSE
>>> )
>>>
>>> 2. Set the values of structs from fb.h
>>> 3. Write the fb.c using the functions from framebuffer.h ( I'm taking
>>> the fb.c in raspberrypi
>>> as example and the bsp-howto as a reference text)
>>>
>>> The above list is just an outline and I intend to explore/understand it
>>> better and make a
>>> proposal out of it.
>>>
>>> Does this list make sense to you?
>>>
>>> What am I missing?
>>>
>>> I would really appreciate any remarks/comments or details you'd like to
>>> add, it will help me understand it better.
>>>
>>> ping :)
>>
>>>
>>> Thanks,
>>> --vijay
>>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doxygen Groups for cpukit

[Gedare Bloom]

On Fri, Mar 8, 2019 at 1:28 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 07/03/2019 21:57, Joel Sherrill wrote:
> > On Thu, Mar 7, 2019 at 2:55 PM Chris Johns  > > wrote:
> >
> > On 8/3/19 3:24 am, Sebastian Huber wrote:
> > > On 07/03/2019 15:19, Joel Sherrill wrote:
> > >> On Thu, Mar 7, 2019 at 7:19 AM Sebastian Huber
> > >>  > 
> > >>  > >> wrote:
> > >> For the shell, very little is really a public API. Most is
> > internal.
> > >> I suspect this applies in many places.
> > >
> > > You have rtems_shell_init() etc. functions for the public API.
> >
> > I was looking at this file today and it could benefit from
> > becoming just the
> > public interfaces.
> >
> >
> > Would Doxygen benefit in general from having two runs? One that is all
> > public
> > interfaces and another that is everything?
> >
>
> Some files contain API and internal stuff. With a top-level API group it
> is transparent to the user what is meant for direct use in applications.
> Also, I was told several times that the primary user facing
> documentation is docs.rtems.org and not Doxygen.
>
>
Yes, we have to date focused on Doxygen as a tool for RTEMS Development
itself.

Considering the quality of our manuals, I don't see that a DOxygen for
application development would be entirely useful.


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doxygen Groups for cpukit

[Joel Sherrill]

On Mon, Mar 11, 2019, 9:36 AM Gedare Bloom  wrote:

>
>
> On Fri, Mar 8, 2019 at 1:28 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 07/03/2019 21:57, Joel Sherrill wrote:
>> > On Thu, Mar 7, 2019 at 2:55 PM Chris Johns > > > wrote:
>> >
>> > On 8/3/19 3:24 am, Sebastian Huber wrote:
>> > > On 07/03/2019 15:19, Joel Sherrill wrote:
>> > >> On Thu, Mar 7, 2019 at 7:19 AM Sebastian Huber
>> > >> > > 
>> > >> > > >> wrote:
>> > >> For the shell, very little is really a public API. Most is
>> > internal.
>> > >> I suspect this applies in many places.
>> > >
>> > > You have rtems_shell_init() etc. functions for the public API.
>> >
>> > I was looking at this file today and it could benefit from
>> > becoming just the
>> > public interfaces.
>> >
>> >
>> > Would Doxygen benefit in general from having two runs? One that is all
>> > public
>> > interfaces and another that is everything?
>> >
>>
>> Some files contain API and internal stuff. With a top-level API group it
>> is transparent to the user what is meant for direct use in applications.
>> Also, I was told several times that the primary user facing
>> documentation is docs.rtems.org and not Doxygen.
>>
>>
> Yes, we have to date focused on Doxygen as a tool for RTEMS Development
> itself.
>
> Considering the quality of our manuals, I don't see that a DOxygen for
> application development would be entirely useful.
>

I wasn't suggesting that if I started this. I was just saying the groups
initially proposed had missing items in public and private

FWIW I think there are still a few POSIX header files in cpukit. Do we want
all to migrate to newlib? What's the rule if we don't?

>
>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doxygen Groups for cpukit

[Sebastian Huber]

On 11/03/2019 15:49, Joel Sherrill wrote:


FWIW I think there are still a few POSIX header files in cpukit. Do we 
want all to migrate to newlib? What's the rule if we don't?


I would move all POSIX header files to Newlib and try to share them with 
Cygwin. This exposes our header files to all packages supported by Cygwin.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Management tools

[Chris Johns]

Hi Jose,

Thank you for the email and the introduction. Welcome.

On 12/3/19 12:24 am, Jose Valdez wrote:
> Currently I have been investigating myself and also requested Sebastian Huber
> for some tools he knows. With this information I am building an excel sheet 
> with
> the summarized information about the tools (_not yet complete_).

I do not have direct access to Excel. Would it be possible for future posts to
please use a format like PDF? Everyone can be read that format and the posts age
better in the public mailing list archive.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update and Query regarding "mq_send: thread waiting: no preempt"

[Joel Sherrill]

This is now pushed. Thanks.

On Sat, Mar 2, 2019 at 11:16 AM Shashvat Jain 
wrote:

> Hello
> Attached with this is a patch which adds some missing test names in the
> /psxtmtests_plan.csv .
>
> the test case "mq_send: thread waiting: no preempt" should be made under a
> different test name or within psxtmmq01 ?
>
> thank you
> Regards
> Shashvat
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel