Стартуем разработку ч.2

Доброго времени суток, уважаемые форумчане.

Для начала позволю себе оффтоп. Первый мой пост собрал просто хренову тучу комментариев на тему, которой и так засрано пол-нтернета — на чем писать. Собственно, тот пост и скатился к срачу друг с другом и обсуждению что к чему и почему. Во втором посте было уже на порядок меньше холиваров, за сим надеюсь, что третий пост будет в этом плане еще спокойней. Давайте обсудим, что нужно сделать, а что нет, и не будем скатываться к очередному «это фигня и медленно, а вот это круто и натив»

Да, так же хотелось бы извиниться за то, что не написал в понедельник, как и обещал. С одной стороны, потребовалось срочно дособрать десяток контроллеров, с другой — дописать ПО. Но это все фигня по сравнению с снегопадом, который превратил движение по городу в 2-3 часовое стояние на месте. Исправляю оплошность.

Итак, технологии разработки пока что не претерпели каких либо разительных изменений. ClientSide — Unity3d, ServerSide — asp+wcf.

Случилось и первое разочарование — юнити, как таковая, из коробки, не поддерживает адекватной работы с графикой. Это можно делать либо через низкоуровневый рендеринг, который, к тому же, доступен только в Pro версии, что резко сужает круг тех, кто готов принять участие в проекте, либо — через Debug, который, понятное дело, как дебаг не собирается в финальный релиз. Я нашел неплохое решение, которое было благополучно куплено и испытано, но это имеет и обратную сторону — сейчас я в процессе переговоров с автором разработки для получения разрешения выложить проект на GIT.

Теперь что касается самого процесса. Я выбрал для хранения данных на стороне клиента (библиотек) xml. Причина для этого проста — xml, в который можно напихать кучу данных в качестве атрибутов, более спокойно относится к изменениям формата хранения и представления данных, чем JSON, который при изменении того самого формата просто перестанет десериализоваться стандартными средствами, и получится перебирание всего массива данных в ручном режиме.

Теперь что касается организации данных. За основу взят формат Eagle. Он дополнен, по справедливому пинку evsi различными форматами футпринтов.

Текущие вопросы.
— В Eagle есть различные, тык сказать, настройки УГО — в зависимости от требуемой локали выбирается тот или иной компонент. На мой взгляд, ересь дикая, потому хочу запихнуть это просто в настройки отображения всей схемы. Но если это так логично, почему не сделано до нас?
— УГО, вне зависимости от локали, я встречал двух видов — первый — это прямоугольник с херовой тучей пинов, второй — разбитый на логические блоки (для логических микросхем) или на наборы функциональных блоков (например, блок портов для STM). Хотелось бы придерживаться единообразия, потому вопрос — насколько востребован сей формат отображения?

Работа с блоками. Формирую модель для создания пользовательских блоков. Т.е. формируем, к примеру, БП, и сохраняем его в виде пользовтаельского блока, указывая ему настройки видимости (для пользователя или в Wiki), то же самое для трассировки. Вопрос — требуется ли просмотр блока в редакторе, или это можно сделать просто в отдельном окне? С одной стороны, в редакторе удобней, если требуется часто лазить по схеме блока, с другой — сложней в реализации. И наоборот — просто реализовать отдельное вью для блока, но при этом ухудшается аспект частого обращения к нему.

Спасибо
  • -1
  • 07 февраля 2013, 11:39
  • dtcDev

Комментарии (43)

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

