adnega

Нужно пробовать, т.к. при этом преобразовании тоже не все гладко. Что делать с точками, которые лежат на оси X? Расщеплять на две комплексно-сопряженные?

Частота Fs увеличилась, но вам нужно частоту фильтра оставить прежней, поэтому она в безразмерном (деленном на Fs) виде как бы уменьшилась, т.е. характерные точки как бы стянулись к нулю по частоте.

Да. Но это лишь один из вариантов решения, т.к. у вас ничего кроме коэффициентов нет. Того же спада АЧХ у вас скорее всего не будет, т.к. порядок фильтра не изменяется. Если вы хотите те же характеристики спада АЧХ, то нужно пересчитывать фильтр полностью, т.к. может потребоваться увеличивать порядок фильтра (коэффициентов станет больше). Дык, вроде делить на 1.21

По вашим коэффициентам можно построить ноль-полюсную диаграмму для вашей частоты. При изменении Fs угол всех точек должен пропорционально измениться и получится новая ноль-полюсная диаграмма. Превратить ее в коэффициенты a и b. Я бы так попробовал.

Нашел старенький, но ответ.

Это понятно. Но как компилятору объяснить, что порядок в reg_list имеет значение? GCC выдает предупреждение, но как заставить соблюдать порядок номеров регистров?

А так попробовать: u32 *p0 = ..., *p1 = ...; uint i = ...; u32 j0, j1, j2, j3; asm( "p01: LDR %0, [%4, #8 * 1] \n" " LDR %1, [%4, #8 * 2] \n" " LDR %2, [%4, #8 * 3] \n" " LDR %3, [%4, #8 * 4]! \n" " SUBS %6, %6, #4 \n" " STMIA %5!, {%0,%1,%2,%3} \n" " BNE p01" : "=r"(j0), "=&r"(j1), "=&r"(j2), "=&r"(j3) : "r"(p0), "r"(p1), "r"(i) : "cc", "memory"); j0 = j0; j1 = j1; j2 = j2; j3 = j3;

Стоп. Тут же IAR ерунду пишет: 0xC778 STMIA R7!, {R6,R5,R4,R3}

Вариант_2 вас устроил только на половину. Может, LDRD/STRD добавит вторую половину. Я так понимаю проблему: вы хотите явно использовать имена регистров, но при этом хотите, чтоб компилятор о их использовании знал, и какие-то дополнительные вещи делал на автомате? Не совсем понятно, чем вариант_1 плох? Почему важен именно порядок регистров?

А можно попробовать LDRD/STRD ?

А так получится (указать явно имена регистров)? void vPortStartFirstTask( void ) { __asm volatile( " ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */ " ldr r0, [r0] \n" " ldr r0, [r0] \n" " msr msp, r0 \n" /* Set the msp back to the start of the stack. */ " cpsie i \n" /* Globally enable interrupts. */ " svc 0 \n" /* System call to start first task. */ " nop \n" ); } Это довольно опасные инструкции. Например, у вас могут быть данные не выровненные - тогда их нельзя использовать.

А что запрещает сделать .s-файл и запускать из Си реализованную там функцию? Зачем вы мешаете компилятору делать свою работу?

Не проще массу умножить на расстояние до центра масс?

Вроде, для каждой задачи должен быть свой инструмент. Для пайки посуды есть мощные паяльники в виде топора.

А как вы поняли что стирается именно нулевой сектор?

Один канал или несколько? Сколько? А что линкер разместил по этим адресам? АЦП 12-битный. Вы в 8 битном режиме от него данные получаете? Без исходника ничего не понятно. Сомнительное решение.

Чтоб что-то сделать с флешь нужно как минимум разлочить работу с ней. По мне так это тоже самое, что MPU разлочить. Да, в нештатной ситуации MPU может дать дополнительную информацию о проблеме, а неразлоченный контроллер флешь (зависнет?) не даст эту самую флешь повредить. А так как ТС уверяет, что флешь стирается даже с локом сектора, то: - выполняется полный код снятия защиты с сектора, стирание сектора, и уж точно разблокирование контроллера флешь по всем правилам (т.е. и MPU тоже будет временно отключен); - либо никакого стирания флешь нет (опять же MPU тут не поможет).

А как это принципиально поможет? Перед корректной записью флешь нужно временно регион MPU отключать, поработать, а затем включать? Что помешает коду с ошибкой на этапе "поработать" наломать дров при выключенном MPU?

У Заказчика всяко может быть. Например, он изменяет какие-то уставки, которые в реальном времени щелкают каким-нить мощным контактором, от помехи которого МК сбоит - статистика в этом случае меняется кардинально. Самое простое - сделайте индикацию HardFault.

Кста, внешняя SPI флешка под IMAGE - рулит.

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

Я для таких случаев всегда использую копию обновления во флешь. Т.е. обнаруживаю корректное обновление на карте, если требуется обновить, то записываю его в регион IMAGE во флешь МК, делаю перезагрузку. Загрузчик видит корректное обновление в IMAGE, принимает решение обновить APPLICATION, стирает APPLICATION, расшифровывает IMAGE и копирует его в APPLICATION, проверяет корректность записи и ставит штамп с CRC32, если все ок. После этого APPLICATION можно запускать. И если когда-то APPLICATION поплохеет, всегда есть копия в IMAGE для автоматического восстановления.

Если у вас нету отладочной консоли (UART), то во внешнюю память можно сбрасывать стек, извлеченный из недр HardFault, а дальше - хоть ногодрыгом кинуть значение регистров и стека во внешнюю память.

Кста, у меня загрузчик даже исправное приложение запускает не сразу, а через 200мс (быстрый старт) - 5000мс (медленный старт, после NVIC_SystemReset), чтоб можно было к нему как-то подключиться. У вас каким образом выполняется обновление? По какому каналу?