[Сергей Борщ 119]

Я понимаю, что вопрос прозвучит как поиск халявы. На самом деле так оно и есть. Честно признаюсь: я совершенно не имею понятия о регулярных выражениях и различных линуксовых утилитах обработки текста. Знаю только, что они есть. Задача разовая и тратить время на глубокое изучение очень не хочется. Если для кого-то ее решение будет делом пяти минут и разминкой мозга - буду признателен.

Сама задача: есть файл списка цепей Kicad. Нужно из него удалить те цепи, которые подключены только к одному выводу. Пример (полный файл в приложении):

    (net (code "133") (name "Net-(DD1-Pad71)")
      (node (ref "DD1") (pin "71") (pinfunction "T1_ETR/PA12")))
    (net (code "134") (name "Net-(DD1-Pad71)_1")
      (node (ref "DD1") (pin "71") (pinfunction "TX/PA12")))
    (net (code "135") (name "Net-(DD1-Pad72)")
      (node (ref "DD1") (pin "72") (pinfunction "JTMS-SWDIO/PA13"))
      (node (ref "XS14") (pin "1") (pinfunction "1")))
    (net (code "136") (name "Net-(DD1-Pad76)")
      (node (ref "DD1") (pin "76") (pinfunction "JTCLK-SWCLK/PA14"))
      (node (ref "XS14") (pin "2") (pinfunction "2")))

Как видно, цепи 133 и 134 описывают две разные никуда не идущие цепи, подключенные к одному и тому же выводу. Надо их удалить. Т.е. если вслед за строкой, начинающейся с "(net" идет только одна строка, начинающаяся с "(node", то обе эти строки надо удалить. Не обращайте внимания, что обе цепи одного вывода тут идут подряд, обычно такие цепи разбросаны по файлу случайным образом. Концовка у файла такая:

    (net (code "215") (name "~SD_EN")
      (node (ref "DD1") (pin "77") (pinfunction "T2_1_ETR/JTDI/PA15"))
      (node (ref "R43") (pin "2") (pinfunction "2"))
      (node (ref "VT1") (pin "1") (pinfunction "G")))))

и ее тоже желательно корректно обрабатывать, т.е. если удаляется последняя строка файла, то на ее место надо воткнуть строку с двумя закрывающими скобками. Текущая версия Kikad проглатывает отсутствие закрывающих скобок в конце файла, но кто знает, что придет в голову этим пчелам разработчикам в будущем.

Хочется простенький shell-скрипт, который можно натравливать на файл списка цепей. В принципе, достаточно только корректной команды запуска утилиты обработки текста (awk, sed, что там есть еще в линухе), в скрипт я и сам оберну. 

Если кому интересны подробности, как такая ошибка генератора вылезает - у меня УГО многих компонентов состоит из нескольких элементов (units). Например, УГО контроллера имеет один элемент с портами ввода-вывода и по одному элементу на каждый узел периферии (USART1, USART2, ADC и т.п.). Естественно, один и тот же вывод встречается в нескольких элементах, но подключен только в одном из них. Французский гений автора Kicad присваивает новую цепь каждому экземпляру такого вывода, а при загрузке списка цепей в плату использует первую попавшуюся цепь для данного вывода. В результате соединение выводов посадочных мест на плате зависит от взаимного расположения таких элементов на листе схемы: повезет - будет как задумано, не повезет - у вывода будет никуда не подключенная цепь. В комментарии к сообщению об ошибке в ответ на вроде бы очевидное предложение не генерить цепи для неподключенных на схеме выводов французский гений написал, что это нужно для визуального контроля правильности упаковки произвольного УГО в произвольный корпус. Ошибка висит в состоянии "подтверждено" более двух лет, мне начинает надоедать удалать такие "висящие" цепи вручную текстовым редактором после каждой генерации списка цепей. Когда-то я делал собственный патч для пропускания таких "висящих" цепей при генерации, но они в очередной раз перепахали код генератора и теперь в нем сам черт ногу сломит, а старый патч, разумеется, уже не накладывается.

netlist.zip

[xvr 12]

Ни sed ни awk тут не подойдут - не хватит возможностей.

Подойдёт какой нибудь полноценный язык - Python например.

Если файлы небольшие (что бы целиком в память загрузить можно было), то скрипт будет достаточно простым.

 

with open("input.txt", "rt") as f:
    input_data = f.readlines()

skip_count = 0
total = len(input_data)
input_data.extend(("","",""))
for index in range(0, len(input_data)):
    if skip_count:
        skip_count -= 1
        continue
    if "(net" in input_data[index] and "(node" in input_data[index+1] and "(node" not in input_data[index+2]:
        skip_count = 1
        continue
    print(input_data[index].rstrip())

скобки на последней строке не проверяет - если задача разовая можно поправить вручную

[yes 5]

вообще-то в питоне (как в Симпсонах) разборщики EDIFа есть (я не пользовался - погуглил)

https://pypi.org/project/spydrnet/

ну и что там его разбирать - лиспоподобные конструкции

на awk-е, естественно, это можно сделать, но на питоне проще

--------------

и как-то удивительно почему пинфункшин разное?

(node (ref "DD1") (pin "71") (pinfunction "T1_ETR/PA12")))

(node (ref "DD1") (pin "71") (pinfunction "TX/PA12")))

[Vladivolt 0]

>pcregrep -M --file=net.txt  sample.txt
 (net (code "135") (name "Net-(DD1-Pad72)")
   (node (ref "DD1") (pin "72") (pinfunction "JTMS-SWDIO/PA13"))
   (node (ref "XS14") (pin "1") (pinfunction "1")))
 (net (code "136") (name "Net-(DD1-Pad76)")
   (node (ref "DD1") (pin "76") (pinfunction "JTCLK-SWCLK/PA14"))
   (node (ref "XS14") (pin "2") (pinfunction "2")))
   
