adnega

Задержка точно не будет зависеть от скважности, а будет зависеть только от значения в CCR4. Фронт может начинаться и от нуля и от точки сравнения: С оверсемплингом не работал.

Самое простое настроить запуск по TRG1=TIM1_CC4. Канал 4 таймера 1 программируете на заданную задержку, а ШИМ получаете с помощью оставшихся каналов. Биты регистра TIM1_CR2. Можно задавать, что для данного таймера будет TRGO и TRGO2.

А что можете посоветовать в LQFP144 корпусе (на замену EP1C3, например)? Spartan-3AN?

Или светодиоды включать не последовательно, а параллельно, чтобы понизить напряжение и повысить ток нагрузки.

Можно повысить частоту до 100 кГц. Использую утилитку для расчетов.

gcc с ключем "-mno-unaligned-access" (принуждает packed собирать побайтово). По-умолчанию, для Cortex-M3 он использует невыровненый доступ и для него использует ldr вместо побайтовой сборки. Но я ручками в МК включил исключение для невыровненого доступа, чтобы знать потенциально опасные места. Разумеется, начал спотыкаться на всех невыровненных данных, даже на содержащих атрибут packed. После этого добавил packed, где нужно, чтобы не словить там ldrd. После этого можно генерацию исключения отключать как и ключ "-mno-unaligned-access". Согласен. Тут я больше из-за академического интереса переборщил. Столкнулся с этим первый раз и решил в дебри погрузиться.

По протоколу настройки прилетают крайне редко. А с самими настройками работа очень интенсивная. Если я тупо добавлю packed, то все многобайтные типы будут побайтово собираться - а мне так не надо (на самом деле для Cortex-M3 и выше можно сборки избежать в расчете на лишний такт при обращении к невыровненным данным). Я могу в протокол добавить фиктивных байтиков перед структурой настройки, чтобы они уже получались выровненными. Я могу для протокола выделить тип-близнец настроек, но с packed. Могу просто memcpy устроить или присвоение структуры. Вариантов много и не все так очевидно. Очевидно одно, что исходник плохой и его нужно править. Собственно, я весь этот разговор затеял в контексте того, что исходник нужно писать так, чтобы от уровня оптимизации, компилятора, слишком быстрого или медленного исполнения - результат не зависел и всегда был корректным. Кста, исходник мой, но 10-летней давности. Все это время биарник работал без нареканий в большом количестве изделий 24/7 и вообще считался отлаженным (светодиодные информационные остановочные табло). Собирал когда-то сборкой от klen. Сейчас пользуюсь ланчпадовской сборкой, lto и прочими плюшками - вот и повылезало при переносе на новое железо.

Везде, где в исходнике есть приведение типов, если может получиться невыровненный доступ нужно ставить соответствующий атрибут структурам. Точнее, если выравнивание не гарантируется, то ставить packed. Дальше уже дело компилятора это правильно трактовать, и с этим проблем не замечено. В подавляющем большинстве случаев в данном исходнике к какой-то части пакета некого протокола осуществляется доступ через указатель на структуру. У всех этих структур просто нужно добавить packed. В другом наборе случаев данные организованы так, что они принципиально выровненные и тут править ничего не надо. Я отлавливаю какие-то промежуточные варианты: например, структура с настройками выровнена и сами настройки хранятся выровненными, но по протоколу могут прилететь настройки уже не выровненные в памяти. Как поступать в таких случаях?

Это не гарантирует, что при следующей сборке не появятся новые LDRD и компания. Проще в исходнике искать приведение к типу "(some_type *)".

Это gcc и структуры, помогает __attribute__((packed)), но в некачественном исходнике нужно искать все места с потенциальной проблемой. Сейчас включил UsageFault для невыровненных данных и ключем "-mno-unaligned-access" попросил компилятор не использовать фичу Cortex-M по работе с невыровнеными данными. Отключил сторожевой таймер. Гоняю - жду дампов от UsageFault.

Четыре клока АЦП (на F051). Кста, у других (F103) может быть по другому.

Конкретно мой случай описан в ES: Все очень долго работало в большом количестве изделий, но потом начали проявляться очень редкие события неинициализации АЦП, видимо, после смены компилятора или ключей компиляции. Сначала долго пытался отловить сам факт, затем пытался локализовать причину. Но подогнали образец, где вероятность глюка была высокая. Затем нашел причину в ES. В копилку историй "вчера-сегодня": Сейчас бьюсь со старым проектом, исходник там "так-себе" - полно наглых приведений типа. В итоге сейчас получаю HF при использовании инструкции ldrd на невыровненных данных. До этого у меня была устойчивая иллюзия, что Cortex-M3 и выше на невыровненных данных теряют такт, и на этом проблемы заканчиваются. Это так, но не для всех команд! Видимо, старый компилятор не оптимизоровал до использования ldrd, и все работало.

Я тоже из этой предметной области. Тогда предложу два варианта: - таймер может сам себе делать запрос DMA-транзакции и одной пачкой менять несколько регистров; - можно несколько таймеров объединить в режиме master-slave и один из таймеров может быть счетчиком импульсов для второго. Ну, и ваш вариант с добавлением фиктивного элемента в буфер, по-моему, весьма годен - сам так делаю. Кста, для светодиодных панелей TIM+GPIO не самый хороший вариант. Я использую FSMC, SPI и немного внешней дискретной логики. Для каждой шины 1-wire использую один таймер с двумя каналами (TX и RX). Для типа WS2812 использую один канал TIM+DMA+фиктивный элемент в буфере.

Это можно сделать при помощи самого таймера, другого таймера (в режиме slave или master), DMA. Я с таймерами STM32 очень плотно работаю, причем, во всяких экзотических применениях - если подробнее опишите задачу, могу попробовать предложить аппаратное решение.

Это очень опасных подход в архитектуре ПО. Если таймер нужно остановить быстро, то это нужно делать аппаратно, а не программно. Иначе какой-нить обработчик прерывания легко десяток/несколько тактов насыпать может. Если архитектура будет корректная, то от качества библиотеки качество ПО будет слабо зависеть. Несколько раз сталкивался с обратной ситуацией, когда код становился быстрее и все переставало работать: например, включение АЦП в некоторых STM32 (F051, емнип).

Допускаю, что там много проверок "лишних" и т.п., но не понимаю всего трагизма: обычно это только на уровне инициализации периферии, а это ну пусть 5% кода. Или я чего-то упускаю? Кста, я сам плотно на своих либах сижу и тоже вставляю проверку/отладку, но отключаемую дефайнами.

Я пользуюсь WinCupl, но вещь довольно своеобразная и глючная. Может, из-за современного железа и ОСи.

Я пользуюсь TL866CS, в том числе и для старых PLD.

Да, но размер и положение задается в скрипте линкера (и в настройках проекта?).

Я бы еще корректность инициализации кучи проверил.

В обработчике HF можно узнать значения регистров R0, R1, R2, R3, R12, LR, PC, XPSR. Например, по PC (и LR) в листинге можно найти кусок кода с проблемой.

Попробуйте на GNDDetect подать GND.

В чем сложность показать подключение?

Очень помогло если бы вы показали подключение, все сигналы между контроллером и программатором.

У вас Software reset, а нужно железный. Частоту уже рекомендовали понизить.