Axel

Такое не подходит?

??? На такой частоте 1мкФ керамика имеет такой-же, если не меньший импеданс, как и 100мкФ тантал (с учетом ESR). А чтобы не свистел - макс.напряжение в 10 раз больше реального.

А какие у Вас параметры проводников (width/space)?

Когда выходы подключаются к фрагментам с независимым (от контроллера) питанием - имеет.

Ну очень интересно: почему двухслойка? Проблем с ЕМС на филде не опасаетесь?

И то, и другое - легко, учитывая пару десятков пик внутренней емкости и общую (с кем-то) землю (если трансивер не изолированный). Резисторы можно считать, исходя из входной емкости пина (≤40р) и длительности фронта. Напр. для CAN (1 MHz) - 270 Ohm вполне подходят. Ну и да, КЗы всякие тоже никто не отменял...

Естественно не знаю, пока не увижу. Так что да,

Фраза: наталкивает на мысль, что доступ к софтовой считалке происxодит из разных потоков. Я бы начал поиск граблей с этого места.

Так все правильно у Вас и получается: 2 байта на битовые поля и 16 байт на все остальное. Или я чего-то не догнал?

Вы - ниспровергатель основ! Я всегда хотел быть таким

Если нужно периодически (и быстро) тоглить комплементарные пины, и для этого надо ОДИН раз установить их состояние, а потом просто, не анализируя текущее состояние, писать в регистр КОНСТАНТУ... А на транзисторах слабо?

Я высказал предположение, что: - в спектре сигналов (в данном случае) практически нет составляющих, для которых импеданс линий проявлял комплексный характер и, следовательно, отражений (практически) не будет - вероятная причина проблем - наводки (возможно RF). Для уменьшения чувствительности к ним я предлагал уменьшить сколь возможно пулл-апы Рассуждения об отражениях безусловно верны, но в данном случае (ИМХО) не релевантны.

Не соглашусь. Если над генерить "жестко" комплементарные сигналы - очень даже... Правда запихнуть такое в либу проблематично (к вопросу об издержках подхода)

Ну так об об этом и речь. В данном случае это I2C: скорость (как правило) невысока, длина линий (вероятно) небольшая, фронты (должны быть) нерезкие. Т.е. собственно для сигналов I2C реактивная составляющая импеданса несущественна и об отражениях можно не беспокоиться. Если в схеме не используется экзотика типа изоляторов, то активная составляющая импеданса в "0" близка к нулю, в "1" - близка к значению пулл-апов, на что и был намек (исходные предположения сделаны исключительно по субъективным впечатлениям от информации ТС).

Если pull-up резисторы >= 1к - как мертвому припарки (ИМХО). Более перспективно уменьшить пулл-апы Ом до 300 (если все абоненты держат 10mA и тока не жалко).

Не в этом случае, к сожалению... :laughing:

Дык... ТС сообщил, что перевод SCL в PUSH-PULL снимает проблемы. Похоже искать надо в цепях I2C. А вообще-то это удача - при переходе с Discovery на штатную плату известно, чего бояться :rolleyes:

При хардовой реализации слэйвов нет причин закладываться на неиспользование clock stretch...Показали бы осциллограмы, глядишь дурацких неадекватных советов поубавится... а может прибавится... Но точно что-то изменится

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

Так похоже поводов нет: если предположить, что реализация (в IAR) __aeabi_uread4 аналогична __aeabi_memcpy, то оба варианта идентичны по затратам.

Весьма вероятная причина. По DS минимальчая скорость фронтов у этой чипы - 0.1V/ns. Предполагаю, что на концах Ваших проводов фронты будут поболее 30ns.

Если: - 0.1% - это от всего диапазона (4096 попугаев) - спектр входных сигналов не содержит "высоких" (относительно частоты выборок АЦП) составляющих - выходные импедансы источников сигналов невысоки - источник опоры приличного качества и (по опыту) не менее 2 вольт - разводка, обвеска, питание соответствуют то реально...

В CrossWorks (GNU) работает это: extern void* __vectors_load_start__; extern void* __vectors_load_end__; ................................ uint32_t vt_length = (uint32_t)&__vectors_load_end__ - (uint32_t)&__vectors_load_start__; Имена взяты из map-файла. Может быть и в IAR возможно что-то подобное?

Если: - предыстория процесса несущественна, либо есть возможность восстановить ее после сброса - нет жестких ограничений на время активзации то с полным сбросом будет спокойнее...

Видимо не выживаться: внутренней подтяжки может элементарно не хватить для приличного уровня помех - там десятки килоом.