Ровно год назад мы инициировали разработку приложения призванного упростить и упорядочить разработку библиотек для различных систем EDA.

Основной упор сделан на хранение информации в базе данных.

Предполагается, что программа в усеченном варианте будет работать с нашей
Schemagee в режиме горячей связи, то есть пользователь выбирает из базы
компонент и он вставляется на схему. То есть компонент выбирается не
по символу (как в пикаде), а по набору параметров (некое подобие оркадовской CIS).

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

В полнофункциональной версии будет присутствовать набор интерфейсов, позволяющей генерировать библиотки для ЛЮБОЙ буржуйской
системы проектирования.

Как это будет выглядеть (приблизительно) показано в прилагаемом фильме.

http://www.eltm.ru/flash/lmg_movie.zip

(Кстати, почему он не приаттачивается к сообщению?)

В связи с этим у меня вопрос: есть ли у вас описания текстовых (а может и бинарных) файлов проектов и библиотек оркада-аллегро?

одна маленькая притча:
в городе П в студгородке была сеть между двумя корпусами.
так как она была общая, то подключались к ней как хотели, а то и как могли - и она начала глючить!
стали в сети разговоры разговаривать: как, когда и где её улучшить.
кто деньгами сброситься предлягал, кто генерального админа выбрать.
и дальше разговоров дело не заходило. хотя достаточно было один свич на всех купить.
но тут появился один воин на белом компьютере и нашел в себе силы его купить. и заработала сеть! и вздохнули все свободно.
и стали воину его затраты возмещать, и никто в обиде не остался.
а после другие герои тоже свою лепту вносили
и жили они , и до сих пор не нарадуются.


я это к тому - хорошь воду то в ступе толочь
пора делом заняться - там видно будет
не умрет проект - хорошо, умрет - тоже хорошо опыт будет
dietimon или ктонить с опытом или по роду занятий начните чтоли.

По поводу внутренних форматов, шло обсуждение на нашем же форуме
http://forum.electronix.ru/index.php?showtopic=69

Ваш файлик посмотрю, спасибо

По поводу начала, хочу понять хоть в какую сторону начать. Для этого ответьте хоть на какие-нибудь вопросы заданные в этой теме

для начала определимся с форматом
я работаю в PCADе, сейчас есть непреодолимое желание перепрыгнуть на Mentor Graphics.
может стоит продумать какуюнить иераржию типа:
библ->приложение->тип элемента->производитель элемента->элемент
а внутри перекрестные ссылки

важно за ссылками следить, и аттрибуты прописывать

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

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

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

В новом выпуске журнала PCD Magazine

http://www.pcdandm.com/pcdmag/mag/0502/0502pcdm_digital.pdf

есть статейка про будущее CAD библиотек.

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

Мне кажется, что следует разделить библиотеки по типам используемых САПР,
тем самым ликвидировав сложное в реализации звено импорта/экспорта.

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

Далее, собственно из чего состоит компонент: УГО, посадочное место и
аттрибуты. Многие фирмы на территории СНГ выполняют схемы по госту, или очень близко к нему. Соответственно нужно определить четкий стандарт
для УГО. Больших проблем с созданием библиотек УГО быть не должно.

Больше сложностей возникает с паттернами, бо они зависят от технологий, но
обычно можно ограничиться парой для reflow и волны причем в некоторых
случаях они будут одинаковыми. Сюда же следует отнести унификацию
в обозначениях на слое шелкографии и сборочном чертеже, причем последним
не стоит пренебрегать!

И наконец, собственно компонент: теоретически все просто - поставить
в соответвие N пинов и задать K аттрибутов. Причем проработка названий и
назначения аттрибутов задача весьма ответственная - так как от этого будут
зависеть возможности генерации отчетов на этапе подготовки тех документации.

Очевидно, что проработать и реализовать все сразу будет сложно, но если
это нужно (а это действительно нужно) и трудности не пугают, то вперед!

а всетаки , каким образом проводить проверку и классификацию , у нас в фирме например компоненты находятся в библиотеке к одному прибору и растащить по производителям их проблемотично (по времени).

а в навал их кидать... такая каша получиться

