Opis schematu tekstowo.

No to pracuj od razu z netlistą którą da się wczytać do projektu pcb. Wystarczy przyjrzeć się który z przyjętych formatów netlist najbardziej ci odpowiada. Czyli jest dla ciebie najbardziej human read/write :)

To teraz wyobraź sobie, że ktoś teraz musi zrobić szczegółowy schemat tego co dla Ciebie jest pudełkiem o nazwie "radio"...

Świetnie, tym lepiej że nie wie gdzie jest przetwornica z punktu widzienia *schematu*.

W dniu 2012-11-10 16:38, Sebastian Biały pisze:

Bolesne doświadczenia lat ubiegłych przekonują mnie, że jest dokładnie odwrotnie. No, może przesadzam z tą bolesnością i odwrotnością...

Chodzi mi o to, że często warto przy zlecaniu wykonania czegoś oprócz typowego zestawu danych dodać ów całościowy ogląd. Zleceniobiorca wówczas:

- lepiej zrozumie, o co chodzi zleceniodawcy i nie popełni błędów;

- być może wykryje błędy w otrzymanych danych, takie które powodują niespójności z całościowym oglądem.

Stosuję tę metodę od paru lat i oszczędziłem już sporo czasu, o oszczędnościach pieniężnych obu stron nie wspominając.

Pozdrowienia, MKi

Schematy modularne znane są od dawna, w postaci graficznej. Wchodzisz do modułów jak do modułów cyfrowych w FPGA.

Mi chodziło raczej o kwestię tego, że jak masz pajęczynę drutów w takim radio to jednak lepiej to ogarniesz w grafice niż sam suchy tekst.

Co do zboczenia programistycznego, zauważ że tworzy się narzędzia do graficznej reprezentacji dużych programów, powiązań między modułami, drzew wywołań funkcji czy użycia zmiennych oraz graficznej reprezentacji maszyn stanów. To dowód na to, że jednak dużo ludzi w tej branży to wzrokowcy.

Wspomniałem o tym kilka razy. Jednak jezyki opisu *hdl nie nadają się do opisu części analogowej.

Zależy. Jesli mam pajęczynę drutów to już po mnie. Co z resztą szkodzi część schematu dostarczyć jako tekst a część jako rysunek?

To jest *WIZUALIZACJA* a nie edycja. Nic nie stoi na przeszkodzie aby z opisu tekstowego uzyskać grafy, schematy, plany.

Ale to pudełko daje się podzielić na części składowe, więc w sumie nawet odpowiednio skomplikowany układ da się opisać. Coś jak VHDL - masz opisy wejścia-wyjścia i spinasz je ze sobą czo często jest znacznie czytelniejsze od schematu.

Ja projektuję mniej-więcej w taki sposób - z podziałem na małe bloki:

piszę np. "show 3.3v" i mam ładnie zaznaczone na płytce gdzie co idzie: to by się w formie tekstowej całkiem nieźle prezentowało, ALE rozmieszczając elementy graficznie mogę już na etapie schematu stwierdzić mniej-więcej gdzie co wyląduje na płytce.

Dziesiątki lat rozwoju informatyki wykazały dobitnie, że im mniejszy pogląda masz na całość, tym bezpieczniejszy kod piszesz bo nie robisz głupawych założeń. Języki opisu hardware idą tez w tym kierunku (modne stało się unit-testowanie w verilogu) co jest dokładnie tym co chcę uzyskać czyli podejściem podziału na moduły. NIGDY nie powinienem wiedzieć w jaki sposób podpiety jest przycisk "w lewo" w procesor żeby zaprojektować lepszy ADC. Unieszczenie ich na wspólnym schemacie jest bez sensu - nie są od siebie zależne.

Możesz go sobie wygenerować na żądanie w dowolnym poziomie szczegółowości.

Mowisz o tym jak wygląda gotowe urządzenie w konfrontacji z kupującym. Takie coś robi się po wykonaniu a nie w trakcie.

Ja widzę jedną rzecz która szkodzi - mianowicie taki plik źródłowy, plik tekstowy musiałby zawierać informację nie tylko o tym, że punkt A jest połączony z punktem B ale i też o tym gdzie/którędy to połączenie przebiega. Inaczej gdy zostawisz maszynie generację obrazu schematu z czystego zapisu połączeń to otrzymasz takie potworki jakie Quartus Altery robi z konfiguracji FPGA gdy każesz mu wyświetlić graficzną reprezentację połączeń, czyli RTL. Tragedia :-)

Nie zapominaj że mając listę połaczeń i wydzielone moduły, jak rownież informacje czym sa połaczenia (szyna adresowa, sygnał analogowy itd) może to zrobić lepiej niż z głupiej netlisty.

Ponadto siła takiego rozwiązania jest możliwośc oglądania *fragmentu* schematu na żądanie: pokaż mi przebieg lini A1. I widzisz na schemacie tylko elementy do których jest wpięta, cala reszta znika.

jesli chcesz ładny schemat na koniec, to można podejśc do sprawy jak do pcb - odpalisz autorouter a nastepnie sam poprawisz położenia i połaczenia. Tylko nie wiem po co tak naprawdę.

Jakie znowu moduły? Czemu ciągle do modułów wracasz? Ja pisałem o schemacie wewnętrznym modułu. A mianowicie schemat dyskretnych połączeń tranzystorów, oporników, kondensatorów w tym Twoim przykładowym radio.

Chcesz aby kondensator odsprzęgający zasilanie był na schemacie umieszczony tu a nie tam. Chcesz aby pętla sprzężenia zwrotnego szła z wyjścia do wejścia tędy a nie tamtędy bo może coś błędnie sugerować oglądającemu później schemat koledze... Chcesz aby filtry były narysowane tak, jak do tego jesteś przyzwyczajony a nie tak jak "autorouter" ich sobie wyrysuje.

