gEDA-pt: Nomeclatura de componentes no gSchem

[Antonio <antonio@xxxxxxxxxxxxxxx>]

Cara! Responsa o site do rapaz, gostei o PDF sobre o PI. Mas o gato
confesso nÃo ter entendido. eheh

Sobre o documento, achei muito interessante, e se partir da Ãtica deste
documento eu concordo que temos um problema de tamanho de nome crescente
quase exponencial na biblioteca, e quantidade de componentes.

Realmente fazer o gSchem do gEDA ter subdiretÃrios de biblioteca e
sub-subdiretÃrios poderia ajudar, mas acho que nÃo resolve nada. E para
isso precisariamos um empenho por parte da galera do desenvolvimento,
temos que ser sinceros que estamos fazendo essa reforma por conta
prÃpria, temos que ter em mente que somos praticamente um fork do
projeto, sà no que diz respeito a biblioteca, mas somos. Um problema
sÃrio à que eles nÃo tem muito porque alterar o software para satisfazer
a necessidades apenas nossas. Mas podemos pedir e ver se somos
atendidos. AlÃm de que alguÃm daqui pode fazer o patch e enviar, que
provavelmente, se nÃo mudar nada para o projeto original, serà aceito.

Acho que temos que comeÃar pela nomeclatura, muita coisa parece depender
daÃ.

To comeÃando a acreditar que deixar o footprint para fora pode ser
interessante, principalmente depois de minhas experiÃncias em usar o
gattrib, pois com ele vocà pode editar todos os atributos dos
componentes de uma sà vez, na forma de uma planilha de cÃlculo.
O interessante à que ele nÃo faz isso com a netlist, nÃo, ele edita a
origem da informaÃÃo, alterando os atributos nos arquivos .sch.

Isto me faz pensar que inserir todos os componentes preocupado com
outros atributos mais direcionados ao funcionamento que o aspecto
mecÃnico pode ser melhor, e deixar para Ãltimo a simples inserÃÃo de
dados mecÃnicos.

Mas existem, como sempre, exceÃÃes. Por exemplo, para muitos integrados
à importante vocà evidenciar no nome do sÃmbolo e jà num atributo
footprint interno o seu encapsulamento, pois isso pode comprometer a
numeraÃÃo de pinos. O mesmo ocorre, de forma bem mais rara, com alguns
outros tipos de componentes com mais de 2 pinos.

Achei interessante o fato de eles comeÃarem com o footprint antes atà do
tipo do componente, tipo 0402-RES-... isso pode ser utilizado caso a
gente mantenha o footprint setado em biblioteca, separando os
componentes por estarem em ordem alfabÃtica.

Uma coisa improtante à que que temos uma excelente ferramenta de
pesquisa no gSchem, e isso nos leva diretamente a um componente ou grupo
deles se sabe-se as regras de nomeclatura. A questÃo à entÃo como montar
a nomeclatura para fazer melhor uso disso.

Como todos podem notar, estamos com alguns pontos a discutir aqui,
tambÃm gostaria de opiniÃes de todos.

--
Antonio

Em SÃb, 2005-07-09 Ãs 13:20 -0300, Xtian Xultz escreveu:
> Um dos usuarios do pcb criou um documento normatizando a nomenclatura
> de 
> fotprints para o pcb, como pode ser visto em http://www.luciani.org
> O documento dele ficou muito bom, principalmente porque se baseia numa
> norma 
> IPC aberta (eu nao sabia que ela estava aberta) o que tambem eh muito
> bom. 
> Porem, seguindo a norma, os nomes de footprints ficam enormes. E nao
> eh a toa, 
> ha um bom motivo para isso, quem le o documento e jah fez alguma placa
> sabe 
> que tudo aquilo eh de extrema importancia e nao tem escapatoria. 
> Eu levantei a questao que exponho abaixo e acabamos num mato sem
> cachorro, o 
> que eh terrivel.
> Afinal de contas, como gerenciar os footprints no gEDA?
> Atualmente (eu digo isso baseado no codigo que o gschem possui
> atualmente) 
> temos duas opcoes: a primeira, que eh o viemos fazendo ateh agora,
> criar um 
> simbolo para cada footprint com o atributo footprint= setado. A
> segunda, que 
> a biblioteca "oficial" do gEDA vem fazendo, eh criar os componentes de
> forma 
> generica, e o desenhista escreve o campo footprint.
> 
> Ambos tem serios problemas.
> 
> No primeiro caso, a biblioteca vai ficar inundada de componentes
> repetidos 
> cujo campo footprint vai diferir apenas, com nomes de componentes
> enormes, 
> cheios de codigos confusos. Encontrar um componente vai ser uma
> verdadeira 
> tortura. Eu nao consigo imaginar, por exemplo, quantos simbolos
> diferentes 
> para resistor teremos! 
> Uma solucao paliativa seria se o codigo permitisse uma estrutura mais 
> hierarquica da biblioteca (com pastas e sub-pastas) para termos a
> pasta dos 
> componentes discretos, e dentro dela ter a pasta de resistores, e
> talvez ateh 
> dentro desta ter a pasta de thru-hole e de SMD.... vai facilitar um
> pouco. 
> Somente um puco...
> 
> No segundo caso, tao torturante quanto ter que navegar num mar de
> simbolos eh 
> ter que saber (de cabeca, ou consultando alguma documentacao) como se
> escreve 
> o nome deste footprint deste simples resistor...
> 
> Com o codigo da maneira que estah, nao vejo solucao.
> 
> 
> Pensando num mundo perfeito:
> 
> Eu sou da opiniao que na etapa do desenho do diagrama, o projetista
> nao tem 
> que se preocupar com footprint algum. Isso eh problema de quem vai
> fazer o 
> layout da placa (eee, vamo enfiar porta logica e conector nesse
> diagrama e o 
> layoutista que se vire! :D ). 
> A ultima versao do OrCAD que usei era assim. Voce carregava a netlist
> e ele 
> perguntava "O componente R1 tem qual fooprint?" e era possivel navegar
> na 
> biblioteca de footprints ou cria uma nova. Depois ele perguntava "Voce
> quer 
> que os R*.* sejam todos com esse footprint? E com o proximo
> componente, ele 
> jah mostrava os footprints que jah foram escolhidos. 
> Eu acho que eh assim que tem que ser. Porem, soh me faz lembrar o
> refrao de 
> uma famosa musica do Camisa de Venus, que diz "Mas este caminho eh
> tao 
> comprido, todo mundo tah f*****". 
> 
> 
> Gostaria de ouvir mais opinioes...