Мелкие вещи вообще неудобно раскладывать по производителям. Волевым
решением разделили все на такие группы:
Резисторы, Конденсаторы, Процессоры, Память, FPGA, 74-подобная логика,
cd40-подобная логика, Микросхемы, Полупроводниковые приборы,
Моточные изделия, Коммутационные изделия, Элементы конструктива.

От приязки библиотек к прибору так же пришлось отказаться. В замен было
введено понятие "версия" для УГО, паттерна и компонента которая добавляется
к названиям через подчерк. Например - VQFP128A-14x20_0. При внесении
изменений которые могут повлиять на уже нарисованные схемы и разведенные
платы создается новый элемент со следующим номер версии и добавляется запись
о сделанных изменениях в соответствующий txt файл.

Данная схема достаточно хорошо себя зарекомендовала.

Самое верное- если кто-то сделает эту работу за деньги. При возникновении ошибок -будет платить за них. А желание сложить в кучу свои библиотеки -понятно, но ни к чему хорошему не приведет. Это -очень важная часть работы и она должна оплачиваться.

дык, и сколько по твоему должен получать администратор библиотеки?
это по моему не дело.
так библиатека в коммерчесий вариант превратится.

Сейчас меня все или почти все будут ругать, но все-таки "вставлю свои 5 копеек". Начну с вопросов:
- А что такое "библиотеки", которые вы все собираетесь складывать на каком-то сервере??? Если речь идет об УГО (во, достижение - минут за 10 вспомнил чего это значит) и footprint-е, то тут и говорить особенно не о чем, работа создать это совсем плевая, даже для сложного элемента, типа DSP C600x занимет минут 20. Если же речь идет о библиотеках для всяческого моделирования, тестирования и т.д. (IBIS, BSDL, VHDL/Verilog, вариации SPICE-ов и масса всякого другого с подобными целями), то на "добровольных" началах ничего не получится - такая работа "на колене" не делается, требует массу времени, ответственности, знаний, оборудования, .... Я даже профессиональным моделям не слишком доверяю (типа IBIS от Texas с пометкой, что модель не экспериментальная, а теоретическая), но пользоваться приходится, т.к. лучшего ничего нет или стоит дурных денег.
- Под какой CAD клепать? Все процедуры import/export обычно такое дерьмо, что не приведи господь, CAD-ы несовместимы или очень плохо совместимы.
- Почему, по крайней мере, как заготовками не пользоваться поставляемыми с пакетами библиотеками? Да, есть ошибки, да - УГО выглядит не так как хотелось бы, но как заготовка, по-моему, подходит. Да, кстати, несмотря на мою нескончаемую ругань про Протел, вынужден отметить, что в последних версиях библиотеки очень большие и почти все можно в большем или меньшем приближении найти. Правда я никогда не пользовался никаким Протеловским моделирование, и сказать про качество этой части ничего не могу.

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

Никто ругать вас не будет. Я внимательно слежу за этим топиком и ждал пока кто-либо поднимет вопрос: "А что же собственно такое - современная библиотека компонентов? Из чего, каких компонентов она должна состоять?". Никто не поднял, всех в основном интересуют УГО по ГОСТу (посадочные места не интересны - что у нас, что у буржуев они в принципе одинаковы).
Не в обиду никому будет сказано, но вопросы УГО, в основном возникают у начинающих разработчиков - у всех кто работает довольно долго эта проблема давно решена своими руками. А внесение новых элементов в свою библиотеку происходит по накатанному сценарию по мере поступления этих новых элементов. Причем это происходит не очень часто (если конечно не метаться по сторонам). Такая же проблема может встать и в случае перехода на новый пакет проектирования. Но в этом случае еще проще.
А вот создание полноценной библиотеки, в которую входит не только УГО и корпус, но и модель элемента (электрическая, логическая, физическая и др) дело серьезное. И голым энтузиазмом не подъемное. Не зря же серьезные фирмы (см. выше) за ведение таких библиотек берут серъезные деньги.

Спасибо за моральную поддержку

Я почти полностью согласен и с LeonY, и с Nixon.

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

Проблема именно состоит в том, что непонятно в каком формате (или вообще виде) эти библиотеки хранить.

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