SCH/PCB муки

На меня несколько раз в год нападает желание найти замену P-CAD 2006, который,  как известно, умер, стух и сгнил. И раз за разом понимаю, что нету достойного соперника. Такое ощущение, что программисты кучи инженерно-девелоперских контор соревнуются в том насколько убогим и неюзабельным получится сделать своё программное обеспечение.

Сегодняшние претенденты: Cadence SPB и Zuken Cadstar.

1. Cadence SPB. На форуме Электроникса нашёл замечательную фразу от апологета данного программного продукта: “без тренинга новичок в данном продукте не сможет даже создать проект, не говоря уж о его дальнейшей разработке”. И это полная правда. На самом старте проекта приходится выбирать и компилировать какие-то стандартные-нестандартные библиотеки, писать в локальную библиотеку во внешнем текстовом редакторе какие-то слова и т.п. И это чтобы создать проект!

Ладно, предположим, что мы его таки создали, пользуясь туториалами. Открываем “Design Entry HDL” – штатную программу рисования электрической принципиальной схемы. Дизайн из конца восьмидесятых, кириллица в принципе не поддерживается, зато поддерживаются какие-то рюши, которые мне на данном этапе даром не нужны – всяческое моделирование и т.п. Нарисовал по туториалу схему, надо бы её транслировать в плату – а фигушки. Нету паттерна для выбранных микросхем. Я обычно рисую библиотеки полностью сам, но здесь я только начал разбираться с программой, и сплошное недоумение при виде кучи возникающих окон, мессаджбоксов с ошибками на голом месте. Мышкой ткнул в пустое место – получи мессаджбокс о том, что “какая-то команда не задана”. Вы серьёзно? Зачем использовать мессаджбоксы для некритических ошибок, уроды???

В общем, транслировать схему в плату так и не удалось пока. Буду еще ковырять, но уже видно, что по удобству работы оно на десять (если не на сто) голов ниже Пикада, который так любят хаять некоторые приверженцы этого поделия.

2. Zuken Cadstar. У этого программного продукта есть большое достоинство – наличие экспресс-версии с ограничением в 50 компонентов и 300 падов на проект. То есть маленькие платки и вообще научиться пользоваться можно совершенно легально, в отличие от.

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

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

Найденные проблемы в схемном вводе – не нашёл как скрывать атрибуты символа, отображение которых мне не требуется. На каждом символе в итоге куча лишних надписей. Рисование связей между элементами очень неудобное. В Пикаде даже не задумываешься об этом – щелкнул и повёл, как надо – так и провёл. Здесь же всё гораздо кривее и непонятнее. Но, возможно, это дело привычки.

Нарисовал схему, стал трассировать плату. При щелчке мыши на компоненте не факт, что выделится весь компонент, а не его часть. Может вылезти окошко с предложением выбрать что я хотел выбрать, но, в отличие от Пикада, курсор мыши не становится сам на первый элемент в списке. Лишние бесячие телодвижения. При разводке платы есть выбор между ручной разводкой, полуавтоматической, автоматической, автоматической для чипов памяти и “речной” разводкой. Нормально пользоваться можно только полностью ручной. В полуавтоматической и автоматической я так и не понял как заставить проводить проводники под углом в 45 градусов. Для чипов памяти не каждая цепь разводится, корреляции не нашёл пока. А речная тупо срезает путь – получается похоже на Топор.

Зукен Кадстар показался получше Каденс Аллегро в смысле юзабилити, но всё так же на десяток голов ниже Пикада. Явно видно, что разработчики пытались в некоторых местах копировать Пикад. Некоторые слямзенные идеи весьма удивляют своей недоделанностью – как с окошком выбора в разводчике.

Индусы в Микросеми

