Jump to content

    

InxSergey

Участник
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

0 Обычный

About InxSergey

  • Rank
    Участник

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Я как раз таки не об оркад говорю, а об Cadence, там полный мрак (хотя стоит гораздо дороже). А рассчитывать на какие-то готовые библиотеки совсем не разумно. В нормальной компании есть свои правила ведения библиотек да и вообще разработки и схем, PCB, ПО. Покупать Cadence за миллионы и при этом даже не организовать нужным образом библиотеки...
  2. Интересно что именно в Allegro лучше? В AD правила гораздо более гибкие и больше возможностей для настройки.
  3. И все же я требую видео по созданию графики УГО в Cadence))) Оно снимет все вопросы. Что там может быть удобнее? Хоть детальную графику, хоть создавать м/с? Я имею ввиду не Orcad (урезанный по функционалу), а самый навороченный последний Cadence Allegro
  4. В чем проблема? Если вы мало работали с AD или вовсе не работали и не знаете как это сделать, это не означает, что это невозможно. Попробуйте в Cadence хоть что то создать) будет что обсуждать.
  5. Не знаю как в Ментор, но в Сadence Allegro достаточно открыть редактор УГО посмотреть на это УБЛЮДСТВО закрыть и забыть про это ПО навсегда. Кто-то видео тут хотел выложить, просьба к пользователям Alegro: выложите видео создания УГО)) чтобы раз и навсегда отбить желание у всех задумавшихся об его использовании. И как такое можно продавать (я уж не говорю что за такие деньги) в 2019 году? И самое главное как можно это купить? Даже в бесплатном KiCade и то GUI на порядок лучше. Про неудобство или неправильную организацию библиотек в Altium - полная чушь. Altium поддерживает разный подход к организации библиотек, выбирайте по вкусу Для совместной разработки есть Vault И хотелось бы услышать что именно могут эти супер программы, чего нельзя сделать в Altium-е?
  6. модуль на МК

    Вся в проблема в том, что то, что для одного "РАБОТАЕТ" может оказаться для другого "НЕ РАБОТАЕТ". И чтобы такого не произошло необходимо четко определить критерии что есть "РАБОТАЕТ" и в каких условиях (температурных, электромагнитных и т.д. и т.п.).
  7. модуль на МК

    Не понятно, что надо реализовывать? Необходимо конкретизировать требования. А так возможно надо то а возможно надо это. Если по пунктам расписать что должно быть реализовано (сначала пункты касающиеся железа, затем софта), то будет больше шансов найти АДЕКВАТНОГО исполнителя который будет понимать за что берется.
  8. Так много написано, а о заработной плате ни слова
  9. Проще, думал об этом, но не пробовал, есть сомнения: как будет считать строки при наличии вложенных файлов (#include), закомментированных строк? Номер строки __LINE__, а что такое номер файла? Стандартными методами можно автоматически получить только имя файла и если есть номер файла (но что это и как получить) и номер строки, то в сервисном ПО из исходников можно вытащить и имя функции. Еще одна проблема возникает если после прошивки прибора исходники изменились, и соответственно все номера съехали. Сохранять вместе с каждой серийной прошивкой к примеру map файл проще чем весь проект, состоящий часто из исходников разбросанных по разным репозиториям. Получается напрямую строки наиболее надежный и понятный способ.
  10. SWO можно растянуть хотя бы на несколько десятков метров? Есть ли способ автоматической подстановки адреса функции, по аналогии с именем - __FUNCTION__ RS-232 на мегабите? А вот по поводу RS485/422 дельный совет.
  11. UART не всегда можно на такой скорости запустить, бывает что устройство находится на значительном удалении от приемной стороны.
  12. При трассировки необходимо передавать информацию о функции в котором произошло событие/ошибка. Есть предустановленный макрос __FUNCTION__ который возвращает указатель на имя функции в которой используется. Но пересылать строкой (например через UART) все имя слишком накладно(слишком много букв :) ). Рациональнее было бы пересылать ID этой функции в несколько байт. Но вот как автоматически сформировать эти идентификаторы? И самое главное как потом расшифровать их обратно в читабельный вид на принимающей стороне (сервисное ПО принимающее данные по UART). Первое, что приходит на ум: формировать файл конфигурации (вопрос только как?) содержащий массив строк/указателей на строки, соответственно слать в терминал индекс функции из этого массива, а на обратной стороне в соответствии с этим же файлом расшифровывать посылку и выводить уже строку с именем. Собственно вопрос в том как формировать этот файл (автоматически при компиляции) и как при выполнении функций трассировки получить соответствующий индекс?
  13. Для Open Source ПО есть условия что при дальнейшем распространении продуктов созданных на их основе обязательно предоставление исходного кода в открытом доступе. Собственно вопрос: а как с этим делом когда OpenSource продукт является лишь средой разработки конечного продукта. При этом в конечном продукте не содержится ни одной строчки кода из этого OpenSource продукта. Например разработана некая программа в IDE Eclipse, но ни одной строчки кода из самого Eclipse это ПО не содержит, т.е. в данном случае Eclipse только среда разработки. Соответственно тот же вопрос и по свободным компиляторам (GCC), KiCad и т.д.
  14. Компоненты NoBom

    Похоже только если свой скрипт писать по созданию ПЭ3/BOM а там учитывать соответствующие атрибуты. Жаль что в стандартных скриптах из коробки такой возможности нет.
  15. Есть ли в каком то виде библиотека (dll, lib...) для работы с SWO на стороне ПК? Для J-Link есть SWO Viewer, но его функционала не хватает. У ST вроде бы тоже есть свой Viewer. Но хотелось бы написать свой. Есть ли какие инструменты для J-Link, ST-Link...?