совет от себя… частенько у компонентов не используются некоторые ноги. на компонентах не всегда логично расположены ноги (зачем мне, например, расположение выводов как на корпусе, если это мешает красивой отрисовке). таки вот. в случае с многоногим прямоугольником было бы удобно иметь возможность перемещения выводов в пределах УГО или хотя бы скрывать неиспользуемые. из той же оперы — железное объединение ног (у мосфетов в со-8 как правило 4 ноги замкнуты. почему бы не заложить возможность их отображения на схеме как одной.
0
  • avatar
  • xar
  • 07 февраля 2013, 13:17
по привязке к локали — имхо «для удобства»
0
  • avatar
  • xar
  • 07 февраля 2013, 13:17
Не привязка к локали (криво выразился), а ее выбор, с автоматическо сменой «на лету» набора УГО
0
имел в виду привязку УГО к выбранной локали
0
работа с блоками так ли уж нужна? если оно разводится на той же плате — пусть в схеме он будет всего лишь сгруппированным набором элементов, который можно разгруппировать и подправить.
0
  • avatar
  • xar
  • 07 февраля 2013, 13:19
Вопрос в повторном использовании блоков, и только в нем. Ради удобства, когда со временем накапливается набор проверенных решений, но нет нормального инструмента для их импорта, лично для меня актуален.
0
Это один из вариантов (весьма полезный, кстати). Есть и другой: оспользование готовой платы в качестве (навесного) модуля. Поддержка сквозного именования цепей и отслеживание изменения в расположении внешних разъемов были бы как нельзя кстати.
0
если блок проверенный — зачем его схема вообще? пусть будет блекбоксом. и вообще, как уже заметил evsi, лучше сделать его отдельной платой (питание например всегда делаю внешнее).
0
Ну может БП есть пример не совсем корректный, но, к примеру, RS485 с обвязкой — гораздо приятней иметь его в виде блока и тянуть от проекта к проекту, чем каждый раз устраивать пляски с бубнами по переносу его из проекта А в проект Б.
0
Ну может БП есть пример не совсем корректный,
так может, он просто рейтингом и отзывами сольется?
RS485 с обвязкой — гораздо приятней иметь его в виде блока и тянуть от проекта к проекту, чем каждый раз устраивать пляски с бубнами по переносу его из проекта А в проект Б.
кажется, это и современные кады позволяют. а проверять самостоятельно придется в любом случае.
0
Вопрос стоял несколько в другом. У вас есть пул блоков, из которых вы лепите схему. Нужно ли Вам раз в минуту получать информацию о том, какова принципиальная схема блока, или достаточно просто грамотно подписанных пинов блока?
0
раз в минуту не нужно. при первом использовании — жизненно необходимо. и вот при первом использовании разницы между инспекцией готовой схемы (блока) и рисованием самостоятельно я в упор не вижу.
0
При первом понятно. При последующих уже не нужно.
0
ну, при первом пользовании после длительного перерыва я даже собственноручно нарисованные библы проверяю, у меня и процессы могли поменяться. чего уж говорить о чужих, даже если там 100500 плюсиков стоит.
яркий пример: я сейчас забираю одного клиента на мелкосерийку. они монтажили приходящей монтажницей. а я буду все жарить в печке. согласитесь, даже в пределах меня одного разница в футпринтах весьма существенная.
0
Мне кажется, удобнее будет «чёрный ящик» с пинами, с содержимым которого при желании можно ознакомиться. А на схеме его содержимое не нужно.
0
Еще хочу напомнить об одной фиче, которой пользовался в Eagle — эквивалентный обмен блоков одного корпуса. Для удобной разводки иногда имеет смысл поменять местами блоки, типа DD1.1 <-> DD1.3. В том числе и обмен эквивалентных блоков из разных корпусов DD1.1 <-> DD2.3.
Ну и, конечно, резисторы «прямоугольничками», а не «пружинками».
0
  • avatar
  • meps
  • 07 февраля 2013, 16:24
Ну и, конечно, резисторы «прямоугольничками», а не «пружинками».

Это УГО. Если выбрать подходящую либу с резисторами, то будут именно прямоугольнички, а не пружинки.
0
А фича с заменой блоков одного корпуса много где есть. В кикаде есть, в альтиуме есть…
0
она есть. но по крайней мере в альтиуме она то работает, то в очередном релизе ее поломают, то опять работает… %)
0
Я им не пользовался, просто видел, что есть. Вот в кикаде пользовался разок, реально удобно при разводке.
0
а я попользовался. причем, проникнулся во время застоя (был такой у альтия), а потом началась чехарда работает-не_работает. пришлось отвыкать. сколько новых идеоматических оборотов в процессе отвыкания придумал — просто неописенно…
0
ServerSide — asp+wcf
Дальше читать не стал, сервер не винде это эпик.
0
  • avatar
  • caver
  • 07 февраля 2013, 18:10
