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. Но вроде так невозможно (((

[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"

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