<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 12:10 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 14/11/17 01:10, Joel Sherrill wrote:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Mon, Nov 13, 2017 at 8:26 AM, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brai<wbr>ns.de</a> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedd<wbr>ed-brains.de</a>>> wrote:<br>
<br>
On 13/11/17 15:20, Daniel Hellstrom wrote:<br>
<br>
Currently there are some documentation on the drivers provided<br>
with RCC. Where would the best place be for BSP specific<br>
device driver documentation in the RTEMS project?<br>
<br>
<br>
This is an open issue. My proposal is to move this to the CPU<br>
Supplement:<br>
<br>
<a href="https://lists.rtems.org/pipermail/devel/2017-October/019270.html" rel="noreferrer" target="_blank">https://lists.rtems.org/piperm<wbr>ail/devel/2017-October/019270.<wbr>html</a><br>
<<a href="https://lists.rtems.org/pipermail/devel/2017-October/019270.html" rel="noreferrer" target="_blank">https://lists.rtems.org/piper<wbr>mail/devel/2017-October/019270<wbr>.html</a>><br>
<br>
<br>
We need to have some document that incorporates what has historically<br>
in each BSP's wiki or READMEs. I don't think this is the CPU Supplement.<br>
</blockquote>
<br></span>
Ok, and what is "some document" from your point of view?</blockquote><div><br></div><div>Chris suggested that a Users Manual include sections on each BSP with</div><div>instructions on setting the hardware up, debugging, etc. It makes sense that</div><div>this is user facing information specific to a set of BSPs. So in the outline of</div><div>what Chris proposed it would either be in a SPARC > General or SPARC > LEON3</div><div>subsection.</div><div><br></div><div>Serious software project documentation falls into categories and we need</div><div>to honor those. There are internal design and development docs, process</div><div>and software engineering docs, and user facing documentation focused</div><div>on applications.</div><div><br></div><div>We have a "middle tier" of documentation where users are sometimes</div><div>developers. But it is probably best to ignore that because it often clouds</div><div>how we organize and approach things.</div><div><br></div><div>We don't need to mix categories of documentation. This is not what is</div><div>expected from the high criticality standards.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brain<wbr>s.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</div></div></blockquote></div><br></div></div>