Читайте статью внимательней! Ни одного упоминания про Маткад там нет! Симулятор встраивается в Matlab(платный) или Octave (бесплатный). Руководство по установке на Windows есть тут: openems.de/index.php/OpenEMS#Windows
Собственно симулятор (вычислительное ядро FDTD и визуализатор AppCSXCAD) написаны на C++. Такой софт делать на скриптовых языках, подобных Матлабу нерационально. На Матлабе написан только конвертер результатов моделирования в структуры данных Матлаб и формирователь задания. Остальные компоненты симулятора написаны на С++.
Если точнее, то QtCreator для проектов с CMake показывает всё смешанным деревом, а для проектов с qmake — отдельно хэдеры и исходники. У меня раздельное дерево раздражения не вызывало.
Согласен со статьёй. Аналогичные результаты с многоэтажными формулами получаются в Maple если проанализировать переходный процесс в колебательном контуре операторным методом. При этом Maple предполагает все коэффициенты комплексными и это приводит к формулам на весь экран. Чтобы этого не происходило ему нужно явно указывать тип всех коэффициентов real. После этого решение становится несколько компактнее.
Вобщем следует вывод, что компьютер не заменяет мозг. Даже если вы используется математические системы, это не отменяет необходимости думать над тем, что вы хотите получить от компьютера.
У меня возникла такая же мысль. Например, чтобы мне сейчас импортозаместиться, мне нужно купить зарубежную ОС и зарубежные среды разработки. Тем самым финансово поддержать «вероятного противника». Взять «отечественную» ОС (например какой-нибудь AltLinux) и начать разрабатывать под отечественный МК нельзя. Причём для импортных МК вполне успешно можно заниматься разработкой под отечественной ОС. Теоретически даже наверное под ОС Эльбрус можно пересобрать тулчейны для разработки например для STM32 или MSP430. Но здесь сам МК нужно покупать у «вероятного противника».
Так что получается, что в результате импортозамещения нет никакой разницы с этой точки зрения. Где-то здесь нарушена логика, т.к. логично что русский МК должен программироваться из русской ОС.
Читал на форуме Миландра, что они не занимаются разработкой инструментальных средств под Linux, но «интересуются данным направлением». Интересно, кто-нибудь здесь знает как у них обстоят дела с этим направлением сейчас?
Существует вот этот проект github.com/Valber/qucs2kicad. Как видно из названия, это скрипты на Питоне, которые конвертируют схему из Qucs в KiCAD. Кому нужно, можете пробовать.
Цифровое моделирование МК не планируется. Сейчас можно использовать VHDL/Verilog, если нужно подключать сложные цифровые ИС. Простые логические элемены/триггеры/регистры тоже реализованы. Зато планируем добавить через несколько релизов цифроаналоговое моделирование (ЦАП/АЦП, цифровые схемы в аналоговом включении).
По поводу добавление симуляции МК… Данную функцию добавить у нас неоднократно просили. Трудоёмкость создания интерактивного симулятора, подобного Proteus большая, а нужность и полезность — сомнительная.
Целиком полагаться на симулятор при отладке устройства на МК — очень вредная идея. Взять и смоделировать схему с МК целиком можно далеко не всегда. По опыту работы с Proteus, он корректно симулирует только AVR. Уже для PIC-контроллеров я искал у себя в программе несуществующие баги, так как симулятор неправильно неправильно смоделировал прошивку. Есть жалобы на некорректную реализацию MSP430.
Протеус имел смысл, когда МК прошивали самодельным программатором от LPT-порта, а профессиональные программаторы были недоступны. Сейчас внутрисхемные отладчики и простое контрольное оборудование доступны даже студентам, отладочные платы для любых МК тоже продаются в огромных количествах, так что все действия, которые выполняются при помощи Протеуса можно выполнить при помощи современных отладочных комплектов.
Вобщем, я считаю, что с МК лучше работать в железе на отладочное плате, а не в симуляторе.
На Slackware-64 у меня ваша IDE запустилась. Проект создаётся, схему можно создать, но вместо русских букв везде непонятные символы. Здесь нужны ещё отзывы от тех, кто запустил её на других дистрибутивах. Возможно какой-то баг Slackware. Arduino у меня нет, поэтому проверить вашу IDE в деле не могу.
Ваши проблемы с запуском на 64-разрядной системе вероятно связаны с отсутствием в последней ia32-libs. Это комплект библиотек, который дублирует 64-разрядные библиотеки. Без него соответственно 32-разрядное ПО не запустится. Гуглите ia32-libs ubuntu.
*Office хорош на производстве, чтобы быстро писать договора, письма, служебки и т.п. Там ему самое место. А затаскивать *Office в научную среду не стоит. Там должен использоваться TeX, DocBook и т.п.
Сам иногда использую LibreOffice для написания тезисов на 1-2 стр. с 1-2 рисунками без формул.
Ещё дополню, что в standalone можно оборачивать не только схемы но и любую графику. Замедление компиляции документа наблюдается не только для схем, но и для любой насыщенной графики TikZ.
maisvendoo Уже описал преимущества применения TeX'а.
От себя добавлю, что ПО САПР вообще-то платное и стоит немалых денег. Также чертежи следует сохранять в векторном формате SVG, EPS и т.п. Если его использовать нельзя, то в растровых PNG или GIF. JPG использовать нельзя, так как происходит размытие линий в чертежах и в статьях нередко потом можно видеть чертежи с пятнами. Это результат использования JPG.
Журналам как правило нужен текст в doc отдельно, а картинки отдельно. Это легко получить при помощи latex2rtf, а картинки сконвертировать в нужный формат, переименовать по шаблону и сложить в нужны каталог при помощи например скрипта на Баше.
Ещё файлы LaTeX текстовые, и поэтому хорошо индексируются системами контроля версий. Всегда можно иметь лог изменений, ветки, откатиться назад и держать бэкапы можно например в приватном репозитории на Bitbucket, а не возиться с файлами на флешках наподобие Моя_статья_старая_версия.doc
Вобщем следует вывод, что компьютер не заменяет мозг. Даже если вы используется математические системы, это не отменяет необходимости думать над тем, что вы хотите получить от компьютера.
Так что получается, что в результате импортозамещения нет никакой разницы с этой точки зрения. Где-то здесь нарушена логика, т.к. логично что русский МК должен программироваться из русской ОС.
Читал на форуме Миландра, что они не занимаются разработкой инструментальных средств под Linux, но «интересуются данным направлением». Интересно, кто-нибудь здесь знает как у них обстоят дела с этим направлением сейчас?
По поводу добавление симуляции МК… Данную функцию добавить у нас неоднократно просили. Трудоёмкость создания интерактивного симулятора, подобного Proteus большая, а нужность и полезность — сомнительная.
Целиком полагаться на симулятор при отладке устройства на МК — очень вредная идея. Взять и смоделировать схему с МК целиком можно далеко не всегда. По опыту работы с Proteus, он корректно симулирует только AVR. Уже для PIC-контроллеров я искал у себя в программе несуществующие баги, так как симулятор неправильно неправильно смоделировал прошивку. Есть жалобы на некорректную реализацию MSP430.
Протеус имел смысл, когда МК прошивали самодельным программатором от LPT-порта, а профессиональные программаторы были недоступны. Сейчас внутрисхемные отладчики и простое контрольное оборудование доступны даже студентам, отладочные платы для любых МК тоже продаются в огромных количествах, так что все действия, которые выполняются при помощи Протеуса можно выполнить при помощи современных отладочных комплектов.
Вобщем, я считаю, что с МК лучше работать в железе на отладочное плате, а не в симуляторе.
dpkg --add-archtecture i386
Ищите более подробную инструкцию.
В openSUSE, который вы упоминали, нужно установить пакеты, которые имеют суффикс 32bit. Нужно их устанавливать используя пакетный менеджер zypper:
zypper install libraryname-32bit
Вместо libraryname подставить имя нужной библиотеки. Её можно узнать через zypper search.
Ваши проблемы с запуском на 64-разрядной системе вероятно связаны с отсутствием в последней ia32-libs. Это комплект библиотек, который дублирует 64-разрядные библиотеки. Без него соответственно 32-разрядное ПО не запустится. Гуглите ia32-libs ubuntu.
Сам иногда использую LibreOffice для написания тезисов на 1-2 стр. с 1-2 рисунками без формул.
От себя добавлю, что ПО САПР вообще-то платное и стоит немалых денег. Также чертежи следует сохранять в векторном формате SVG, EPS и т.п. Если его использовать нельзя, то в растровых PNG или GIF. JPG использовать нельзя, так как происходит размытие линий в чертежах и в статьях нередко потом можно видеть чертежи с пятнами. Это результат использования JPG.
Журналам как правило нужен текст в doc отдельно, а картинки отдельно. Это легко получить при помощи latex2rtf, а картинки сконвертировать в нужный формат, переименовать по шаблону и сложить в нужны каталог при помощи например скрипта на Баше.
Ещё файлы LaTeX текстовые, и поэтому хорошо индексируются системами контроля версий. Всегда можно иметь лог изменений, ветки, откатиться назад и держать бэкапы можно например в приватном репозитории на Bitbucket, а не возиться с файлами на флешках наподобие Моя_статья_старая_версия.doc