On 2012-11-09 19:48, J.F wrote:
> Chyba kazdy rozsadny edytor ma generacje netlisty (jak nie ma, to nie
> jest rozsadny :-)

Ale nie o to chodzi aby porównywać netlisty. Chodzi o to aby:

a) pisać w języku schematów
b) kontrolwoać wersje na plikach źrodlowych
c) mieć możliwość odtworzenia schematu ze źródeł na żądanie

> Te juz mozesz jakos porownywac.
> Aczkolwiek ... zrodel takich problemow moze byc wiele - raczej bym sie
> skupil na programie do sprawdzania (ERC) czy symulacji.

To jest możliwe rownież kiedy zamist grafiki masz tekst.

> Owszem, ale wystarczy drobna nieuwaga i w kodzie zrodlowym sobie
> namieszasz.

Jaka nieuwaga? Taka sama jak narysowanie się kreski o długości 2px na
schemacie co spowodowalo położenie mi produkcji płytek? Chyba jednak
tekst lepiej kontrolować.

> Przy czym czasem latwiej zauwazyc brak linii na schemacie, niz jakas
> pomylke w jednej z dziesiatek tysiecy linii kodu ..

To jest dyskusyjne. Tym bardziej że jesteś w stanie mając takie pliki
przygotować sobie własne testy typu "czy wszystkie układy logiczne mają
zasilanie" albo "czy gdzieś przypadkiem nie podpięto dwóch wyjśc razem"
albo "ten tranzystor ma wiszącą bazę".

W zasadzie potrzebuje Verilog-AMS tylko bez symulacji. Powinien być
wystarczający do odtworzenia schematu.

do góry

W dniu 2012-11-09 15:44, Sebastian Biały pisze:
> Własnie wale głową w mur: jak sprawdzić jak zmieniła się wersja 16
> schematu względem 12 zakładając że pliki trzymam w systemie kontroli
> wersji? Pomijam w tej chwili oprogramowanie - po prostu mam poważną
> wątpliwość czy to w ogóle jest sensowne w przypadku schematów rysowanych.
>
> Jestem bardziej programistą, więc oczywiste wydaje mi się że "schemat"
> opisany w języku tekstowym byłby:
>
> a) mniej odporny na błedy dzieki stosowaniu jakiś wyższych abstrakcji
> ("magistrala adresowa 1, podepnij do pamięci U2").
> b) wygodny w przeglądaniu historii w systemach kontroli wersji
> c) możliwy do trywialnego podziału na zgrabne logiczne kawałki
> d) nieczytelny dla przecietnego elektronika, ale kij z nimi, niech sobie
> klika.
>
> Teraz: czy świat dorobił się jakiegoś języka pozwalającego rozsadnie
> opisać typowy schemat elektroniczny który:
>
> a) nie jest językiem *hdl bo nie potrzebuje opisywać działania bramek,
> interesuje mnie podpięcie drutow do pinów elementów elektronicznych. Nic
> nie przeszkadza, gdyby *hdl mógł byś wpięty w tle do symulacji.
> b) nie jest czytelny *tylko* dla maszyny, jak edif. Ma być read-write
> dla człowieka.
> c) potrafi okreslić opis na wyzszym poziomie niż pojedyncze druty.
> d) da się skonwertować na schemat (z autoroutingiem połączeń).
>
> Widział ktoś coś rownie nietypowego?
>
> Żeby uprzedzić krucjatę: jestem specyficznym człowiekiem. Uważam za
> wygodne rzeczy które inni nie byli by w stanie używać nawet pod
> przymusem. Liczę jednak że nie jedynym.
>
> Tak sobie wymysliłem w 10 sekund przykład ze składnią wyssaną z palca:
>
> module counter( input wire clock, output vector result[4] )
> {
>
> U2 : CD4093;
> U1 : CD4001;
> R2 : Resistor( 10Ohm, 1W );
>
> U2.gate1.out connect U1.gate2.in1;
> U1.gate2.out connect U2.gate1.in2;
> U1.gate2.in2 connect clock;
> U2.gate3.out connect result[2];
> R2.pin1 connect result[3];
> ...
> U2.vcc connect global.vcc;
> ...
>
> }
>
> Przypomina to języki *hdl, ale tutaj mogę podpinać elementy również
> analogowe. Czy ktoś widział gdzies coś podobnego, nawet bardzo odlegle w
> składni?