net.txt
\(net.*(\n *\(node.*)(\n *\(node.*)+
 

NET.TXT

[yes 5]

извиняюсь, наверно это не EDIF по крайней мере не похоже по названию узлов, но скобочки и листоподобность присутствуют

 

понял про пинфункшены

 

 

[_pv 52]

до кучи ещё на lua:

#!/usr/local/bin/lua
f = io.open(arg[1], "r")
str = f:read("a")
f:close()
str = str:gsub("%s*%(net [^\n]*\n%s*%(node [^\n]-%)%)%)","")
print(str)

 

[Сергей Борщ 119]

С питоном понял, есть пища для размышлений, спасибо. 

Vladivolt, о, шикарно. А без net.txt можно? 

1 минуту назад, yes сказал:

и как-то удивительно почему пинфункшин разное?

Потому что это экземпляры вывода из разных элементов одного компонента - первый из элемента GPIO и таймеров, второй - из CAN1.

[yes 5]

3 minutes ago, Сергей Борщ said:

 

Vladivolt, о, шикарно. А без net.txt можно?

import sys

file_name=sys.argv[1]

ну и дальше...

 

по-моему так

[Сергей Борщ 119]

35 минут назад, yes сказал:

извиняюсь, наверно это не EDIF

Это велосипед с квадратными колесами, как и большинство других решений в Kicad. Со временем они закономерно должны изобрести формат PCAD-ASCII.

Апофеозом была такая фраза в их roadmap, недавно кто-то до нее все-таки дочитал и ее убрали:

Цитата

> Study ergonomics of various commercial/proprietary PCB <http://docs.kicad-pcb.org/doxygen/namespacePCB.html> applications (when in doubt about any particular UI solution, check how it has been done in a certain proprietary app that is very popular among OSHW folks and do exactly opposite).
 

 

6 минут назад, yes сказал:

по-моему так

Мне кажется, вы не поняли - в NET.TXT находится строка "\(net.*(\n *\(node.*)(\n *\(node.*)+", было бы совсем красиво засунуть ее в командную строку запуска pcregrep.

Так, отбой - эта конструкция вырезает из файла и все остальные строки, не имеющие отношения к "(net"

[yes 5]

а имеет смысл задавать софтверно конфигурируемые элементы (я так понял, что это собственно причина) в виде УГО?

в чем выгода, в том, что не надо даташит читать при рисовании схемы? только при создании либы?

но бывает, что тот же CAN1 может выставлятся на полдюжины вариантов ножек (в тех же STM-ах или IMX-ах) - то есть по 5-6 вариантов на каждую ножку - перебрать все варианты в виде отдельных УГО кажется невозможным...

 

[Vladivolt 0]

6 минут назад, Сергей Борщ сказал:

А без net.txt можно? 

>pcregrep -M \(net.*(\n *\(node.*)(\n *\(node.*)+  sample.txt
pcregrep: Error in command-line regex at offset 10: missing )

не проходит такой паттерн в ком.строке ...

[Сергей Борщ 119]

10 минут назад, yes сказал:

а имеет смысл задавать софтверно конфигурируемые элементы (я так понял, что это собственно причина) в виде УГО?

в чем выгода, в том, что не надо даташит читать при рисовании схемы? только при создании либы?

Мне так удобно и да, в техописание с таким подходом я заглядываю существенно реже, работа идет быстрее:

Это красивее и проще для понимания, чем рисовать один большой УГО со списком всех возможных функций каждой ноги и потом вспоминать, какая именно из функций этой ноги используется. Или рисовать УГО только с номерами GPIO и потом еще дольше ломать голову, но уже с дополнительным заглядыванием в документацию.

 

[Vladivolt 0]

>pcregrep -M \(net.*(\n\s*\(node.*)(\n\s*\(node.*)+  sample.txt
    (net (code "135") (name "Net-(DD1-Pad72)")
      (node (ref "DD1") (pin "72") (pinfunction "JTMS-SWDIO/PA13"))
      (node (ref "XS14") (pin "1") (pinfunction "1")))
    (net (code "136") (name "Net-(DD1-Pad76)")
      (node (ref "DD1") (pin "76") (pinfunction "JTCLK-SWCLK/PA14"))
      (node (ref "XS14") (pin "2") (pinfunction "2")))o

пробел

А как вместо "(bar)(bar)+" задать "два и более раз (bar)" - пока не знаю.

[Сергей Борщ 119]

13 минут назад, Vladivolt сказал:

не проходит такой паттерн в ком.строке ...

Жаль. Да и другие нужные строки оно выкидывает. Будем использовать питон.

26 минут назад, Сергей Борщ сказал:

28 минут назад, yes сказал:

по-моему так

Мне кажется, вы не поняли

А вот для скрипта из сообщения xvr ваш совет очень пригодился, большое спасибо. Задача решена, землекопов - полтора.

[yes 5]

17 minutes ago, Сергей Борщ said:

Мне так удобно и да, в техописание с таким подходом я заглядываю существенно реже, работа идет быстрее:

удивительно (для меня) - обычно КАД (PADS 100% остальные давно пользовал, может изменилось что...) не разрешает сделать так, чтобы сумма пинов во всех привязаных УГО отличалась от количества ножек футпринта.  то есть если пытаешься такой компонент собрать, то вылазит ошибка тула.

интересно, кто-нибудь еще так делает?