jcxz

Прям беда эти 250нс! :smile3009: И что за задача такая, интересно, требующая прерывания в 1МГц?? Ага "реализованы десятки проектов" и после этого не знаете, что получить такие частоты прерывания крайне проблематично - не знаете?? Имхо - это вроде как почти самоочевидно. Сомнения берут в десятках проектов... И каким образом кстати произведены все эти замеры с точностью до десятков нс? Вы умудрились воткнуть щуп осциллографа прямо в AHB? :blink: Поделитесь вашим бесценным опытом! B)

Где написано? И что? 12 - только вход + прерывание выполняющейся в фоне команды + время на загрузку кода (prefetch) ISR + выполнение ISR + выход ISR + prefetch фонового кода. И prefetch - вещь длительная из из flash. У Вас откуда прога выполняется? Наверняка из флешь. И какая частота флешь?

Буферизацию задают именно станции, так как в начале после коннекта, выдают поток с максимальной скоростью канала, гораздо больше скорости самого потока. И длится это в течение бывает до нескольких сотен КБ. Я много работал с интернет-радиостанциями (сам писал своё интернет-радио) не надо мне сказки рассказывать. Вот это и есть - кривой подход и непонимание принципов буферизации потока. Если после этих 32 байт как Вы начали играть будет приостановка потока на миллисекунды - что делать будете? Хрипеть и булькать? А если после 1КБ? Корректная реализация буферизации: 1.Заполнить буфер как минимум на N секунд данными и только после этого начать выводить звук. 2.В процессе вывода звука (когда звук уже включен) отслеживать положение указателя заполненности буфера и при приближении оного к верхней или нижней границе, делать передискретизацию потока с плавным повышением или понижением sample rate. "Смешались в кучу люди кони..." То был Ethernet сейчас уже вайфай... И какие 5 сек на 64КБ??? Обычно радиостанции сейчас все не менее 128кбит/сек. А чтобы буфер реально работал, он должен быть заполнен около 50%. Итого 64/2/(128/8) = 2 секунды даже на 128кбит/сек, что очень мало - дырки и паузы при нестабильном потоке от станции будут постоянно. А как позвольте поинтересоваться Ваше радио компенсирует ошибку частоты своего генератора и генератора источника потока? Что такое погрешность частоты генератора в курсе? ;)

Не верю в "меньше секунды". 1. У Вас там канал - Ethernet - даже в этом случае необходимо довольно большое время для запуска (auto negotians, DHCP, подключение к серверу потока и т.п.). 2. Серверы вещания интернет-радиостанций как правило рассчитывают на пребуферизацию потока у клиента. Т.е. - после соединения первые несколько секунд (а это десятки или даже сотни КБ) выплёвывают в ускоренном режиме, чтобы создать на пользовательском устройстве некоторую буферизацию потока, чтобы не было разрывов звука при задержках потока данных. Т.е. - начинают вещание как бы из на несколько секунд из прошлого. Таким образом - это не "планшеты тормозят при старте", а это они корректно работают с буферизацией (выкачивают достаточный объём заполнения буфера и только потом включают звук). Если в Вашем радио это не так - значит это кривая реализация. Вижу на схеме у Вас внешнее ОЗУ на 64КБ - видно для буферизации потока. Размер его слишком мал - встречал много радиостанций, которые при старте сразу делали пребуферизацию на несколько сотен КБ. На таких радиостанциях Ваше радио будет терять часть данных при старте. Да и при последующей работе могут быть потери, так как приостановки потока до нескольких секунд - это обычное дело, а буферизации Вашей схемы не хватит чтобы это скомпенсировать (64КБ - на 320кбит/сек это всего 1.5сек буферизации). Достаточный буфер - это около 1МБ.

Я понимаю конечно что "чукча не читатель...", но может всё-таки прочитаете и попытаетесь понять, что я писал? Каждый периферийный блок в LPC1768 тактируется своей частотой, получаемой делением системной частоты на некий делитель. У Вас этот делитель чему равен? Вы уверены, что он ==1? Это не инструкции, это си-исходник. Который может компилиться в любое число инструкций. Если хотите получить ВЧ-прерывание, придётся писать на асм. Если рассуждать логически, то перед написанием ПО, надо сперва прочитать документацию на железо. Вы её как видно не читали. Иначе бы знали, что такое стэкинг на входе/выходе в ISR и сколько тактов он занимает. Это десятки тактов. Странно как-то вроде смотрите на картинку, а видите нечто, чего на ней нет... %-) Я вот вижу, что только GPIO висит на системной шине (AHB), таймеры же - на периферийной шине (APB). И для каждого блока на APB есть свой делитель, в отличие от AHB, где все работают на частоте AHB. Чувствую что ваяется очередное ногодрыгательное "творение"... А Вы, позвольте спросить, кроме таймера и GPIO, про какую-нить другую периферию LPC хоть читали? Да и вообще - хоть даже про таймер-то прочитали? И если да - зачем так много инструкций в Вашем ISR? Можно получать периодическое прерывание от таймера не записывая в него ничего.