Protel pokazuje zmiany podczas importu np do PCB. Chyba słowny opis
powinien wystarczyc to i tak tylko dla twojej wiadomosci .

do góry

W dniu 09.11.2012 16:29, Sebastian Biały pisze:
> On 2012-11-09 15:58, Zbych wrote:
>> Przy analizowaniu schematu nie jest mi wszystko jedno gdzie są elementy
>> i którędy idą druty je łączące.
>
> Mi jest wszystko jedno o ile elementy są zgrupowane blokami. To jest
> przetwornica, to jest system procesorowy, to jest radio itd. To czy
> druty idą dolem, górą nie ma znaczenia. De facto na moich schematach nie
> ma w ogole drutów - każdy pin ma nazwę neta i koniec.

W przypadku dużych elementów (procesory, pamięci itp.) zgoda. Ale przy
układach tranzystorowych i innej drobnicy opis tekstowy będzie
upierdliwy i pewnie będzie wymagał wcześniejszego narysowania na kartce
i dopiero ręcznego wygenerowania twojej netlisty.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:k7jlg7$m0u$1@node2.news.atman.pl...
>
>> Przy czym czasem latwiej zauwazyc brak linii na schemacie, niz jakas
>> pomylke w jednej z dziesiatek tysiecy linii kodu ..
>
> To jest dyskusyjne. Tym bardziej że jesteś w stanie mając takie pliki
> przygotować sobie własne testy typu "czy wszystkie układy logiczne mają
> zasilanie" albo "czy gdzieś przypadkiem nie podpięto dwóch wyjśc razem"
> albo "ten tranzystor ma wiszącą bazę".
>

Używam bardzo starego Protela 3. Nigdy nie uruchamiałem error-check dla
schematu - nie miałem takiej potrzeby. Teraz zajrzałem do tej funkcji.
Definiuje się w tabelce (jak tabliczka mnożenia 17 kolumn x 17 wierszy)
łączenie czego z czym (lub brak połączenia) jest OK, daje ostrzeżenie, daje
Error. Plus jeszcze trochę flag opcji.
Z tego wynika, że zapis tekstowy nie jest niezbędny do tego typu sprawdzeń.

Napisałeś gdzieś, że Twoje schematy w zasadzie to osobne elementy z
poopisywanymi nazwami netów.
Właśnie mam zrobić schemat zawierający Wiznet W5200.
Dostaję białej gorączki jak widzę ich kartę katalogową z której nie wynika
jak ten scalak połączyć (czy wyjścia LEDów są push-pull, czy OC, piszą "Be
sure to connect tantalum capacitor ...." a na wyrywkowym schemacie (bo w
karcie nie ma normalnego schematu aplikacji scalaka) jest zwykły, a gdzie
indziej piszą: "Connect a capacitor of 10.1uF to the ground." - dla mnie
rewelacja. No skąd mam wiedzieć, czy jak podłączę ceramika do wewnętrznego
stabilizatora 1V8 to ten stabilizator będzie stabilny, czy się wzbudzi
(skoro tekst sobie, a schemat sobie). No i w ogóle nie wiadomo do jakiego
napięcia podłączyć środki transformatorów bo przecież obwody wyjściowe i
wejściowe da się różnie zrobić i ja nie muszę być jasnowidzem.
Jedyne schematy (trzeba szukać poza karta katalogową) są właśnie typu każdy
element sobie - no nic z takiego schematu, a szczególnie w sensie EMC nie
widać - nie umiałbym chyba zaprojektować płytki według takiego schematu.