Ciągle piszesz o modułach i ciągle masz w głowie cyfrowe myślenie magistral łączących czarne skrzynki typu "cpu", "pamięć", "uart". Pomyśl chwilę o tym jak zastosujesz swoje pomysły w analogówce.

Za każdym razem jak coś zmienię w tekstowych "źródłach"? Przecież wiesz jak pokracznie działać potrafią autoroutery na PCB. Owszem, połączeń dokonają, ale czytelne to dla człowieka nie jest.

Nie wiesz po co, bo sam nie pracujesz nad schematami...

Co przeszkadza miec moduły w modułach? Przeciez to naturalne że zasilacz składa się z osobnych elementów takich jak driver mocy, układ regulacji, układ shutdown itd. Wszystko wygląda jak schemat blokowy o róznym stopniu szczegółowości. Chcesz widzieć bebechy wzmacniacza - prosze, nie chcesz, też proszę.

Możesz go sobie narysować jesli musisz. Ważne żeby swiat poza nim nie miał pojęcia o tych kreskach. Świat na zwenatrz zna tylko brzeg modulu i tyle.

Jak można źle narysować kondensator odsprzęgający skoro ja posutluje aby go w ogóle nie rysować (jaki jest cel istnienia tego elementu na schemacie *IDEOWYM*, twoja IDEA polega na odsprzęganiu zasilania w 8051 czy na wykonaniu sterwnika akwarium?). Jak mozna źle narysować filtr skoro to osobny, zwarty moduł i części nie zostaną rozrzucone po całym schemacie. Zawsze możesz podać hinty do rysowania jeśli koniecznie musisz *rysować* ale idę o zakład że to zbyteczne jeśli prawidłowo połaczyłeś schemat. Cała masa software do jezykow hdl potrafi nazysować schemat z kodu i robi to na tyle skutecznie że niepismienni potrafią się w tym orientować.

Myślę i nie widzę róznicy. A nie, w zasadzie widzę róznicę: mianowicie kilka programów które miałem w rękach nie rozrózniały napięcia od prądu. Klikałeś w net i mówiłeś "30mils" bo tam miał płynąc duży prąd. A przeciez net to napięcie a nie prąd. No więc można by i to posprzątać:

power.output.vcc connect( 10A ) aplifier.vcc. power.output.vcc connect( 1mA ) inputGain.vcc

I router PCB ma znacznie jasniejszy obraz gdzie jest potrzebna gruba a gdzie chuda scieżka. I nie, nigdzie nie wpiszę jaką ma mieć szerokość. To zależy od technologii wykonania PCB, to nie ta warstwa abstrakcji.

Zaczekaj, dlaczego za każdym razem jak coś zmienisz w źródlach masz oglądać schemat? Może mi to wyjawić? Nie masz zaufania do ścisłego i czytelnego zapisu że musisz za każdym razem analizować druty? Pomysł jest taki zeby *NIGDY* nie oglądać schematu. Tylko w sytuacjach wyjątkowych można go odzyskać.

Autorouter PCB jest inny niz autorouter schematów. PCB ma znacznie więcej stopni swobody i warunków których nie ma na syntetycznym schemacie.

W ogóle i ani trochę.

Nie, nie mówię o tym. Przykład: zlecam wykonanie obudowy, dostarczam rysunki. Po wykonaniu okazało się, że omyłkowo jeden z rysunków zrobiłem lustrzany. Wykonawca jest w porządku, zrobił dokładnie co mu kazałem. Ja straciłem kasę i czas. A jak (za kolejnym przypadkiem) opowiedziałem (machając rękami), o co mi chodzi, sam wyłapał podobny błąd.

Pozdrowienia, MKi

No wiec dalej nie widzê problemu w wygenerowaniu schematu ze "¼róde³".

Zapominasz tylko, że schemat (zwłaszcza analogowy) to nie program i element w 10 zagdnieżdzonym bloku może wpływać na elementy otaczające z

1 poziomu (choćby ceramik od uC położony zbyt blisko LDO na pcb). Przy takim wielokrotnym zagnieżdzaniu bloków znacząco spada szansa, że ktoś to zauważy.

Na PCB. Na ideowym nie. To dwie zupełnie rózne rzeczy czetow mylone w tym watku.

Ktoś to na pewno zauważy że mu się cewka z A wsadziła pod transformator z B na *PCB*.

To tobie się tak wydaje. To na podstawie schematu ma być _widać_ na co trzeba uważać przy projektowaniu PCB, bo nie wszystko da się zapisać jako regułki/obostrzenia przekazywane z netlistą do programu PCB.

Dlaczego nie da siê opisaæ? Bo nie istnieje jêzyk opisu posiadaj±cy odpowiednie konstrukcje? No nie istnieje, to ju¿ wiemy. Nic nie stoi na przeszkodzie ¿eby w nim jednak tworzyæ hinty dla pcb: element A i B jak najdalej od siebie, blok C i D odseparuj mas±, blok E tylko po jednej stonie laminatu, element Y tylko na brzegu, element X tylko poziomo, element W gdziekolwiek. Kwestia przemy¶lenia *innego* jêzyka opisu pcb. Tylko ¿e ja jestem jak najdalej od mieszania kwestii schematu ideowego od romieszczania elementów na p³ytce. Co nie znaczy ¿e nie dalo by rady zrobiæ to w ramach jednego spójnego opisu.

I to jest chyba najwłaściwszy wniosek z tej dyskusji.