Не верю!

Смотрится это по мануалу, в частности "Simplified block diagram" и "Architectural overview". И выставляются соответствующие делители частоты для каждой периферии. Процессор работает на своей частоте, периферийные блоки - каждый на своей. В LPC1768 можно каждому периферийному блоку назначить свой делитель частоты. Получить 1МГц прерывание можно, только писать ISR надо оптимально. И возможно на асм, чтобы не грузить CPU на 100% одним только ISR.

где-то вкралась лишняя инверсия

Вносить изменения в схемотехнику крайне не желательно. Этот вариант оставим на крайний случай.

"...ни на миг не..."

Надо! Пускай не 12, но хотя-бы 2-4. Ну и что что Вам хватает 500? Мне вот 1Мб иногда не хватает. Задачи у всех разные. Очевидно, что скорость не у putty, а у драйвера порта. А корректно написанный терминал опрашивает набор доступных скоростей для данного порта и позволяет выбрать одну из них. Кривых терминалок полно, кто-ж спорит.

Очевидно должны быть на официальном сайте?: http://infocenter.arm.com/help/index.jsp

Рекомендации обычные: Изучаете задачу, оцениваете какие её части потребуют максимальных вычислительных ресурсов. Далее - пробуете оценочно прикинуть реализацию этих частей на разных типах ядер. Смотрите - хватает-ли быстродействия? Один и тот же алгоритм (с разными опциями), будет занимать разное число тактов при реализации на разных ядрах. Скажем простой пример - необходим симметричный КИХ ФНЧ, точности коэффициентов достаточно 16бит. C55xx например потратит 1 такт на каждые 2 порядка такого фильтра. Cortex-M4 с его DSP-командами наверное примерно по 4 такта на порядок (не уверен) + доп. затраты на организацию цикла и циклическую адресацию (которые в C55xx будут ==0). Но если скажем нужны 32-битные коэффициенты фильтра (это скорее уже БИХ), то разница будет уже не такая существенная. Плюс - в DSP-процессорах бывает и его компоненты заточены под интенсивные вычисления, не только ядро. Например в C5502 вся внутренняя ОЗУ разбита на 8 блоков, каждый блок - 2-х-портовый (т.е. позволяет 2 обращения по чтению/записи за такт). Это из-за того, что система команд C55xx позволяет за один командный такт выполнять до 5 обращений к памяти (только за данными, не считая выборки команд). Там к ОЗУ от ядра идёт сразу 5 шин данных. В ARM это не нужно, так как за такт может быть не более одного обращения за данными от ядра. Зато DSP как правило хуже работает на алгоритмах управления (там где "вермишельная логика переходов"), хуже работает с прерываниями и мультизадачностью (из-за большого количества регистров). Например для ядра C674x вообще видел рекомендации от TI запрещать прерывания на участках где делается плотная обработка массивов данных с максимальной оптимизацией. Архитектура DSP заточена именно под обработку потоков данных без прерываний и ветвлений. ARM более универсален, но на потоковой обработке конечно проигрывает настоящему DSP. Так что надо прикинуть чего в программе будет больше и взвесить всё.

