Возникла задача: оцифровать аналоговый сигнал с частотой ~ 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?

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


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


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

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

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


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


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


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

Это понятно - можно в начале 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".


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

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

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

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

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

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

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

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

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

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

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

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

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

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