50MS/s ADC, LPC4370 - да или нет? Опции

[jcxz]

Возникла задача: оцифровать аналоговый сигнал с частотой ~ 50MS/s, разрядности хватит 8бит.
Режим измерения АЦП: кратковременный интервал (<100мкс).
Обработка сложная не нужна, нужно батарейное питание. Поэтому думаю использовать МК на Cortex-M.
Сначала думал АЦП-тракт построить на отдельном АЦП с параллельным выходом и завести поток на МК либо напрямую
(если в МК найдётся подходящий интерфейс, чтобы повесить внешний АЦП с необходимой скоростью) либо
через промежуточное FIFO для согласования скоростей (типа IDT72241).
Но потом у NXP обнаружил LPC4370 - 3-ядерный МК с АЦП на 80MS/s.
Вроде как раз то, что нужно! правда BGA и без флеши ((
Если его использовать, то схемотехника значительно упрощается и удешевляется. Да и наличие экономичного M0 очень подходит для батарейного питания (большую часть времени устройство будет находиться в ожидании, думаю в этом режиме держать включённым только одно M0-ядро).
Но я не имею опыта работы с линейкой LPC43xx. Имею большой опыт работы с LPC17xx и с многоядерными OMAP.

Есть здесь кто-то, кто имеет опыт с LPC43xx и конкретно - LPC4370?
Имеется ряд вопросов:
1. Как организована работа JTAG с разными ядрами? Есть-ли возможность одновременной отладки через один J-Link всех ядер?
Можно-ли управлять JTAGом ядрами независимо одно от другого (два стоят, третье - шагаем)? Есть-ли поддержка такой работы в IAR?
2. Насколько работоспособен ADCHS (высокоскоростной 12бит АЦП) в LPC4370? В LPC17xx сталкивался с проблемой большого шума
втроенного АЦП, из-за которой на большой скорости с ним практически нереально работать. Нет-ли в ADCHS подобной проблемы???

PS: А может народ знает - имеются-ли другие МК со встроенным АЦП порядка 50MS/s?

[scifi]

1. Как организована работа JTAG с разными ядрами? Есть-ли возможность одновременной отладки через один J-Link всех ядер?
Можно-ли управлять JTAGом ядрами независимо одно от другого (два стоят, третье - шагаем)? Есть-ли поддержка такой работы в IAR?

Я отлаживаю в Кейле (но собираю при помощи gcc). Там в настройках отладчика указывается, к которому ядру нужно цепляться через JTAG.
Пробовал отлаживать M0, там приходилось подключаться к M4, запускать M0, потом подключаться к M0 и отлаживать. В общем, геморрой. Наверное, что-то из этого можно автоматизировать, но мне не нужно было. В качестве адаптера использую LPC-LINK 2 с прошивкой CMSIS DAP.

2. Насколько работоспособен ADCHS (высокоскоростной 12бит АЦП) в LPC4370? В LPC17xx сталкивался с проблемой большого шума втроенного АЦП, из-за которой на большой скорости с ним практически нереально работать. Нет-ли в ADCHS подобной проблемы???

У меня пока до реальной работы с сигналами дело не дошло. Оцифровывал с небольшой скоростью, данные идут. На форуме LPCWARE видел упоминания шума. Где-то есть рекомендации по разводке, какие пины лучше не задействовать, чтобы меньше шумел АЦП. В крайнем случае можно останавливать ядра и/или переферию на время оцифровки. В общем, только жизнь покажет.

PS: А может народ знает - имеются-ли другие МК со встроенным АЦП порядка 50MS/s?

Я долго искал и ничего подобного больше нигде не видел.
Более того, этот МК стоит в разы дешевле, чем скоростной АЦП, который в нём сидит.

[jcxz]

Я отлаживаю в Кейле (но собираю при помощи gcc). Там в настройках отладчика указывается, к которому ядру нужно цепляться через JTAG.
Пробовал отлаживать M0, там приходилось подключаться к M4, запускать M0, потом подключаться к M0 и отлаживать. В общем, геморрой. Наверное, что-то из этого можно автоматизировать, но мне не нужно было. В качестве адаптера использую LPC-LINK 2 с прошивкой CMSIS DAP.

В IAR7.20 тоже вижу что в свойствах проекта можно выбрать или LPC4370_M0 или LPC4370_M4 - это ясно, это для какого ядра компилить данный проект.
А в свойствах отладчика есть вкладка "Multicore", но она не активна. И есть чекбокс "Scan chain contains non-ARM devices", но не знаю что там нужно вписывать в поле "TAP number" и вкладка
"Multicore", после установки этого чекбокса, не становится активной. У меня J-Link (и есть SAU510), но могу и другой купить какой нужен.
А Вы не пробовали не отключаясь от M4, подключиться к M0?
Я много работал с OMAP-L137, там 4 ядра, два из которых: ARM9 и DSP C674x. Так там просто: два отдельных проекта, но их можно независимо друг от друга коннектить каждый к своему ядру и, независимо от другого, управлять им (загружать прошивку, останавливать, запускать, шагать и т.п.). И всё это через один JTAG (SAU510) под CCS.

Где-то есть рекомендации по разводке, какие
пины лучше не задействовать, чтобы меньше шумел АЦП. В крайнем случае можно останавливать ядра и/или переферию на время оцифровки. В общем, только жизнь покажет.

Рекомендации я видел в даташите.
В LPC17xx шум проявлялся в виде редких неожиданных провалов напряжения до максимального уровня или нуля. Такое ощущение что происходил сбой в АЦП, а не какие-то наводки.
Вроде пробовал и останавливать - не помогало. Но в том проекте нужно было измерять постоянное напряжение, так что я делал много измерений, а потом убирал эти помехи медианным фильтром и вобщем это не проблема была. А в новой задаче необходимо оцифровывать поток быстроменяющихся данных на частоте 50МГц, там лишних замеров не сделаешь, ядро конечно можно остановить, но DMA должно работать.

Я долго искал и ничего подобного больше нигде не видел.

Спасибо! Вы сэкономили мне кучу времени

Вы с режимами пониженного потребления в LPC4370 не разбирались?
Как я понял из даташита, в sleep ядра можно переводить независимо друг от друга, но в более глубокие режимы - только целиком весь МК.
Мне был бы оптимален режим работы в качестве основного ядра: M0-подсистема, а ядро M4 - в deep sleep (или более глубокий сон). А когда нужна работа с АЦП - включается M4, делает работу и опять уходит в deep sleep. Но вроде так невозможно (((

[scifi]

А в свойствах отладчика есть вкладка "Multicore", но она не активна. И есть чекбокс "Scan chain contains non-ARM devices", но не знаю что там нужно вписывать в поле "TAP number" и вкладка

В Кейле совсем просто: при открывании свойств адаптера он сразу сканирует цепочку JTAG и предлагает выбрать в списке одно из трёх ядер.

Я много работал с OMAP-L137, там 4 ядра, два из которых: ARM9 и DSP C674x. Так там просто: два отдельных проекта, но их можно независимо друг от друга коннектить каждый к своему ядру и, независимо от другого, управлять им (загружать прошивку, останавливать, запускать, шагать и т.п.). И всё это через один JTAG (SAU510) под CCS.

Вот это я понимаю - софт для людей. Может быть, яры и кейлы подтянутся. А может и нет.

А Вы не пробовали не отключаясь от M4, подключиться к M0?

Пробовал. Там при старте запускается только M4, а M0 сидят в сбросе. Считается, что прошивка, исполняемая на M4, должна снять сброс с M0. Я пробовал подключиться отладчиком к M0 и дёрнуть соответствующий регистр, чтобы снять сброс, но ничего не вышло. Вывод такой: перед подключением отладчика к M0 нужно обеспечить отключение сброса M0.

Вы с режимами пониженного потребления в LPC4370 не разбирались?

Нет. Ни разу не приходилось экономить электроэнергию. Хотя у LPC4370 отключил тактирование ненужной периферии - уж очень заметно он греется.

[jcxz]

Пробовал. Там при старте запускается только M4, а M0 сидят в сбросе. Считается, что прошивка, исполняемая на M4, должна снять сброс с M0. Я пробовал подключиться отладчиком к M0 и дёрнуть соответствующий регистр, чтобы снять сброс, но ничего не вышло. Вывод такой: перед подключением отладчика к M0 нужно обеспечить отключение сброса M0.

Это понятно - можно в начале main() для M4 вывести M0 из сброса (и прошагнуть это место отладчиком).
А можно то же самое сделать и конфигурационным файлом JTAG (.mac - файл в IAR).
Я подобным образом для LPC1788 сделал отладку проекта во внешней SDRAM: в .mac-файле прописал инит EMC-контроллера, и J-Link стал нормально грузить и запускать прошивку в SDRAM.
Это не проблема, также можно и вывести M0-ядро из ресета.
Главное тут - чтобы при подключенном к JTAG одном IAR-проекте, была возможность открыть другой проект и подключить его к тому-же работающему JTAG.
В CCS3.3 это решается промежуточной софтиной: вначале запускается "Parallel debug manager", он подключается к JTAG-эмулятору. А потом открываются
проекты для ядер и они уже коннектятся к "Parallel debug manager".

Нет. Ни разу не приходилось экономить электроэнергию. Хотя у LPC4370 отключил тактирование ненужной периферии - уж очень заметно он греется.

Я на LPC1758 экономил. Работа с периферией у меня была так сделана: включил нужную периферию, поработал с ней, затем - отключил её. И ПО так написано, что всё неиспользуемое время CPU находится в idle-процессе ОС выполняя команду WFE. Но отключение всей периферии и перевод в sleep-режим давали недостаточно экономии. Более глубокий сон там был невозможен (из-за задачи).
Потом добавил ещё в интервалы длительной малой активности отключение PLL с переходом на IRC и выставлением максимального делителя частоты ядра ==256. Так удалось добиться требуемого уровня потребления.
Здесь вроде есть для этого M0-подсистема - можно вроде больше сэкономить если-бы удалось выключить всё, что не входит в подсистему M0.
Хотелось бы потребление МК порядка 2-3мА. При этом выполнение некоторых простых функций M0-ядром.

[sonycman]

Я много работал с OMAP-L137, там 4 ядра, два из которых: ARM9 и DSP C674x.

А остальные два - это что?
Разве L137 это не двухъядерный процессор?

Прошу прощения за офтоп

[aaarrr]

А остальные два - это что?

Наверное, имелись в виду PRU. Но за ядра их считать не стоит.

[jcxz]

Наверное, имелись в виду PRU. Но за ядра их считать не стоит.

Почему это? Вполне себе ядра. Хоть и урезанные по самое. По скорости любой STM32 уделают

[aaarrr]

Почему это? Вполне себе ядра. Хоть и урезанные по самое. По скорости любой STM32 уделают

Даже всякие Cortex-M, занимающиеся управлением питанием в составе SoC'ов на Cortex-A, обычно не удостаиваются такого громкого именования.
PRU - это, по-моему, все же периферия, хоть и программируемая

Кстати, не приходилось их где-нибудь использовать?

[scifi]

Даже всякие Cortex-M, занимающиеся управлением питанием в составе SoC'ов на Cortex-A, обычно не удостаиваются такого громкого именования.
PRU - это, по-моему, все же периферия, хоть и программируемая

Сказали бы просто "устройство в цепочке JTAG".
Если уж начали спорить о значении слов, то, строго говоря, "ядро" - это IP корка, и в эту категорию входят и UARTы, и Ethernet MACи, и т.д. Какой-то умелец назвал процессор "ядром", и понеслось. Интел подлил масла в огонь, начав использовать для своих процов брэнд "Core"

[aaarrr]

Если уж начали спорить о значении слов, то, строго говоря, "ядро" - это IP корка, и в эту категорию входят и UARTы, и Ethernet MACи, и т.д. Какой-то умелец назвал процессор "ядром", и понеслось. Интел подлил масла в огонь, начав использовать для своих процов брэнд "Core"

Ядро в данном случае сокращение от "вычислительное ядро".

[sonycman]

Кстати, не приходилось их где-нибудь использовать?

Интересно, а как эти пруссы программируются? Можно ли задать для них функцию в компиляторе?
Или настройка как для обычной периферии - через регистры ввода-вывода?

[aaarrr]

Интересно, а как эти пруссы программируются? Можно ли задать для них функцию в компиляторе?

Для них пишется отдельный ассемблерный код. Загрузка и запуск средствами нормального процессора.

[sonycman]

Для них пишется отдельный ассемблерный код. Загрузка и запуск средствами нормального процессора.

Ну а инструмент для этого ассемблера есть, наверное? Среда какая нибудь? Не бинарный же код набивать, сидя с книжкой - как в былые весёлые времена ZX Spectrum?

Имхо, костыль какой-то получается.

[scifi]

Ядро в данном случае сокращение от "вычислительное ядро".

Напридумали словечек. В старину сие чудо называлось ЦПУ или "процессор".

[aaarrr]

Ну а инструмент для этого ассемблера есть, наверное? Не бинарный же код набивать, сидя с книжкой - как в былые весёлые времена ZX Spectrum?

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

Напридумали словечек. В старину сие чудо называлось ЦПУ или "процессор".

Четырехпроцессорный процессор?

[sonycman]

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

Спасибо за ликбез

Интересно, а зачем TI изобретали велосипед с этими самодельными ядрами, а не воспользовались готовыми решениями?

[aaarrr]

Интересно, а зачем TI изобретали велосипед с этими самодельными ядрами, а не воспользовались готовыми решениями?

Учитывая примитивность "ядер", едва ли в том была необходимость. Подозреваю, что PRU выросли из пожеланий кого-то из ключевых заказчиков, которые затем перешли в массовые изделия.

[jcxz]

Кстати, не приходилось их где-нибудь использовать?

Ну естественно сразу использовал PRU0 стандартно - для запуска ARM-ядра.
Позже хотел использовать для организации низкоуровневого драйвера обмена с кучкой SPI-АЦП. В текущей реализации чтение потока данных с 3-х 8-канальных SPI-АЦП осуществляется через McASP (на McASP эмулирую SPI). На этом же McASP кроме 3-х АЦП висит ещё аудио-ЦАП с I2S-интерфейсом.
Всё это работает одновременно на связке McASP+EDMA3, обслуживается ARM-ядром. Но при такой связке, не получилось по сигналам организовать обратный поток на АЦП (во время потока по обратному каналу (MOSI) этими АЦП можно управлять, например - считывать или записывая некоторые регистры АЦП не прерывая непрерывного потока сэмплов (между кадрами), но сериализаторами McASP это не получается сделать по сигналам).
Так вот, в дальнейшем, при наращивании функционала устройства, я планировал всю задачу обмена с АЦП перенести со связки McASP+DMA на одно из PRU-ядер, программно сэмулировав 3 отдельных SPI-канала на PRU-ядре. Грузить такой задачей одно из основных ядер не хотелось.
Я проработал это направление: разобрался в ассемблере PRU, написал простое ПО на него (эмуляция UART и работа по нему со взаимодействием с ARM-ядром). Но потом заказчик решил, что он доволен текущим функционалом устройства и решил не продолжать дальнейшее развитие ((
Но всё-таки хоть и тестовое, но ПО на PRUSS у меня работало.

Учитывая примитивность "ядер", едва ли в том была необходимость. Подозреваю, что PRU выросли из пожеланий кого-то из ключевых заказчиков, которые затем перешли в массовые изделия.

Не согласен.
PRU-ядра очень удобны для организации отсутствующей нестандартной периферии, где нужно например делать что-то очень простое с пинами GPIO (или другими интерфейсами), но очень быстро и не грузить простой задачей основные ядра.
Либо если нужно выполнять простую, но интенсивную обработку каких-то больших объёмов данных, которая слишком сложна, чтобы сделать её на EDMA3, но на PRUSS хоть на ассемблере нетрудно реализовать.
Например - принимая с какого интерфейса поток данных, необходимо преобразовать его в более удобную для обработки форму (переставив какие-то данные, поменив порядок байт или бит и т.п.).
Можно было-бы конечно вместо них поставить полнофункциональные ядра, но на них думаю потребовалось-бы гораздо больше вентилей и может не хватило-бы, или не хватило на два ядра.
Я считаю такую организацию: ARM + DSP + два субъядра очень удачной и удобной. Жаль только отладчик не цеплялся к PRU-ядрам.

[EmbedElektrik]

тут на форуме проскакивало что реальная полоса ацп около 15 МГц. так что не все так шоколадно.

[jcxz]

тут на форуме проскакивало что реальная полоса ацп около 15 МГц. так что не все так шоколадно.

Вы про эту тему?:
http://electronix.ru/forum/index.php?showt...&hl=LPC4370
Мне вобщем-то нужно оцифровать сигнал с основной гармоникой 5МГц. Ну может в худшем случае 7.5МГц, не более. Сигнал близок к синусоиде и высшие гармоники не интересуют.
Так что можно сказать что аналоговой полосы в 5 (или 7.5) МГц вполне достаточно. А вот сэмплов хотелось бы десяток на период.
Да и зачем собственно АЦП с макс. частотой квантования 80МГц иметь аналоговую полосу больше 15-20МГц?

[scifi]

тут на форуме проскакивало что реальная полоса ацп около 15 МГц. так что не все так шоколадно.

Только что померил реальную полосу. Отрицательный вход АЦП ёмкостью привязан к земле, а положительный подключен к генератору с выходным сопротивлением 50 Ом, да ещё с нагрузкой 50 Ом. То есть АЦП видит выходное сопротивление источника сигнала 25 Ом. Вот что получилось (небольшие горбы и провалы - это неточность амплитуды генератора по частоте):

Эскизы прикрепленных изображений

 

[jcxz]

Только что померил реальную полосу. Отрицательный вход АЦП ёмкостью привязан к земле, а положительный подключен к генератору с выходным сопротивлением 50 Ом, да ещё с нагрузкой 50 Ом. То есть АЦП видит выходное сопротивление источника сигнала 25 Ом. Вот что получилось (небольшие горбы и провалы - это неточность амплитуды генератора по частоте):

Хм... а как Вы померили полосу для частот выше половины частоты квантования АЦП?

[scifi]

Хм... а как Вы померили полосу для частот выше половины частоты квантования АЦП?

Да всё так же. Просто считал среднеквадратичное отклонение от среднего. Никто не запрещает полосу сигнала разместить выше частоты оцифровки (undersampling - слышали о таком?). Неслучайно есть множество АЦП, у которых аналоговая полоса многократно шире частоты оцифровки.