На днях пришлось обратиться в техподдержку компании Микросеми. Проблема заключалась в следующем: нужно поставить СофтКонсоль – интегрированную среду разработки для программирования процессоров, входящих в системы-на-кристалле этой конторы – и софтовые, как Core8051s и встроенные АРМы. СофтКонсоль требует перед своей установкой обязательную установку утилиты программирования FlashPro версии не ниже 5.0. На официальном сайте даётся возможность скачать только последнюю версию этой утилиты – 10.0. Проблема заключается в том, что по-видимому проверяется только одна цифра перед точкой версии, и инсталлятор делает вывод, что установленная версия (10.0) гораздо меньше требуемой 5.0. Полный бред, с моей точки зрения. С этим и был послан запрос.

Пришёл ответ от господина с весьма показательной фамилией “Падала”. Он посоветовал установить целиком всю Libero SoC – приличного размера солянку из десятка разношёрстных утилит. Которые на той машине нафиг не сдались.

Посмеялись и забыли – я даже отвечать не стал. Просто нашёл где-то в закромах версию 8.3, с которой СофтКонсоль радостно заинсталлилась. А сегодня полез на рабочий комп за файлом с переводами и увидел второе письмо от господина Падала, где он интересовался, исполнил ли я его инструкции. Пришлось ему рассказать эту телегу, но по-английски, поэтому скорей всего более вежливо, чем мне бы хотелось.

Где живёт uint32_t?

Начал писать заголовочные файлы для SmartFusion. Работа предполагается в SoftConsole. Есть несколько поименованных областей памяти, с которыми надо будет работать. Описаны они примерно следующим образом:

typedef struct
{
volatile uint32_t    TSW[16];
volatile uint32_t    SA[30][16];
}MKORX_TypeDef;

#define        MKORX_BASE        (0x40050000)
#define        MKORX            ((MKORX_TypeDef *) MKORX_BASE)

Дальнейшее использование, соответственно, стандартным образом: MKORX->SA[4][2] = 0xDEADBEEF;

Дык вот здесь есть малюсенькая такая тонкость, которая заключается в том, что тип uint32_t описан в файле stdint.h и его надо хотя бы единожды в проект включить. Иначе, возникает ошибка компилятора, которая в принципе не гуглится и по этому описанию понять – а в чём собственно ошибка? – не получится:

expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘TSW’

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

Лень и пыль

Дорешивал домашку к четвёртой неделе MITx 6.002x (да, дедлайн 8 апреля, а сегодня уже 7 – ну не было у меня возможности раньше заняться). И столкнулся с непонятностью.

По задаче нужно вычислить ток зависимого источника тока – мосфета, причём довольно хитро расположенного. Забудем про то, что ЭТО с моей точки зрения не цепь нифига – слева я имею ввиду. В смысле – ну там же разрыв!!! А вот с их точки зрения цепь. Потому что “воспользуйтесь законом Кирхгоффа о напряжении в контуре”. НУ ВЕДЬ НЕТУ КОНТУРА!!! Ладно, фиг с ними, предположим, что он есть. Едем дальше, загвоздка дальше. Ток мосфета вычисляется по формуле (K*(Vgs-Vt)^2)/2, где Vgs – напряжение, приложенное к затвору относительно истока, а Vt – напряжение срабатывания (threshold) (работаем мы типа в режиме сатурации насыщения!). Плюс надо вычислить напряжение Vout. Формула опять же по Кирхгоффу: Vout = Vdd-Rl*Id. Ток мы узнали на прошлом этапе, причём ток через транзистор вместе с резистором, поэтому нам резистор Rs второй раз учитывать не нужно.

Дык вот, решаю я квадратное уравнение. Получаю два корня, весьма близкие, но всё же. Выбираю меньший. Высчитываю по нему Vout. Ввожу оба ответа. И опаньки, Vout подходит, а Id, с помощью которого я Vout высчитал – нет. Ыыыы. Крыша едет.

Разгадка проблемы кроется в том, что я купил новые батарейки для своего инженерного калькулятора и когда менял их занёс под экран пылинку. Решив, что она мне и не мешает вовсе, я не стал разбирать калькулятор заново. А когда решал задачу эта пылинка мне обошлась привидевшейся точкой между целой и децимальной частью детерминанта. Разница между моим и правильным значением тока составила пятнадцать тысячных. Для расчета напряжения такая погрешность не вызвала проблем, а значение тока у меня не приняли…

