jcxz

ошибаетесь. Сомневаюсь, что найдёте осцилл за 800руб. Но лучше: https://www.nxp.com/part/OM13054#/ с LPC4370 всего за 27$ за EVB. Можно купить 2, одну сделав J-Link-ом.

Хех! У Nuvoton-а есть со 128МБ встроенной DDR! раз пошла такая пьянка... Кто больше?

Перед nvic_irq_enable() полезно очищать флаги прерываний. Как в периферии так и в NVIC. Советую: остановиться отладчиком перед nvic_irq_enable() и посмотреть где у вас торчат активные флаги запросов прерывания.

Есть всякие.

Надо было как то сделать осциллограф на LPC4370. Сделал. Много времени не заняло. Так как понимал - что нужно и для чего. И внутренней памяти на всё хватило и ещё куча лишней осталась, и 80 MS/s захватывал и отображение работало и на LCD и в USB. Не вижу проблемы если понимаешь что именно тебе нужно. А так да - эти осциллографостроители, плавающие в основах, обычное дело.

В 1-ю очередь: Микроконтроллер, способный уметь закачать в себя необходимый поток сэмплов. Объём ОЗУ - дело 2-е. Если он сейчас выберет МК с 1МБ ОЗУ, не подумав об интерфейсе подключения АЦП, то вообще никакой картинки не сможет получить. До свистоперделок даже дело не дойдёт. PS: Всё равно, что выбирать цвет кузова авто, даже не поинтересовавшись: "а есть ли вообще автодорога к цели путешествия"? Может вообще лодку выбирать нужно, а не авто.

Я уже несколько раз писал: И вопрос был о минимуме необходимой ОЗУ. Захватывать можно сколько угодно, хоть мегабайты если есть место. Но необходимый минимум для отображения осц. на экране = количеству точек экрана по X. Зачем прореживание, если можно просто захватить с необходимой частотой и если речь идёт о минимальных требованиях, чтобы хотя бы заработало, а не о максимальных хотелках? ТСу хотя бы по-минимуме что-то сделать. Не думая о прореживаниях, фильтрации и т.п. Если сможет сделать минимум, дальше будет доделывать дополнительные свистоперделки.

Вы читать умеете? 800 точек * 1 байт на пиксель = 800 байт нужно захватить чтобы нарисовать один кадр осц. (при АЦП > 8 бит - умножить на 2). 800 (или 800*2) байт есть почти в любом ARM-е. Причём тут разрядность МК - вообще не понятно. И рисование - это совсем другая задача. Не мешайте мух с котлетами (захват осц. и рисование). О рисовании речь вообще не шла. Потому как неизвестно ничего о способе подключения экрана. Рисование зависит от способа подключения. Если дисплей имеет свой контроллер с ОЗУ, с параллельной шиной до МК - памяти в МК вообще не нужно, можно рисовать прямо в памяти контроллера. У человека каша в голове. Он даже не понимает разницы между захватом осц. и рисованием, причём - для разных типов интерфейса с дисплеем. Это первоочередная проблема, которую ему надо будет решить. До всяких рисований. И боюсь, что он на ней споткнётся и дальше не продвинется.... До рисований дело даже не дойдёт.

Что именно непонятно? Памяти для захвата осциллограммы много не нужно. Её нужно столько, сколько у вас точек LCD по горизонтали. Ну может с 2-кратным запасом для масштабирования захваченного кадра. Такое количество есть почти в любом ARM-е. Производительности для отрисовки осц. тоже много не нужно. Если грамотно рисовать и без лишних рюшечек. Это же не кино прокручивать.

Где "там" я не знаю, а вам советую внимательнее прочитать, что я писал.

Необязательно. Там может быть и целиком прошивка. Вы о чём? Я вообще-то говорил о том, что прошивка в CY7C68013A может грузиться как из EEPROM по I2C, так и через USB с хоста. Странно... а я её писал для CY7C68013A. Не знал, что изменению не подлежит.

Я вам ещё в самом первом сообщении писал про маппинг flash на адрес 0. Только вам так и не пригодилось.....

Хватит внутренней памяти типичного Cortex-M средней руки. Ничего фантастического не нужно. А с рисованием справится даже самый дохлый Cortex-M. Самое главное - захват. Хотя 10MS/s - это уже не космос.

Там не ассемблер, там GPIF, который программируется визуально в GPIF-редкакторе. GPIF - это что-то вроде простой ПЛИС. Конфигурация для которой создаётся в GPIF-редакторе, хранится в прошивке дампом и заливается в ПЛИС ядром 8051 при старте. И да - диаграмма работы GPIF разрисовывается в GPIF-редакторе по тактам. Примерно так. Да и само микроконтроллерное ядро x51 может обслуживать самостоятельно какие-то транзакции по USB. Но только медленные. Быстрый поток внешний_интерфейс<->USB обслуживается GPIF-ом. На LPC4370 это возможно. Только АЦП должен писать отсчёты не во внешнюю память, а во внутреннюю. Если нужна полная скорость 80MS/s. Но ведь осциллограф и не должен минутами писать все сэмплы подряд. Его задача: по какому-то событию (триггеру) захватить последовательность сэмплов, количеством не менее числа точек по X экрана. И потом уже отрисовать их на экране. Мегагерцовая скорость отрисовки тоже не нужна. Знаю о чём говорю, так как ранее как раз на нём делал осциллограф на 80MS/s. И как ни странно - он захватывал несколько тысяч отсчётов, с последующей отрисовкой на LCD. Без каких-либо пропусков. Сложности могут возникнуть с обслуживанием триггер-событий, так как программно будет это делать весьма непросто если АЦП будет молотить на полной скорости. Поток 80 MS/s (естественно через DMA; по 2 сэмпла в одном 32-битном слове) грузит LPC4370 почти полностью, оставляя ядру мало времени. Может даже ядро вооще лучше класть в сон на время трансфера ADC->DMA->RAM. Но если как пишет ТС - "достаточно 10 MS/s", то на такой скорости уже даже триггер-события можно попробовать обнаруживать программно (с небольшой задержкой старта после оного). Но потребны способности к ассемблеру.

Уверены? Я вот на схеме вижу U6, в которой вполне может находиться прошивка. Но даже если "софт находится на PC", то это не значит, что "его никто не писал". Без прошивки CY7C68013A работать не будет.