jcxz

LPC4370. Нет, там просто. Но если в STM похоже на то, как сделано в LPC, то Вам надо понять разницу между обычным доступом через SPI и memory-mapped режимом (который STM32 тоже похоже начал уметь). Я вижу, что вы не понимаете что именно вам нужно. В LPC в memory-mapped режиме возможно было только чтение. Здесь, подозреваю, аналогично.

Это что! Я после PIC16F84 (с 8-словным стеком) следующим шагом перешёл на TMS320VC5502. Вот это был рывок так рывок! Есть такие человечки. В цирке. С большими красными носами обычно ходят.

Остапа понесло.... Так может говорить только человек, не имеющий понятия не только о MSP430, но и о x51-ядре. Я думаю скоро мы узнаем, что и ненавистная винда, она тоже - порождение "древнючего" 51-го. Да вообще нужно всех этих недоделанных экономистов уволить, которые не могут правильно посчитать экономический эффект, и работают себе в убыток. И на их место взять Эдика. Он всё как надо разрулит С чего это? Keil тоже умеет x51.

Да.

Такая проблема есть и на IAR_7.80.4 под win7. Тот же самый IAR под win8 - такой проблемы не наблюдается.

Хех! В последний раз, когда я занимался DSP, я переходил на CGT v6.1.23. Как давно это было оказывается - целых 2.1.77 версий назад! А может стоит примерить?

Если в процессе разработки, то это - самое то. Это может быть хорошей встряской для ПО. Которая может проявить скрытые баги. Так же как и смена уровней оптимизации. А вот спустя N лет, когда уже подзабылась архитектура проекта, часто бывает "не трожь его, чтобы оно не воняло". Особенно если оно не своё

Есть промежуточное звено: MSP430. Там очень удобно энергосбережение сделано.

....а если добротность высока, а интенсивность падающего звука - относительно мала, то имхо как раз собственные колебания через N периодов будут превалировать над вынужденными (если в спектре падающей волны есть множество гармоник, в том числе и на резонансной частоте - вот они в конце концов и возобладают над вынужденными). Обычно колебательные контуры усилителей на пьезокристаллах имеют довольно большую добротность, даже приходится принудительно её задавливать когда она не нужна. "Не соответствует" - в смысле: Форма огибающей колебаний не соответствует падающей волне (её спектру, амплитудам спектральных составляющих), из-за всех указанных факторов. А из контекста вопроса, как я понял, ТС ожидает увидеть на контактах пьезокристалла форму напряжения, пропорциональную падающему на датчик звуковому давлению. Типа осциллограммы звука. Так не получится.

Поляризуется. А в чём разница между "давлением" и "интенсивностью"?

Ничему не соответствует. Пьезо-кристалл УЗ-приёмника - возбуждается и колеблется на собственной резонансной частоте. Возбуждается конечно от энергии падающей на него звуковой волны. Колебания могут возникнуть даже от одной волны и потом плавно затухать (в зависимости от добротности колебательного контура). Читайте про колебательные LC-контура - работают аналогично.

Да ничего он не построит, не беспокойтесь. Разве что очередную свистоперделку-мигалку лампочками.

Годах этак в 2013-2014 делал я проект кардиографа, с анализом снимаемых данных. Было там множество и фильтров и БПФ. И отдельно - анализаторы этих данных, выявляющие различные патологии в сердечном ритме. Всю теорию и математику делал не сам - мне алгоритмы (даже с исходниками) предоставили коллеги из Будапешта. Они эту теорию нарабатывали и клинически обкатывали до этого несколько лет (почти 10 лет!) на базе какой-то больницы и под руководством тамошнего профессора с соответствующей специализацией (кроме него в команде были и другие врачи). Обкатывали по базе накопленных данных в клинике, да и с реальными пациентами насколько помню имели дело. Обкатывали алгоритмы на PC (win). Следующим этапом работ было: перенести эти обкатанные алгоритмы для выполнения непосредственно на устройстве, снимающем кардиограммы. Сначала, по плану работ, я должен был только написать код, снимающий данные и управляющий всей периферией (драйвера) и предоставляющий поток входных сырых данных с АЦП коду мат.обработки и забирающий результаты обработки и передающий их в канал. Но, так как девайс был на базе DSP, а коллеги, писавшие и отлаживавшие это всё на PC, не имели никакого опыта разработки ни под DSP ни вообще под embedded, то у них не получилось: не хватало производительности DSP-ядра для обработки. Сильно не хватало - в несколько раз. Поэтому адаптировать код под DSP было предложено мне. Я сам в предметной области (кардиологии) ничего не шарил (да и сейчас не особо). Но будапештсткие коллеги сделали для меня подробное описание своих алгоритмов, очень качественное. И предоставили полные исходники. Я это перенёс на девайс. Потом оптимизировал (для ускорения). Хватило си-оптимизации, но с активным использованием intrinsic-функций и на чистом си. Код хорошо оптимизировался компилятором (проверялось и допиливалось и допиливалось много итераций по ассемблерным листингам). Итого: удалось добиться, что при включении всех опций обработки и анализа (макс. вычислительная загрузка), загрузка DSP-ядра была около 20%. А теперь внимание! Делалось это всё на OMAP-L137 с тактовой ~295МГц (не максимальная конечно) для обоих ядер (ARM+DSP). Обработка на DSP-ядре велась в double-значениях (на этом ядре double - поддерживается системой команд, 2 такта на double-MAC-операцию если не изменяет склероз). DSP-ядро занималось исключительно математикой прикладной обработки данных. Все манипуляции с железом и потоками данных делало ARM-ядро (чтоб разгрузить DSP). Итого: DSP-ядро C674x с аппаратным double при тактовой ~295МГц загружено на ~20%. А вы говорите абдурина. +теория и консультации в прикладной области от команды врачей. А не пиво-инет. PS: ОЗУ там потребовалось немного для всей этой обработки: всё влезло во внутреннее ОЗУ + дополнительно 1...2 МБ SDRAM.

Возможно в старой плате стоит чип более старой ревизии, чем в новых. И в новой ревизии чипа или изменили дефолтные значения каких-то полей в его регистрах (и эти дефолтные значения не изменяются кодом инициализации чипа) или добавили новые битовые поля, которые ранее были зарезервированы, и в которые теперь код инициализации пишет неверные значения. Сравните мануалы на старую и текущую ревизию чипа.

Понятно. Всё равно - кривоватый метод. Он даже не кодонезависимый. Ибо - включившись в любой произвольный момент в поток кодированных данных, невозможно однозначно определить границы кадра и правильно декодировать кадр из потока. Придётся применять дополнительные методы валидации кадра.