Я покупал OM13054. Стоит около 20евро на ru.farnell.com. Может и дешевле есть. В ней только косяк, что мало периферии на разъёмы выведено :(((( Но для осцилла хватит. Её можно и в J-Link превратить - segger.com даёт такую прошивку для этой платы. И ETB там есть ;)

Эквивалентный режим - вещь малоинтересная. Раз Вам интересно заниматься осциллографом, лучше бы взяли отладку на LPC4370 и лучше характеристики получили-бы ;) Тем более она не дорогая.

Ну АЦП LPC4370 таких опций не имеет вроде как. Но Ваше АЦП какую максимальную sample rate имеет? Во сколько раз ниже 80MS/s? :laughing: И какую разрядность? 12бит как у LPC4370? А то что M4-ядро хорошо загружено будет, так у LPC4370 ещё два свободных ядра есть. Да и M4 не 100%-но загружено будет. Оставшейся производительности ядер будет больше, чем у полностью свободного STM32F303 :laughing: Всего лишь в 9 раз хуже чем у LPC4370. :laughing:

В сэмплах в памяти МК? С помощью какой-то периферии? Я не знаком с периферией STM32F303 - не нужно.

Конечно для детского варианта 32MS/s (и даже сколько-то больше) вполне хватит. А о серьёзных характеристиках в сотни MS/s и не говорил никто. Находит где/в_чём? Во внешнем аналоговом сигнале заведённом на ногу компаратора в МК? А толку?

В том коде что я привёл - полное доказательство. Знающий асм для Cortex-M может это увидеть. Не 3 такта, Слесарь хотел вообще-то 32MS/s. Берём калькулятор и считаем: 204/32 = 6.375 Но и на бОльших частотах должно хватить быстродействия. PS: Для непонявших: Приведённый код только ищет точку синхронизации (перехода через "0") сигнала. Это самая ресурсоёмкая часть работы которую должен выполнять процессор в осциллографе. Больше этот код ничего не делает. Остальная работа - по отображению картинки это уже ерунда по требуемой вычислительной мощности. Остальная работа тривиальна. В LPC4370 282КБ внутреннего ОЗУ - за глаза хватит. Скажем выберем: N=4, M=10. Тогда будем обрабатывать DMA-блоки по 20*4*10 сэмплов. И того потребуется 2 DMA-буфера по 20*4*10*2 байт. Это ни о чём при 282КБ имеющихся.

Имелась в виду частота сэмплирования АЦП. Я осциллограф не делаю. Делает ТС. У него в ТЗ указана только одна частота выборок. Нужность реализации других частот - его дело. И "у меня" тоже делается. Вам код инициализации АЦП LPC4370 привести? Сами юзермануал прочитайте. Для тактирования АЦП LPC4370 можно использовать отдельный PLL с пачкой опциональных делителей после него - никаких таймеров не нужно. В смысле??? Вы смысл кода вообще поняли? Какое болтание и какая разница сколько тактов будет в AdcExec_14??? В точке AdcExec_14 уже найдено, что в последних 20 сэмплах точно есть переход. А значит этот участок выполняется 1 раз на одно срабатывание синхронизатора. Т.е. - 1 раз на один отображаемый кадр. Т.е. - не более чем 50 раз в секунду. И какая разница сколько там тактов? Да хоть 200 хоть 2000. Не понял о чём речь Возьмите учебник по командам Cortex-M и разберитесь в коде. Этот код ищет момент перехода через "0". Это самая ресурсозатратная часть алгоритма. О чём писал AlexandrY и утверждал что её невозможно сделать на Cortex-M для данной частоты. Всё остальное - ерунда. Нет, неправильно. До вычитания данные беззнаковые, после вычитания получаются знаковые данные, дальше анализируется их знак. Какой таймер??? Вы опять за своё. Похоже что ничего не поняли..... Почему неинтересно? Именно так и работает любая обработка потоков данных. Именно так и можно сделать поиск точки синхронизации для осциллографа - вполне рабочий вариант. И почему не гарантированный? Какая разница сколько тактов? Ещё раз - Вы не поняли ничего в работе этого кода. Этот код должен запускаться на каждый принятый блок сэмплов от DMA. Размер такого блока должен быть достаточно большим (там приведено условие 20*N*M чем больше N и M - тем меньше загрузка CPU - эффективнее обработка).

Похоже у Вас нет опыта обработки потоков данных.... Никаких "слово за словом", никаких таймеров и прочей аппаратной лабуды. Работа идёт с потоком данных, находящимся в ОЗУ. Данные поступают в ОЗУ пакетно - блоками большой длины через DMA. В рассматриваемом случае - из внутреннего АЦП LPC4370. Процессор просматривает поток DMA-блоков в поиске старта синхронизации (откуда начинать захватывать кадр для показа на экране). Все времянки (отступы, размеры кадра и пр.) конечно задаются в сэмплах, так как частота их известна. А теперь открываем описание системы команд Cortex-M4 и пишем обработчик DMA-блоков данных, который ищет момент перехода через "0": PUBLIC AdcExec ;extern "C" void AdcExec(u32 *data, s32 sign, u32 zero); ;R0 - указатель на блок сэмплов для обработки (упакованы в 32-битные слова - по 2 сэмпла в каждом в битах 0...11 и 16...27 - в таком формате их выдаёт АЦП LPC4370) ;R1 - знак предыдущего значения сигнала ;R2 - текущее смещение нуля (в мл. 16 битах, остальные биты ==0) ;в блоке сэмплов [R0] находится 20*N*M сэмплов принятых в очередном блоке DMA ;каждый сэмпл - 12-битный беззнаковый, так что 0 - при мин. значении напряжения, 0xFFF - при макс, 0 шкалы АЦП == 0x800 histerezis EQU 10 ;если желаем гистерезис M EQU ... AdcExec: PUSH {R4-R11, LR} LSLS R3, R1, #1 BMI AdcExec_01 SUBS R2, R2, #histerezis IT MI MOVSMI R2, #0 B AdcExec_02 AdcExec_01: ADDS R2, R2, #histerezis LSRS R3, R2, #12 IT NE MOVNE R2, #0FFFh AdcExec_02: ORRS LR, R2, R2, LSL #16 MOVS R2, #M ;количество повторов 20*N для обработки всего блока сэмплов LSLS R3, R1, #1 BMI AdcExec_21 ;поиск <0 AdcExec_11: LDMIA R0!, {R3-R12} ;грузим 20 сэмплов в регистры SSUB16 R3, R3, LR ;вычтем смещение нуля из 2-х сэмплов SSUB16 R4, R4, LR ;повторим для остальных 18 сэмплов SSUB16 R5, R5, LR SSUB16 R6, R6, LR SSUB16 R7, R7, LR SSUB16 R8, R8, LR SSUB16 R9, R9, LR SSUB16 R10, R10, LR SSUB16 R11, R11, LR SSUB16 R12, R12, LR ORRS R3, R3, R4 ORRS R3, R3, R5 ORRS R3, R3, R6 ORRS R3, R3, R7 ORRS R3, R3, R8 ORRS R3, R3, R9 ORRS R3, R3, R10 ORRS R3, R3, R11 ORRS R3, R3, R12 ORRS R3, R3, R3, LSL #16 AdcExec_12: BMI AdcExec_14 ;переход если в предыдущих 20 сэмплах обнаружен переход через 0 вниз LDMIA R0!, {R3-R12} ;грузим следующие 20 сэмплов в регистры ;N раз повторим команды AdcExec_01...AdcExec_02 ;... SUBS R2, R2, #1 AdcExec_13: BNE AdcExec_11 ;обработали весь блок сэмплов, не нашли перехода через 0, ждём следующего блока от DMA POP {R4-R11, PC} AdcExec_14: ;здесь получено состояние "обнаружен переход через 0 вниз" в одном из предыдущих 20 сэмплов R0[-20]...R0[-1] ;сделаем более точное обнаружение с точностью до сэмпла и перейдём к захвату потока сэмплов для отображения AdcExec_21: ;здесь напишем аналог процедуры AdcExec_11...AdcExec_13, но для поиска перехода в >=0 Участок AdcExec_11...AdcExec_12 обрабатывающий 20 сэмплов, должен выполняться примерно за 23 такта (расположим его в самой быстрой памяти, в ОЗУ например). Берём калькулятор и видим, что на обработку одного сэмпла нужно немного более 1 такта. Так что о каких "намного больше, чем 6" речь? Может у Вас на STM32F303 это так, но для LPC4370 всё ГОРАЗДО быстрее. Частота развёртки - в смысле частота сэмплирования АЦП? При чём тут таймер??? Она задаётся тактовой частотой АЦП и её не трудно установить какую нужно.

Так зачем себе отказывать? Хочется - побалуйте себя. :-) Отладки с DSP сейчас найти думаю не проблема, какое-то время назад на C5535 (вроде) даже бесплатно раздавали.

Ну Вы сравнили палец с тапком DSP с ARM! :rolleyes: Смотря какой TMS. То же упомянутое тут ранее DSP-ядро C674x из состава OMAP L137, на его макс. тактовой 450МГц и с его возможностями параллельной обработки и два канала по 80MS/s потянет имхо без проблем. Не говоря уже о многоядерных монстрах из TMS320. Даже если там средненькое ядро C5502 на 300МГц тактовой - тоже без проблем обработать такой поток - писал под него много на асм. Там вся память поделена на 8 независимых банков, каждый из которых позволяет два 16-битных доступа за такт (независимо от других банков). И полно команд делающих MAC-операцию одновремнно с записью/чтением ОЗУ и ещё в параллель такой команде часто можно ещё одну параллельную команду выполнить на другом АЛУ например. Тогда уж лучше 32-битный ARM.

Да. Многие внешние АЦП после такого теряют актуальность. Естественно смещение 0 может быть любым. Конечно предварительно его вычесть надо. Команды LDM на кучу регистров и SSUB16 в комплекте с ORRS/ANDS творят чудеса. B) Слесарь хотел 32МГц вроде? На 204МГц тактовой МК это больше 6 тактов на сэмпл - если ядро занимается только поиском синхры - должно хватить за глаза. А гистерезис - он вообще не требует дополнительной вычислительной нагрузки.

Эх, жаль на тренировку пора бежать, а то я бы привёл Вам код поиска перехода через 0 для ARM который успеет на 204МГц ;) Правда без предварительного ФНЧ конечно.