Kiedyś (1988), w czasach kiedy dysponowaliśmy tylko IBM-XT i drukarką
igłową, byłem zafascynowany programem Tech (chyba nazwy nie mylę) do edycji
tekstów. Idea taka, że to program wie jak tekst ma wyglądać, a piszący tylko
określa że to jest tytuł, to jest przypis itp., a kompilator zrobi z tego
ładny tekst bo on wie lepiej jakie są wymogi ergonomiczne tekstu, aby się
"dobrze czytał". Jednak przekonałem się do edytorów tekstu, w których od
razu widzę jak to wygląda.
Wydaje mi się, że Twoje podejście do schematu to jest tak jak ten Tech do
tekstu.
Schemat dla elektronika to jest jak rysunek techniczny dla mechanika.
Wyobrażasz sobie edycję w formie tekstu na przykład rysunku złożeniowego
takiego zwykłego mechanicznego budzika, bo ja nie.
Człowiek jest maszyną równoległą, a komputery są maszynami szeregowymi. Dla
człowieka zawsze edycja czegokolwiek będzie łatwiejsza gdy widzi wszystko na
raz.
Dopóki nie zaczniemy być zastępowani przez jakieś humanoidalne roboty
schemat będzie bardziej czytelny w formie graficznej niż tekstowej.
P.G.

do góry

On 10.11.2012 12:23, Piotr Gałka wrote:
> Wydaje mi się, że Twoje podejście do schematu to jest tak jak ten Tech do
> tekstu.

I tak się dziwnie składa że tworzenie w latex dokumentów przy
wykorzystaniu repozytorium przez wielu ludzi jest znacznie wygodniejsze
niż jakikolwiek sieciowy edytor tekstu.. Różnicę widać najlepiej jak
trzeba z tego tekstu zrobić "szablony" parametryzowane i autonomicznie
tworzyć dokumenty. Nie wyobrażam sobie zrobienia tego w edytorze wyswig.

Niestety całe środowisko narzędzi które wykorzystujemy najbardziej lubi
formaty tekstowe albo trzeba dopisywać "helpery" które pokażą/zwizualizują
zmiany.

Pewnie Sebastian byłby szczęśliwy gdyby dało się tak:
http://nvie.com/posts/a-successful-git-branching-mod
el/
pracować z schematami. Mam propozycję: załóż zbiórkę na jakimś
crowdsourcingu, zobaczysz na ile ludzie tego potrzebują.

Marek

do góry

> Jestem bardziej programistą, więc oczywiste wydaje mi się że "schemat"
> opisany w języku tekstowym byłby:
....
Dla połączeń z protela możesz wygenerować Net listy (są tekstowe) - i je
porównać. Dla wartości elementów wygenerować BOM'a i też porównać.

Jeśli było dużo modyfikacji - może być inna kolejność elementów i
połączeń, ale prosty własny programik lub skrypt powinien załatwić sprawę.

do góry

On 2012-11-10 12:23, Piotr Gałka wrote:
> Kiedyś (1988), w czasach kiedy dysponowaliśmy tylko IBM-XT i drukarką
> igłową, byłem zafascynowany programem Tech (chyba nazwy nie mylę) do
> edycji tekstów. Idea taka, że to program wie jak tekst ma wyglądać, a
> piszący tylko określa że to jest tytuł, to jest przypis itp., a
> kompilator zrobi z tego ładny tekst bo on wie lepiej jakie są wymogi
> ergonomiczne tekstu, aby się "dobrze czytał". Jednak przekonałem się do
> edytorów tekstu, w których od razu widzę jak to wygląda.

Ja wręcz odwrotnie. Oddzielam logiczny układ tekstu od wyglądu. Do tego
stopnia, że porzuciłam worda na rzecz xml+xsl i fopa. Ale już pisałem,
że jestem specyficzny, bo czasem chce wiedzieć w diffie co zmieniłem w
dokumencie (szczególnie jak to jest dokumentacja zmiany).

