Opis schematu tekstowo.

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?

Reply to
Sebastian Biały
Loading thread data ...

W dniu 2012-11-09 15:44, Sebastian Biały pisze:

[...]

Wątpię, żeby coś tak wysokopoziomowego istniało (w sensie, że w pliku są tylko pary połączeń bez informacji którędy poprowadzono linię). Przy analizowaniu schematu nie jest mi wszystko jedno gdzie są elementy i którędy idą druty je łączące.

BTW część programów przechowuje schematy w formie tekstowej (eagle, kicad), więc diff daje jakieś pojęcie co zostało zmienione. Altium też potrafi graficznie pokazać różnice między dwoma schematami.

Reply to
Zbych

Wygenerować z obu netlisty, zrobić diff netlist (ewentualnie wcześniej sortując).

Zależnie jakie "różnice" cię interesują - czy przesunięcie linii o 2 mm w prawo, czy zmiany logiczne.

Pliki netlist spice są niepisanym standardem, bo je łykają symulatory, ERC, analizatory, etc.

Schemat jest przedstawieniem wygodnym dla człowieka.

Reply to
Michoo

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.

Reply to
Sebastian Biały

Workaround :)

Ja mam wizje żeby *pisać* schematy i z tego robić pcb.

Pojęcie mm nie istnieje. Istnieją tylko powiązania pinów na różnych poziomach abstrakcji.

Niestety są ciężko czytelne przy większych ilościach danych. Mi chodzi nie o języki write only albo maszynowe. Mi chodzi o zapis czytelny dla mnie.

To tylko teoria :) Niestety jestem zboczony zawodowo programistycznie i chyba wiem dlaczego świat nie dorobił się graficznych języków programowania poza nieistotnym szumem typu LabView.

Reply to
Sebastian Biały

[ciach] To nie jest tak że szukasz czegoś do wizualizacji zmian a nie czytelnego formatu?

Marek

Reply to
Marek

Nie. Wizualizacja zmian przelała czarę goryczy. Gdyby istniał format opisu schematu prawdopodobnie przeszedł bym na niego. Mam ostatnio dwie wpadki wynikające z "narysowania się druta tam gdzie przypadkiem kliknąłem" i nie zliczę ile innych idiotyzmów po drodze. To + kontrola wersji powoduje że rozgladam się za alternatywą. Tak jak mówie, języki programowania grficznego, choć mozliwe, nie mają żadnego sensu praktycznego poza niszami. Podobnie VHDL/Verilog - koem źrodłowym dokładniej opiszesz schemat niż zabawą w klikanie drutów w jakimś gównianym edytorze bo mając taki opis możesz znacznie więcej z nim zrobić.

Reply to
Sebastian Biały

Może źle się wyraziłem. Jeżeliby istniał 'diff' który biorąc dwa pliki z repo wypisałby że różnią się tym że tu było połączenie pomiędzy pinami a w drugiej rewizji go nie ma to zapewne byłoby wystarczające? Poprzez termin wizualizacja nie miałem na myśli graficznej reprezentacji, tylko tłumaczenie z maszynowego na ludzki.

Korzystamy z fwbuildera (tool do generowania firewalli), przechowuje on konfigurację w xml. Niby jest to do przeczytania/zapisu przez człowieka, praktycznie jednak niewykonalne. Znacznie łatwiej jest napisać coś co porówna i rozumiejąc semantykę "przetłumaczy" z maszynowego na ludzki co się dokładnie zmieniło.

Pewną przewagą tekstowego formatu byłoby możliwość mergowania branchy w repo, nie wierzę jednak że działałoby to wystarczająco dobrze.

Marek

Reply to
Marek

Użytkownik "Sebastian Biały" napisał w wiadomości grup

Chyba kazdy rozsadny edytor ma generacje netlisty (jak nie ma, to nie jest rozsadny :-)

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

Owszem, ale wystarczy drobna nieuwaga i w kodzie zrodlowym sobie namieszasz. Przy czym czasem latwiej zauwazyc brak linii na schemacie, niz jakas pomylke w jednej z dziesiatek tysiecy linii kodu ..

J.

Reply to
J.F

Uzywam na codzień SVN w przypadku C++. Działa perfekcyjnie, przy setkach merge mogę policzyć dwa przypadki kiedy nabroił automatyczny merge i nie bez przyczyny. Nie widze powodu dla ktorego niemożliwe było by pracowanie przez N osób równloegle przy tym samym *schemacie*. Nawet rozwiązywanie konfliktów powinno działać sensownie o ile język opisu byłby rozsądny.

PS. VHDL i Verilog też się dobrze mergują automatycznie w SVN.

Reply to
Sebastian Biały

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

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

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ć.

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.

Reply to
Sebastian Biały

W dniu 2012-11-09 15:44, Sebastian Biały pisze:

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

Reply to
ZeNek

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.

Reply to
Zbych

Użytkownik "Sebastian Biały" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:k7jlg7$m0u$ snipped-for-privacy@node2.news.atman.pl...

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.

Reply to
Piotr Gałka

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:

formatting link
ć z schematami. Mam propozycję: załóż zbiórkę na jakimś crowdsourcingu, zobaczysz na ile ludzie tego potrzebują.

Marek

Reply to
Marek

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ę.

Reply to
invalid unparseable

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).

Czyli słuszne :D

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?

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.

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.

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

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

Reply to
Sebastian Biały

Użytkownik "Sebastian Biały" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:k7lsed$aio$ snipped-for-privacy@node1.news.atman.pl...

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

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.

Reply to
Piotr Gałka

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.

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

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.

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.

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

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.

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.

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.

Reply to
Sebastian Biały

W dniu 2012-11-09 15:44, Sebastian Biały pisze:

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

Reply to
Mario

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.