adnega

На MCO обычно 8 МГц от ST-Link`а.

MCO1 - это 8 МГц с ST-Link`а? Тогда не понятно как у вас USB вообще работает. У меня много разных NUCLEO на ST-Link_v3, и МК там со своими кварцами. Есть одна STM32F767 со старым (вторым) ST-Link - на нем частота MCO для таргета 7.99989 МГц. У третьих - примерно 7.98890 МГц (частота плавает в районе 0.01 МГц). На Discovery со вторым ST-Link`ом - 8.00062 МГц

Нужен исходник. Какие именно у вас значения. Не замечал, чтоб таймеры в STM32 как-то не так делили, точность определяется только точностью опорной частоты. Кста, внутри не кварц, а RC-генератор. У него точность хуже и примерно 1% (как в вашем случае) - это типичная ошибка. Вам нужен именно кварцевый резонатор/генератор в качестве опоры.

Предделитель и делитель должны быть на единицу меньше требуемого значения.

И я готовлю. Только беда: контроллер одновременно поддерживает два вида подключения модулей - "паравозиком" и "параллельно". Есть 8 модулей (например, цены на АЗС) их могут подключить паравозиком, но неисправность одного модуля приведет к неработоспособности оставшейся части. Поэтому есть альтернативное подключение: 8 портов для индивидуального подключения модулей. Первый тип, очевидно, SPI+DMA. Второй - FSMC+DMA (как бы octo-spi). Второй буфер получается из первого транспонированием. Транспонировать проще (меньше матана) чем два варианта setpixel.

Да.

У меня задача сложнее была нужно было выполнять транспонирование битов: есть 8 байт, нужно первые биты всех байт по порядку сложить в первый выходной байт, вторые биты - во второй и т.д. И делать это 100 раз в секунду, и байтов там под тыщу - вывод картинки на матрицу светодиодов. Делал с использованием BB. Вот бы одну инструкцию или трюк какой...

Думается мне, что все эти перекодирования кнопок матричной клавиатуры ничто в масштабе передачи по интерфейсу. Тут оптимизировать лучше не поток команд, а качество исходника на ЯВУ. Кто сказал, что "оптимально" - это ="быстро"? Я читаю, что "оптимально" это про качество исходника, его многократной применимости в других проектах, скорости разработки, защиты от глупых ошибок - денег в конце концов. Да, если нужен быстрый код, то UBFX + BFI - самый лучший вариант, и довольно универсальный. Но это ASM, совсем другие требования к разработчику, легко допустить ошибку, сложно сопровождать (например, битик в протоколе потребуется поменять местом или раскладка матричной клавиатуры поменяется из-за снабжения). И самое главное - это прибивание гвоздями исходника к процессору. Я бы завел одну структуру с битовыми полями под клавиатуру, вторую - под пакет протокола. В исходнике - присвоение всех битов протокола битам клавиатуры. Если меняется клавиатура - меняем только ее поля в структуре. Аналогично для протокола. Дальше пусть компилятор оптимизирует - я показал на что он способен.

У ТС Cortex-M3, а в них эта фича встроенная. У М4-моделей - опциональная. У М0 - отсутствует. У М7 и прочих - не в курсе. Забавно, что jcxz указал, что фича может отсутствовать, но когда я дополнил, что и инструкций выбранных может не быть - вспомнили о М3. С М4 и М7 соглашусь, но М3-то есть без Bit-banding ?

Тогда можете показать Cortex-M без Bit-banding ?

Существует Cortex-M0. Есть там UBFX+BFI ?

У них за последние несколько лет (сужу по сайту) много в этом плане годноты. Если б это можно было закупать без проблем, то много чего мог бы импортозаместить из своей продукции.

В начале апреля КП на 200 шт К1986ВЕ92QI было со сроком 2 дня. Но шепчутся, что это остатки распродают, и больше не будет. Кто-то может прояснить ситуацию?

Как и Поэтому лучше не мудрить с ASM и сделать на Си.

Довольно старенький

typedef struct s_b { union { DWORD dw; struct { DWORD b0:1; DWORD b1:1; ... DWORD b30:1; DWORD b31:1; }; }; } s_b; void foo(void) { s_b src, dst; src.dw = var_1; dst.b0 = src.b10; dst.b1 = src.b11; dst.b2 = src.b12; dst.b3 = src.b8; ... dst.b28 = src.b23; dst.b29 = src.b20; dst.b30 = src.b24; dst.b31 = src.b25; var_2 = dst.dw; } Тупо в лоб на Си: Видим, что Си все сделает за вас (без сдвигов и масок). Правда, смежные битики в одну транзакцию не объединяет.

Довольно существенные ;)

Можно по-изучать map-файл - там быстро можно найти куда килобайты утекают.

Для этого можно использовать внутренние ПЗУ и ОЗУ. Можно подгружать код порциями по мере необходимости, расшифровывая/проверяя в процессе.

На той плате, что у меня есть, внешняя ПЗУ подключена по SPI. Если подключить ПЗУ на параллельную шину, то можно исполнять прямо из ПЗУ.

У меня есть LDM-HELPER-K1986BE1QI-WEB версии 1.05. Там подключена внешняя память: FLASH-NOR внешняя:128 Мб, SRAM внешняя:8 Мб. Думаю, можно из внешней флешки загрузить код во внешнее ОЗУ и там его исполнить. Прошивать, скорее всего, по UART - утилитка есть. Пока не использовал. Есть сомнения, что Миландр будет в будущем.

Вот еще объявление: Нужно проверить совместимость.

STM32F100CBT6B ?

ТС все правильно говорит. Не всегда CRC это вещь в себе, а требуется взаимодействие с внешним миром. У меня так сделано: DWORD crc32(const BYTE *buf, DWORD len) { DWORD *dw = (DWORD *)buf; CRC->CR = (1 << CRC_CR_RESET); len /= 4; while(len--) CRC->DR = __RBIT(*dw++); return __RBIT(CRC->DR); }; Финальной инверсии нет. __RBIT стандартная и есть в CMSIS (core_cmInstr.h) В G0 сделал так: DWORD crc32(const BYTE *buf, DWORD len) { DWORD *dw = (DWORD *)buf; CRC->CR = (1 << CRC_CR_RESET) | (1 << CRC_CR_REV_OUT) | (1 << CRC_CR_REV_IN); len /= 4; while(len--) CRC->DR = __REV(*dw++); return CRC->DR; }; Дефайны у меня свои - поэтому аккуратно.

Т.е. вы отправляете пакет с какими-то данными, а он в TX выдает что? Или вы так глубоко не копали, и у вас просто бинарник не работает на этих МК? PS. Мне как-то с производства прислали пакет с "не корректными" CAN-phy. Все оказались полностью исправными, но кто-то, не разобравшись, начал их выкусывать из изделий.