AndreyVN

Похоже, здесь сразу несколько проблем. Одну разглядел, в отсутствии модели корпуса, AD решает, что сколько занимают пады, столько занимает и корпус, поэтому все элементы воспринимаются как Collision. В порядке эксперимента - растащил все в стороны, крестики исчезли, но situs все равно пишет: Error : Pad DO1-5 Appears to be unroutable. Violation against Rule - Clearance_All Clearance Constraint (Gap=0.1mm) (All),(All) Detected. Как проблему с корпусом решить?

Нарисовал footprint из полигонов, сконвертировал их в pad'ы, присвоил designator'ы. Кликаю по схеме, вижу, что все pad'ы распознаются правильно. Запускаю DRC - ошибок нет. Что не так: 1) Если на паде лежит элемент - он сразу выделяется как Clearance Violation, хотя элемент электрически связан с этим падом (картинка: все пады с крестиками). 2) Запускаю трассировку: Error : Pad DO1-4 Appears to be unroutable. Violation against Rule - Clearance_All Clearance Constraint (Gap=0.1mm) (All),(All) Detected. И так по всем pad'ам на которых лежат элементы. Там не должно быть никакого Gap, они электрически связаны. DRC это подтверждает. Что я не правильно сделал? PS: Раньше эти полигоны лежали на слое Top и все трассировалось нормально, решил сделать красивее, перенес подключение DC/DC в footprint и начались проблемы. AD23.7, DC/DC TPS 61023

Мысль здравая, но нет похожей команды, посмотрел на всякий случай. Похоже, что с кодом все нормально. Передача происходит настолько быстро, что пользовательская часть программы не успевает отловить изменение статуса передатчика, CPU крутится где-то в дебрях ОС.

В линейке TI есть изделие CC1310 (СС13xx-CC26xx) на борту которого процессор Cortex-M3 и радиомодуль, управляемый Cortex-M0. Программирую это через CodeComposerStudio, пользуюсь TI-RTOS, пересылаю пакеты данных с одного модуля на другой. Все работает, кроме возможности анализировать статус передатчика. Это нужно чтобы запускать АЦП во время радиотишины. Отправляются пакеты вот такой командой EasyLink_transmit(&txPacket); команда ставит пакет в очередь и всегда возвращает EasyLink_Status_Success. То есть, отловить факт передачи по возвращаемому коду не получается. В составе команды, которую исполняет RF модуль есть 2 байта статуса, которые отражают именно текущий статус команды. Вроде, то, что нужно! An integer telling the status of the command. This value is updated by the radio CPU during operation and may be read by the system CPU at any time. Однако, все попытки анализировать это поле cmdStatus = ((volatile RF_Op*)RFCommand)->status; Не дают никакого результата, status всегда 0x2000 и до выполнения команды и во время и после. Что я делаю не так ??? PS: RFCommand это вот такая структура: struct __RFC_STRUCT rfc_radioOp_s { uint16_t commandNo; //!< The command ID number uint16_t status; //!< \brief An integer telling the status of the command. This value is //!< updated by the radio CPU during operation and may be read by the //!< system CPU at any time. rfc_radioOp_t *pNextOp; //!< Pointer to the next operation to run after this operation is done ratmr_t startTime; //!< Absolute or relative start time (depending on the value of <code>startTrigger</code>) struct { uint8_t triggerType:4; //!< The type of trigger uint8_t bEnaCmd:1; //!< \brief 0: No alternative trigger command<br> //!< 1: CMD_TRIGGER can be used as an alternative trigger uint8_t triggerNo:2; //!< The trigger number of the CMD_TRIGGER command that triggers this action uint8_t pastTrig:1; //!< \brief 0: A trigger in the past is never triggered, or for start of commands, give an error<br> //!< 1: A trigger in the past is triggered as soon as possible } startTrigger; //!< Identification of the trigger that starts the operation struct { uint8_t rule:4; //!< Condition for running next command: Rule for how to proceed uint8_t nSkip:4; //!< Number of skips + 1 if the rule involves skipping. 0: same, 1: next, 2: skip next, ... } condition; } __RFC_STRUCT_ATTR; Эта структура сидит в ОЗУ и поле статуса должен менять Cortex-M0 то-ли через прямой доступ к памяти, то-ли через прерывание. Я собираю это поле в массив и просматриваю в JTAG-отладчике.

Ищите сетку Фибоначи. Насколько я знаю, для произвольного количества точек задача их равномерного распределения по сфере не имеет аналитического решения. Решается только для определенных чисел. Численно народ решает через механические аналогии, например, распределение заряженных частиц, считают силы, решают уравнения движения и ждут пока частицы перестанут двигаться.

Это я виноват, за недосказанность. Эта схема рекомендована для переключения питания радио-модулей (у меня SIM-800), у него очень большие (до 2.0А) пиковые токи и как следствие, обвязка танталовыми конденсаторами большой емкости. А переключение происходит очень редко и пропадание одного пакета данных вполне допустимое явление (они и так иногда куда-то пропадают). Так, что предложенные объяснения выглядят очень правдоподобными.

Доброго дня! Вопрос по ключу на последовательно включенных P-канальных MOSFET. Не могу понять, зачем в таких схемах в цепи затвора ставят конденсатор? Есть подобная схема, где наружу торчат стоки, и тоже в цепи затвора 0,1 мкф.

Увидел, что у Вас цвета 'Mono', помню, что отверстия действительно становились черными при выборе монохрома, а вот что слетало, уже забыл. В общем, смирился и распечатал как есть.

Всем привет! Можно ли как-то изменить цвета holes при печати негатива? Негатив делаю черз OutputJob, плату накрываю сплошным полигоном на фиктивном механическом слое. Затем в OutputJob определяю фиктивный полигон черным, верхний слой и Multi Layer белыми. Печать отверстий включается галочкой, явного управления цветом для них не предусмотрено. Настройка цветов отверстий на вкладке Layer, категорически в OutPut Job не запрыгивает. И еще, при таком методе получения негатива исчезают надписи, если они были вырезаны на медной заливке.

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

Это не результат ручной трассировки, а результат работы Situs'а. Есть и другие "оборванные" проводники, которые не объединяют соседние пады. Т.е. вопрос откуда берутся недоведенные дорожки остается открытым.

Altium Designer 23.7.1 не доводит трассы до точки назначения. Как думаете, это глюк или что-то с правилами не так? Если кликнуть по не доведенной дорожке, то она отрисуется до следующего пина, как и должно быть. И таких участков очень много.

Ну кое-как решiл. Нагородил прямоугольных Pad'ов с одинаковым Designator и одинаковым Jumper ID. Выглядит все корректно и маски в областях перекрывания падов и цепи развелись правильно. Ну и термальные отступы появились, поскольку все пады легальные. Пока не знаю, что скажет DRC. Конечно, такой метод применим к не сильно сложным конфигурациям.

У меня 17.0.11 (зато легальная 🙂 К сожалению такой менюшки нет. Вот так выглядит.

Создал Pad нестандартной формы как полигон, посадил на него реальный pad. Все работает, за исключением одной засады. Если этот Pad сидит на земле, то внешняя заливка делает отступы только от реального pad'а (который под полигоном). А внешний полигон сливается с внутренним, из которого сформирован pad. Можно как-то заставить AD сделать термальные отступы для полигона в полигоне, когда цепи этих полигонов совпадают?