> Wydaje mi się, że Twoje podejście do schematu to jest tak jak ten Tech
> do tekstu.

Czyli słuszne :D

> Schemat dla elektronika to jest jak rysunek techniczny dla mechanika.

Przykręcając śrubkę w mocowaniu silnika jedoczneśnie *NIEZBĘDNE* jest
aby rysunek zawierał kształt koła zębatego z obwiedniami i precyzyjny
kład w poprzek uzwojenia sąsiedniego silnika, prawda?

> Wyobrażasz sobie edycję w formie tekstu na przykład rysunku złożeniowego
> takiego zwykłego mechanicznego budzika, bo ja nie.

Nie wyobrażam sobie aby ktoś edytował rysunek budzika bez mozliwości
podzielenia go na kawałki. Ponadto tu troche oszukujesz: w mechanice
kształt niesie informację. W elektronice schemat jest tylko dekoracją,
na końcu i tak chodzi o to kto z kim łaczy się jakim netem. Innymi slowy
rysunek w elektronice niesie z sobą zdecydowanie mniej informacji niż
rysunek w mechanice.

> Człowiek jest maszyną równoległą, a komputery są maszynami szeregowymi.
> Dla człowieka zawsze edycja czegokolwiek będzie łatwiejsza gdy widzi
> wszystko na raz.

Nie. Mówie to jako programista. Posiadanie obrazu całościowego jest
zadaniem menagera. Przeciętny wykonawca ma wiedzieć *jak* najmniej.
Myslę że w elektronice mistrzu projektujący przetwornicę nie wpowinien
wiedzieć gdzie do CPU kolega obok podpina przycisk.

> Dopóki nie zaczniemy być zastępowani przez jakieś humanoidalne roboty
> schemat będzie bardziej czytelny w formie graficznej niż tekstowej.
> P.G.

To jest mocno dyskusyjne na czym ta czytelność ma polegać.

Dla mnie CPU.addressBus connect memory.addressBus jest *cholernie* czytelne.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:k7lsed$aio$1@node1.news.atman.pl...
>
>> Wyobrażasz sobie edycję w formie tekstu na przykład rysunku złożeniowego
>> takiego zwykłego mechanicznego budzika, bo ja nie.
>
> Nie wyobrażam sobie aby ktoś edytował rysunek budzika bez mozliwości
> podzielenia go na kawałki. Ponadto tu troche oszukujesz: w mechanice
> kształt niesie informację. W elektronice schemat jest tylko dekoracją, na
> końcu i tak chodzi o to kto z kim łaczy się jakim netem. Innymi slowy
> rysunek w elektronice niesie z sobą zdecydowanie mniej informacji niż
> rysunek w mechanice.

Masz rację, że trochę oszukuję (inaczej przesadzam).

>> Człowiek jest maszyną równoległą, a komputery są maszynami szeregowymi.
>> Dla człowieka zawsze edycja czegokolwiek będzie łatwiejsza gdy widzi
>> wszystko na raz.
>
> Nie. Mówie to jako programista. Posiadanie obrazu całościowego jest
> zadaniem menagera. Przeciętny wykonawca ma wiedzieć *jak* najmniej. Myslę
> że w elektronice mistrzu projektujący przetwornicę nie wpowinien wiedzieć
> gdzie do CPU kolega obok podpina przycisk.
>
>> Dopóki nie zaczniemy być zastępowani przez jakieś humanoidalne roboty
>> schemat będzie bardziej czytelny w formie graficznej niż tekstowej.
>
> To jest mocno dyskusyjne na czym ta czytelność ma polegać.
>
> Dla mnie CPU.addressBus connect memory.addressBus jest *cholernie*
> czytelne.

