Estou criando alguns slides para minha turma sobre como devemos documentar o hardware que estamos desenvolvendo.
Eu gostaria de listar os documentos que devemos fazer ao criar algum hardware. Eu me inspirei na documentação do software UML, que traz muitos tipos de documentos para quase todas as situações.
Pela minha experiência e pesquisa, muitos projetos têm apenas o esquema, o layout e a lista de materiais. Penso que também devemos adicionar informações sobre o motivo (requisitos) que nos levam a escolher um microcontrolador e não o outro. Há também algumas informações sobre o layout que simplesmente não escrevemos, como posição especial do componente que não deve ser alterada.
Dito isto:
- Como devemos documentar nosso hardware?
- Qual é o documento importante que você gostaria de ter se precisar fazer algumas melhorias / alterações em outro hardware que você nunca viu?
- Como organizar essas informações de maneira clara?
documentation
RMAAlmeida
fonte
fonte
Respostas:
Concordo plenamente com o seu terceiro parágrafo. Além das coisas óbvias, como esquemas, listas técnicas, etc., existem coisas menos tangíveis, como, por exemplo, por que você escolheu um componente específico e tão importante quanto, por que você não escolheu um componente talvez mais óbvio.
Agora, posso estar mostrando minha idade aqui, mas ainda gosto de usar um livro de registro de capa dura para registrar meus processos de pensamento e decisões de design - mesmo os errados. Se alguém no futuro tentar substituir um componente por um mais 'adequado' ou mover uma faixa no PCB, minhas anotações poderão dizer que eu já estive lá e queimei meus dedos (talvez literalmente!).
Eu sempre numero as páginas e permito algumas páginas na frente como um sumário. Você também pode documentar coisas como cálculos de dissipação de energia, tolerâncias, tempos etc. (esse hábito vem dos meus dias na indústria aeroespacial, onde era obrigatório manter um diário de bordo). É claro que você sempre pode colocar essas informações em um documento WP, mas eu vou ficar no papel!
As descrições de circuitos também podem ser apropriadas quando se trata de circuitos incomuns (especialmente analógicos). Eu os trataria como comentários de software para documentar qualquer circuito não óbvio ou funções de componentes. Esquemas, como o software, devem ser 'auto-documentados', na medida do possível, mas às vezes isso não é suficiente.
Uma alternativa mais atualizada, especialmente em um ambiente educacional, pode ser ter um site do projeto. Isso poderia ser organizado como uma coleção de blogs para cada disciplina - design de hardware, layout de placas de circuito impresso, software etc. A natureza do blog permitiria que os colaboradores mostrassem seu fluxo de pensamentos e documentassem o andamento do projeto, enquanto outras páginas poderiam ser mais formais (progresso Gráficos de Gantt, resultados de testes etc). Você pode até adicionar atas de reuniões e listas de ações. Os hiperlinks facilitam a referência cruzada e agora temos o MathJax, de modo que até as equações de design são fáceis de inserir.
fonte
Em nossa empresa, esperamos escrever documentos de descrição de design de hardware. Isso é bem direto: você explica no início o que o circuito deve fazer e depois entra em detalhes em cada seção. Todo valor de componente deve ser justificado de alguma forma: se você possui resistências pullup ou em série "padrão", elas devem ser mencionadas em uma nota no início (por exemplo, "pullups de 10 K e capacitores de desvio de 0,1 uF são usados, a menos que seja especificado de outra forma") , caso contrário, as opções para os valores dos componentes precisam ser explicadas. por exemplo, "Filtro RC de 4,7 K e 0,1 uF (tau = 0,47 ms) usado para limitar componentes de alta frequência" ou "multiplexador NLAS4051 usado para vazamentos baixos - este nó do circuito é sensível".
fonte