On Tue, Nov 14, 2017 at 12:10 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> > > On 14/11/17 01:10, Joel Sherrill wrote: > >> >> >> On Mon, Nov 13, 2017 at 8:26 AM, Sebastian Huber < >> sebastian.hu...@embedded-brains.de <mailto:sebastian.huber@embedd >> ed-brains.de>> wrote: >> >> On 13/11/17 15:20, Daniel Hellstrom wrote: >> >> Currently there are some documentation on the drivers provided >> with RCC. Where would the best place be for BSP specific >> device driver documentation in the RTEMS project? >> >> >> This is an open issue. My proposal is to move this to the CPU >> Supplement: >> >> https://lists.rtems.org/pipermail/devel/2017-October/019270.html >> <https://lists.rtems.org/pipermail/devel/2017-October/019270.html> >> >> >> We need to have some document that incorporates what has historically >> in each BSP's wiki or READMEs. I don't think this is the CPU Supplement. >> > > Ok, and what is "some document" from your point of view? Chris suggested that a Users Manual include sections on each BSP with instructions on setting the hardware up, debugging, etc. It makes sense that this is user facing information specific to a set of BSPs. So in the outline of what Chris proposed it would either be in a SPARC > General or SPARC > LEON3 subsection. Serious software project documentation falls into categories and we need to honor those. There are internal design and development docs, process and software engineering docs, and user facing documentation focused on applications. We have a "middle tier" of documentation where users are sometimes developers. But it is probably best to ignore that because it often clouds how we organize and approach things. We don't need to mix categories of documentation. This is not what is expected from the high criticality standards. > > > -- > 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