Nie przeszkadza mi na schemacie jak szyna danych, czy adresowa jest
poprowadzona jedną grubą kreską, ale przeszkadza mi jak nie jest
poprowadzona wcale bo wtedy oznacza to, że czegoś podpiętego pod A0 można
się spodziewać wszędzie - czyli jak długo bym schematu nie przeglądał to
nadal nie jestem pewien, czy nie przegapiłem gdzieś A0 napisanego przy
jakimś druciku w kącie kartki.
A już namalowanie wszystkich kondensatorów blokujących razem przy zasilaniu
jest dla mnie utrudnianiem roboty sobie samemu. Wmalowując dany element
ustalam ile ma pinów zasilania i jakich i jakie kondensatory na których mają
być i czy bezpośrednio pod VCC, czy przez koraliki ferrytowe (wymaga to
czasem dokładnego przestudiowania karty katalogowej). Jeśli zamiast
namalować to koło elementu dam to gdzieś na boku nie połączone (rysunkowo) z
danym elementem to jak potem za miesiąc/dwa będę projektował płytkę to
musiałbym to wszystko od nowa ustalać - jest tam na przykład równolegle ileś
elektrolitów, tantali, X7R, Y5V i bądź tu mądry który miał stać przy czym.
Dobry schemat zawiera według mnie już plan EMC płytki. Ja to robię grupując
elementy tak jak mają potem być pogrupowane, a ważne strefy podziału
oznaczam sobie liniami przerywanymi - elementy jednej strefy nie mogą być za
blisko drugiej, aby pojemnościowo (czy prądami powrotnymi po GND) nie
przekazywały zakłóceń, a każdy przewód przechodzący między strefami musi być
przemyślany.

Aby schemat w formie tekstowej zawierał podobne informacje, które na rysunku
widać od razu, to musiałby wykraczać poza samą netlistę - bo netlista to
właśnie połączenie tych wszystkich kondensatorów razem.

Według mnie dla komputera oczywiście wygodniejszy jest zapis tekstowy (ale
binarny też mu wsio ryba) niż graficzny, ale dla człowieka - nigdy.
P.G.

do góry

On 2012-11-10 17:05, Piotr Gałka wrote:
> Nie przeszkadza mi na schemacie jak szyna danych, czy adresowa jest
> poprowadzona jedną grubą kreską, ale przeszkadza mi jak nie jest
> poprowadzona wcale bo wtedy oznacza to, że czegoś podpiętego pod A0
> można się spodziewać wszędzie - czyli jak długo bym schematu nie
> przeglądał to nadal nie jestem pewien, czy nie przegapiłem gdzieś A0
> napisanego przy jakimś druciku w kącie kartki.

Chciałbym wiec mieć narzedzie takie:

show drivers addressBus.A0
show pins addressBus.A0

To jest trywialne jak się już takie pliki posiada. Efekt może być też
graficzny, w końcu generator normalnego schematu jest jak najbardziej
możliwy.

> A już namalowanie wszystkich kondensatorów blokujących razem przy
> zasilaniu jest dla mnie utrudnianiem roboty sobie samemu.

One nie mają znadnego sensu na schemacie. Fakt ich obecności zaciemnia
obraz.

> Wmalowując
> dany element ustalam ile ma pinów zasilania i jakich i jakie
> kondensatory na których mają być i czy bezpośrednio pod VCC, czy przez
> koraliki ferrytowe (wymaga to czasem dokładnego przestudiowania karty
> katalogowej). Jeśli zamiast namalować to koło elementu dam to gdzieś na
> boku nie połączone (rysunkowo) z danym elementem to jak potem za
> miesiąc/dwa będę projektował płytkę to musiałbym to wszystko od nowa
> ustalać - jest tam na przykład równolegle ileś elektrolitów, tantali,
> X7R, Y5V i bądź tu mądry który miał stać przy czym.