H3P4 – как посчитать ток через идеальный диод

Какой-то несусветный ужас в домашней работе к третьей лекции. Схема в общем случае упрощается до такой: три параллельных плеча, первое – источник напряжения 7,5 вольт последовательно с резистором 5600 Ом, второе – источник напряжения 3.25 вольт последовательно с идеальным диодом, третье – нагрузочный резистор 5600 ом. Вопрос – какой ток будет течь через диод?
Первая мысль – диод идеален, сопротивление у него нуль, значит откидываем сопротивление нагрузки – туда ток не потечёт. И ответ тогда – бесконечность. Фигушки. Неправильная логика…

Два часа сражался с этой задачей. А оказалось всё просто – нарисовать эквивалентную цепь Тевенена и посчитать её. Дело тридцати секунд :(

Надо меньше думать привычными категориями и начинать пытаться использовать знания, которые даёт профессор Агарвал. Не зря ж он их даёт в конце концов…

Lab 2b

Задача такая. Есть два источника напряжения. Первый – меандр в диапазоне от 0 до 1 вольта. Второй – синусоида в диапазоне от -1 до 1 вольта. Надо получить из них сигнал V1/2+V2/6.
Вроде как всё просто – делитель на второй сигнал на три и затем сложить эти два сигнала – получится по половинке амплитуды от каждого. Но нужно при этом свести влияние делителя второго генератора на первый к минимуму. Тут всё зависит от того насколько нам это реально критично, т.е. какой ток мы собираемся с этого дела выбирать. Потому что если критично, то я бы тупо использовал операционные усилители – и дело с концом. Но здесь всё проще, так как про ток нам ничего не сказано. Ставим после делителя резистор на побольше, и последовательно с первым генератором резистор с таким же сопротивлением. И суммируем сигнал – получается верный ответ.

А теперь о проблемах. В обсуждениях на все вопросы об этой лабораторной очень часто разные люди загадочно говорят “не думайте, что двух резисторов достаточно, поставьте третий, не стесняйтесь”. Так вот, я не понимаю, как все эти люди добились правильного результата при помощи только трёх (не четырёх, как у меня) резисторов. Потому что резистор на общий провод в этом случае начинает делить результат после суммирования, а надо наоборот – сначала разделить, а лишь потом суммировать. Видимо я чего-то не догоняю…

MITx 6.002x

Наконец-то начался семестр в программе обучения MITx 6.002x. Очень интересно на какой по номеру неделе я брошу это занятие.

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

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

Далее нужно сделать домашнюю работу. Первое задание – сравнить количество энергии в БигМаке и батарейке для электромобиля. Вообще там могло быть всё что угодно, это задача тупо на арифметику первого класса. А вот дальше начинается уже ТОЭ. Придётся вспомнить законы Кирхгофа. На втором курсе они ну никак даваться не хотели, с тех пор я их позабыл, теперь придётся вспомнить. Третье задание – опять закон Ома, на этот раз нужно будет высчитать рассеиваемую мощность.

Интересно, когда мне надоест?

JTAG, BSDL и сопутствующие

..it is true that asking regexpes to parse arbitrary HTML is like asking Paris Hilton to write an operating system..

Заинтересовался протоколом IEEE-1149, который JTAG. Хочу попытаться освоить его на низком уровне. Вроде как всё довольно просто – конечный автомат Тестового порта доступа (TAP) управляется линией TMS по переднему фронту TCK, данные вводятся по линии TDI, выводятся по TDO. Плюс необязательная линия TRST, про которую можно не думать. Автомат достаточно неплохо расписан в стандарте – всё довольно стройно и логично.
Далее начинаются усложнения. Стандарт описывает интерфейс и требования к протоколу, а вот сам протокол может быть с некоторыми ограничениями каким угодно. Для каждого устройства, оснащенного портом JTAG, производителем пишется BSDL-файл, в котором данный протокол и описывается. После чего данный файл выкладывается или не выкладывается (если производитель очень жадный) на всеобщее обозрение. Также, в BSDL-файле может содержаться дополнительная информация о внутренней структуре устройства и способах доступа к этим кишкам всё через тот же JTAG – попросту говоря, описывается что нужно сплясать на входе TDI, когда автомат состояний находится в правильном состоянии (Capture-IR или Capture-DR – пока этот момент я не особо уяснил).

Теоретическая информация – это хорошо, но я уясняю информацию только в практическом ключе – поэтому захотелось изваять простенький JTAG-комплекс. Взять программатор, который изначально был разработан для работы с совершенно другим самописным протоколом и попробовать подцепиться им к какому-нибудь камню. Для начала мне бы хватило правильно считанного значения IDCODE.

Я не люблю делать одноразовую работу, поэтому к задаче решил подойти издалека – написать свой собственный парсер BSDL-файлов. Возвращаясь к фразе из эпиграфа – структура этих файлов представляет собой обычный исходник, похожий на исходники любого другого языка программирования. И подойти к нему с точки зрения обычных конфигурационных файлов довольно проблематично. Поэтому я снова заинтересовался задачей синтаксического анализа. Пока что сижу и изучаю форму Бэкуса-Наура, расширенную форму их же, выбираю инструмент, которым буду пытаться описать грамматику BSDL, пока что по принципу количества информации лидирует yacc и его форки вроде bison. Освоение синтаксического анализа впоследствии может пригодиться для построения скриптовых интерпретаторов для внутренних задач.

Забавности в повседневном САПР

В P-CAD PCB, где мы разводим платы, в меню File есть две подменюшки. Одна – Close, другая – Clear. PCB – это MDI-приложение, но с одной особенностью – всегда должен быть открыт документ, пусть даже и Untitled :)
Отличие File->Close от File->Clear вот так сразу и не видны. Когда в приложении открыт только один файл они совершенно равнозначны. Понятие MDI-приложения подразумевает возможность открытия нескольких файлов в одном окне приложения. И, если честно, за фанатичное следование парадигме MDI следовало бы отрубать руки и делать лоботомию программисту. Потому что, например, Excel (из 2003-го Офиса) определяет наличие себя в памяти при запуске (уж не знаю как – атом ставит или просто перебирает по именам) и открывает файл внутри уже запущенной копии. При этом на панели задач всё-равно _не_ одна кнопка, но развернуть один лист на полный экран на одном мониторе, а другой – на другом при этом становится невозможно. Но это я отвлёкся.
Если в P-CAD PCB открыто несколько дизайнов плат, то File->Close закрывает текущий, а File->Clear еще и открывает вместо него новый дизайн. Причём, сохраняет при этом расположение и размеры окна. Не знаю где это может пригодиться, но почему бы и нет. Лично я предпочитаю открывать дизайны плат каждый в своей копии PCB, благо на это действие никаких хуков не стоит.

DDoS для контроллера

Забавный эффект получили. Есть устройство, которое управляется по шине магистрального канала обмена (MIL-STD-1553B). Протокол обмена в упрощённом виде выглядит так:

(1) Посылка данных -> (2) Ожидание векторного слова, сигнализирующего о готовности квитанции о выполнении в подадресе -> (3) Запрос квитанции -> (4) Посылка запроса о телеметрии -> (5) Ожидание векторного слова, сигнализирующего о готовности телеметрии в подадресе -> (6) Забор телеметрии из подадреса.

Так получилось, что выставлять флаг занятости на время обработки данных нам нельзя, следовательно контроллер принимает все без исключения посылки от МКО. Контроллер CISC (IP-ядро 8051 в ПЛИСе), работает на пониженных частотах – около 5 МГц. Скорость передачи по шине МКО – 1Мбит/с. В итоге получается, что вместо обработки данных пунктов (1) и (4) все процессорное время тратится на обработку запросов (2) и (5). Самый настоящий DDoS 😀