Le dimanche 11 juin 2006 à 02:12 +1200, josephhenryblack a écrit : > Pinouts > As soon as timothy provides the latest revG schematic, we could start > documenting something of the 672? pin outs. The hardware programmers > would appreciate a list of what goes where for when they stop with the > simulations and assign the pins for real. You´re speaking about revG schematic, but what about the revF, E,...and the current revB ? Any revH or I, J ? > As soon as the new BOM is listed, we want some list references and > details in the wiki, and this will help with the pin out list. Ok, but if the pin out list is tied to the revision of the schematic, the former has to be revised too (?)
> I think Jack may soon be looking for a piece of software that will > generate codes for Traversal or OGP documents. We need to have a way to > specify different documents like (apologies to Jack) as he described it > to me like government standards - they have unique numbers and > references. With our Official OGP documentation we will need to have a > pattern to differentiate between different types of documents - but we > want to prevent mistakes, so a piece of software would help so we don't > need to refresh our memory by going back and reading up on the docs to > work out what to call the page. I understand the need of some logics to manage and organize the documentation. But that involves to define a process. For example, there´s the revB of the schematic on the wiki, but where is the revA ? and what is the reason about the revB relatively to the revA ? (the latest thread about the spi prom controller is speaking about the schematic and pins) Maybe a "newsletter" only about the revisions would be useful and their content could appear on the wiki. Accordingly, as far as the pin out list is concerned, it could be linked to the relevant decision. That´s a process among some others upon which one can elaborate a soft which provides the decision number or reference. > > Also, since I don't really understand what's going on, I'm having a hard > > time > > discovering if and how I can contribute. > Thanks for the post and keep the questions coming. When someone is too > hesitant to ask, we are all missing out. You see something, you ask, and > we all learn. (and with all the different perspectives the newsletter > benefits<g>) Frankly, the wiki gives too much to read though it is clearly organized. But some quick guides would be helpful. A quick guide about OGD1 : a sketch of the board showing what is it involved (main compoments, the relation between them...) The same about all the domains of contribution (edition, compiling and collecting infos, software documentation...)around OGD Contribution about web sites should be apart, by this way one has a hardware domain of contribution, and a web site domain of contribution. Hence, everybody can quickly see where he or she can contribute. Briefly, when one has to handle several things of different purposes, one need a map, or some maps to show. Best luc > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