Dalej rozmawiamy na innym poziomie. Dlamnie element firmy X wymagający 3
kondensatorów blokujących zasilanie - nie da się popsuć bo zostanie
dostarczony przez producenta w formie XXXAmplifierReferenceModule(
power, input, output) który w środku ma scalaka i kilka elementów na
około. Nie obchodzi Cie ile ma kondensatorów - to nie istotne, niech się
tym martwi producent oraz router pcb a nie schemat gdzie przedstawiadz
ideę a nie workaroundy na problemy scalaków.

> Dobry schemat zawiera według mnie już plan EMC płytki.

Myślę że to przegięcie. Schemat *ideowy* ma pokazywac ideę. Jesli
pokazuje coś więcej - to już jest podejrzane. Mi brakuje np. mozliwości
z jednego schematu wygenerowania dwóch pcb: prototypowej i finalnej.
Najlepiej spójnie ze schematem przez cały czas. Ciężko zachowuje się
spójnośc w schemacie wyglądającym jak rysunek picassa.

> Ja to robię
> grupując elementy tak jak mają potem być pogrupowane

module powerRegulator( input ac, output dc12v)
{
element BC211 powerRegulator; //;)
element ZenerDiode( 5.1V );
...
}

>, a ważne strefy
> podziału oznaczam sobie liniami przerywanymi - elementy jednej strefy
> nie mogą być za blisko drugiej, aby pojemnościowo (czy prądami
> powrotnymi po GND) nie przekazywały zakłóceń, a każdy przewód
> przechodzący między strefami musi być przemyślany.

Wszystko to jest elementem pcb a nie schematu. To że zachowujesz
porządek "liniami przerywanymi" to jest dokładnie to samo co mógłbym
osiągnąc pisząc kod w róznych modułach grupując go ładnie pomiędzy nimi.

> Aby schemat w formie tekstowej zawierał podobne informacje, które na
> rysunku widać od razu, to musiałby wykraczać poza samą netlistę - bo
> netlista to właśnie połączenie tych wszystkich kondensatorów razem.

Przecież mowie - modularnośc. Być może nawet jakieś dziedziczenie. Żeby
się dało tak:

module powerSupply( out U1,U2 ) : implements StandardPowerSupply
{
external module singlePowerSupply< 5V > s1;
external module singlePowerSupply< 12V > s2;

s1.out connect U1;
s2.out connect U2;
}

jak widzisz zrobilem coś na kształt szablonowego schematu i odbiłem jego
dwie instancje w module powyżej. Mogę teraz singleSupply wymienić na
impulsowe albo bateryjne. Resztę schematu to nie interesuje. W dodatku
ten powerSupply jest wymienny miedzy kilkoma innymi schematami bo jest
standardowym "powerSupply". W koncu jak zrobiłem jeden dobry to może nie
warto wymyślać go co chwile na nowo, może za rok coś w nim poprawie.

> Według mnie dla komputera oczywiście wygodniejszy jest zapis tekstowy
> (ale binarny też mu wsio ryba) niż graficzny, ale dla człowieka - nigdy.

Absolutnie się nie zgadzam z poglądem że nigdy. Mnie szlag trafia
oglądając schemat mojego telewizora na ktorym *kompletnie* nic nie widać
bo zamiast wydzielonych bloków mam radosą twórczośc jak wepchnąć
wszystko na jedno A3. Dla mnie taki schemat to dokładnie to samo co
netlista. Nie jest to human-friendly.

do góry