Ваше право :)
0
сервер не винде это эпик.
это как асм vs С vs C++ на эмбедде — вечный холивар.
+2
Я был в святой уверенности, что два поста холиваров уже дали возможность выпустить все пары.
0
Я был в святой уверенности
скорее наивной ;)

холивар — он такой. он вечен!
+2
От да, согласен — в наивной :)
0
да нет. просто у вас талант. или эпидемия пошла какая то холиварная *WALL*
+2
+1 самый начальный пост был ничем иным, как самой откровенной провокацией холивара ради привлечения внимания. От заголовка и до тезисов. В резкой и категоричной форме.

И да — эпидемия наблюдается. Пишешь пост «как под маком настроить разработку X,Y и Z» — спор о том, что мак гавно… Пишешь как эффективнее юзать эклипс — спор о том где и на чём это гавно тормозит. Такое ощущение, что люди теряют способность собирать мысли в кучку и держать их в контексте. Ладно бы вконтактике, но тут…
0
Такое ощущение, что люди теряют способность собирать мысли в кучку и держать их в контексте
это просто
а) весело
б) в холиварном обсуждении порой можно много чего интересного почерпнуть.
+1
да не вопрос… жалко что ценность ресурса снижает
0
это в первую очередь сообщество. так что считаю небольшой срач и подъебочки только полезны, ибо сближают )
0
ценность ресурса они не снижают. т.к. у всех в голове сами по себе завелись срачефильтры. надеюсь только, что эти фильтры не мешают получать новую полезную инфу.
0
Холивар тут ни при чем. Есть опыт эксплуатации высоконагруженных серверов и он совершенно однозначно говорит, что держать их на винде себе дороже.
0
эххх… твои слова, да некоторым в уши… я вот прям сейчас наблюдаю написание «убийцы фейсбука» на шарпе и виндовых серверах. показывал-доказывал, без толку. повбывавбы(с)
0
Про что и речь, свистоперделку для хостинга фоток своего котЭ хоть на вижуал бейсике, когда доходит до продакшена тут уже варинтов в общем то нету. Linux — only, как вариант писать на Java и засунуть в что нть типа Tomcat. Вполне себе рапид-девелопмент при наличии не кривых рук.
0
Вот ссылочка на сравнение Web framework для жабы. Все вопли про Java что тормозит и хреново работает, говорю сразу — вы нее умеет ее готовить %)
0
мсье ведь в курсе.нет вполне используется на таких high-load как myspace.com, newegg.com, plentyoffish.com. при чем многие знакомые high-load специалисты после опыта с дотнетом от поддержки старых проектов отказались в пользу конкурентов.
0
А я вот думал, что дальше
> я накопил достаточный опыт в программировании. Занимаюсь этим уже 5 лет.
> языки программирования клиента — C# + JS, сервер — C#
> сервер проекта svn
читать уже не буду :)
Но стало интересно, заглохнет ли энтузиазм/проект. И если вдруг да, то насколько быстро и на каком этапе.
0
По поводу графики. XNA не рассматривали?
0
XNA = .NET = Windows Only => почему не WPF, которая на порядки, нет, на херову тучу порядков удобнее для такой затеи? :))))
0
Вы в WPF схемы рисовать собрались, или рендеринг 3D модели платы делать? Или и то и другое?
0
Я собирался, изначально, делать на WPF, как на более быстрой технологии для производства продукта. Меня сбили с понталыку, переключив на кросс-платформенное решение. В частности, из за воплей Linux! Linux!

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