W dniu 2012-11-09 15:44, Sebastian Biały pisze:
> Własnie wale głową w mur: jak sprawdzić jak zmieniła się wersja 16
> schematu względem 12 zakładając że pliki trzymam w systemie kontroli
> wersji? Pomijam w tej chwili oprogramowanie - po prostu mam poważną
> wątpliwość czy to w ogóle jest sensowne w przypadku schematów rysowanych.
>
> Jestem bardziej programistą, więc oczywiste wydaje mi się że "schemat"
> opisany w języku tekstowym byłby:
>
> a) mniej odporny na błedy dzieki stosowaniu jakiś wyższych abstrakcji
> ("magistrala adresowa 1, podepnij do pamięci U2").
> b) wygodny w przeglądaniu historii w systemach kontroli wersji
> c) możliwy do trywialnego podziału na zgrabne logiczne kawałki
> d) nieczytelny dla przecietnego elektronika, ale kij z nimi, niech sobie
> klika.
>
> Teraz: czy świat dorobił się jakiegoś języka pozwalającego rozsadnie
> opisać typowy schemat elektroniczny który:
>
> a) nie jest językiem *hdl bo nie potrzebuje opisywać działania bramek,
> interesuje mnie podpięcie drutow do pinów elementów elektronicznych. Nic
> nie przeszkadza, gdyby *hdl mógł byś wpięty w tle do symulacji.
> b) nie jest czytelny *tylko* dla maszyny, jak edif. Ma być read-write
> dla człowieka.
> c) potrafi okreslić opis na wyzszym poziomie niż pojedyncze druty.
> d) da się skonwertować na schemat (z autoroutingiem połączeń).
>
> Widział ktoś coś rownie nietypowego?
>
> Żeby uprzedzić krucjatę: jestem specyficznym człowiekiem. Uważam za
> wygodne rzeczy które inni nie byli by w stanie używać nawet pod
> przymusem. Liczę jednak że nie jedynym.
>
> Tak sobie wymysliłem w 10 sekund przykład ze składnią wyssaną z palca:
>
> module counter( input wire clock, output vector result[4] )
> {
>
> U2 : CD4093;
> U1 : CD4001;
> R2 : Resistor( 10Ohm, 1W );
>
> U2.gate1.out connect U1.gate2.in1;
> U1.gate2.out connect U2.gate1.in2;
> U1.gate2.in2 connect clock;
> U2.gate3.out connect result[2];
> R2.pin1 connect result[3];
> ...
> U2.vcc connect global.vcc;
> ...
>
> }
>
> Przypomina to języki *hdl, ale tutaj mogę podpinać elementy również
> analogowe. Czy ktoś widział gdzies coś podobnego, nawet bardzo odlegle w
> składni?

Kicad ma plik schematu tekstowy. Ale nie jest to dokładnie to co chcesz.
W pliku są wymienione elementy z wartościami, położeniami i orientacją
oraz połączenia skąd dokąd w sensie współrzędnych. Nie ma listy połączeń
między elementami. Ale w uzupełnieniu z plikiem listy połączeń masz komplet.
przykład .sch:
Wire Wire Line
1700 7000 1700 6950
Connection ~ 1700 6950
Connection ~ 1700 6750
Connection ~ 1600 6750
Wire Bus Line
600 1950 2100 1950
Wire Bus Line
2100 1950 2100 1100
$Comp
L C_MINI C33
U 1 1 4B7D3743
P 1750 6000
AR Path="/333734334B734761/22DA2C4B7D3743" Ref="C33" Part="1"
F 0 "C33" V 1700 6050 30 0000 C CNN
F 1 "100nF" V 1800 6075 25 0000 C CNN
1 1750 6000
0 1 1 0
$EndComp

przykład .net:
( /4B734761/4F437649 $noname IC3 24LC16 {Lib=24LC16}
( 1 /Sheet1/P0.11-RXD2-SCL2-MAT3.1 )
( 2 GND )
( 3 /Sheet1/P0.10-TXD2-SDA2-MAT3.0 )
( 4 VDD33 )
( 5 /Sheet1/P0.6-I2SSRX_SDA-SSEL1-MAT2.0 )
)
Net 8 "P1.29-MCOB2-PCAP1.1-MAT0.1" "P1.29-MCOB2-PCAP1.1-MAT0.1"
IC1 45
IC20 49
Net 9 "" ""
IC23 13
J8 1

--
pozdrawiam
MD

do góry