Пока остановился на интерфейсной микросхеме ISP1582 от NXP
Но есть одна загвоздка - проц _уже_ должен адресовать 64М (16Мх32) флешу
Получается, что эту интерфейсную микросхему придется адресовать как-то хитрее.
В плане формирований управляющих сигналов для флеши поставил CPLD, ячеек лишних там еще много, так что комбинаторику уписать туда можно практически любую.
Можно ли как-то задействовать интерфейс динамической памяти?
Хотелось бы, чтобы для программиста потом все было как можно "прозрачнее", просто флеш в одном диапазоне, интерфейс USB - в другом, без лишнего программного "ногодрыгания"

У LPC2468 уже есть собственный USB full-speed Device/Host/OTG Controller with 4kB of endpoint RAM. Вам еще один USB-device нужен что ли?

в том-то и дело - full speed
я ж в сабже написал - hi-speed надобно
Собственный контроллер в LPC работает замечательно... но медленно для заказчика. Поэтому и возникла необходимость во внешнем контроллере hi-speed USB

AT91SAM3 попробовать не хотите? Там USB HS встроенный. Параллельной внешней шины нет, но я сейчас на NAND-ы с SPI смотрю, может Вам тоже подойдут.

нет, как раз требуется 32-разрядная шина, так бы проблем бы не было, и у LPC есть hi-speed решения

Едва ли.


Ну, можно знатно извратиться, выделив некоторую область памяти, где 16-бит обращения идут у ISP, а 32 - к флеш. Или подключать ISP на один цикл шины после записи секретного слова по секретному адресу. В общем, есть варианты.

так все равно нужно что-то отключать от шины... то есть однозначно идентифицировать относительно какого-то сигнала


вроде бы выход, но.. запись во флеш подразумевает относительно хаотичные данные и не факт, что не совпадет с этим magic значением. В результате такое решение не подходит

а может все-таки "ногодрыг"? если аппаратных решений нет
да и выставить уровень на ножке порта дешевле по времени, чем одна операция с внешней шиной...

Вот по BLS и идентифицировать. Другое дело, что работать только 32-х битными словами с флеш может оказаться неудобно, но это надо смотреть по задаче.


Ну, если программист будет достаточно внимателен, то ничего страшного.

как раз нормально. То есть, если адрес не выровнен до 4, /BLSx как раз и будет тем /CS, через который можно лезть НЕ во флеш?
Кстати - какой BLS? при 16-битном BLS2, при 8-битном любой, но не BLS0? Я так понимаю, BLS0 будет всегда генериться при 32-битной конфигурации EMC?

Фигню я сморозил: способ годится только для записи Хотя такую запись можно использовать для временного переключения flash-ISP.

ну с таким же успехом можно и ногой дрыгать


ну не совсем, если в выражение впихнуть /OE, /WR, /CSx, /BLSx и A0 с A1

Совсем: при чтении BLS не используется, а A0 и A1 могут быть в нуле.
Нет, на LPC работа BLS конфигурируется (бит PB в EMCStaticConfig), так что все в порядке.

итого итог - ногодрыг все-таки, скорее всего... проще по прерыванию от внешнего контроллера ставить пин в 1, вычерпнуть все и сбросить...
а в основной проге, где работа с флеш, просто на эту тему не заморачиваться

И так, пожалуй, правильно. Делить ресурс по ширине доступа можно, но это все-таки слишком большое извращение.

не буду плодить новую тему...
для данного контроллера (LPC2468) скорость передачи по USB со встроенным full-speed в размере 6 Мбит/с нормально, или есть куда развиваться?
сам контроллер, фактически, занимается только тем, что ждет 32Кбайт данные, отсылает подтверждение и снова ждет. Весь блок отсылается во внешнюю flash (или читается оттуда такими же блоками)
имеет ли смысл в таком случае связываться с DMA? С ним дела пока не имел, разбор полетов может занять какое-то время, а пилот выпускать нужно. С hi-speed вопрос решается, но если есть куда "рости" с родным контроллером, то было бы очень неплохо

Я, правда, с LPC2468 не работал, но очень сильно сомневаюсь, что он не позволяет оттяпать всю полосу.
Ищите, где у вас тормоза случаются.

а какова методика поиска?
я пользую кейловский пример для mass storage, выкинул оттуда scsi, оставил только bulk.
В прерывании обрабатываются только control и мои две точки, там выставляются флаги. В основной проге жду флага и начинаю выгребать буфер точки или наоборот наполнять

Сделайте сначала какой-нибудь bulkloop или вообще простейшую "посылалку", посмотрите скорость. Если скорость неудовлетворительная, посмотрите, нет ли тормозов по вине хоста.

А каким образом, или почему хост может тормозить?

Смотреть, есть ли NAK'и. Хост может тормозить по причине кривизны ПО, на нем запущенного.

делал... то же самое
попробую хост посмотреть

какими пакетами (какого размера) лучше обмениваться хосту с девайсом? я пересылаю по 32К (сначала команда, потом блок данных, потом ответ от девайса)

и еще, так никто не ответил... в таком режиме, когда проц, фактически, тупо ждет флага от прерывания и выгребает точку, есть ли смысл пользовать DMA?

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

буфер есть, т.к. в user manual работа с ним описана. А вот есть ли он в реализации кейла... сейчас посмотрю...

там все в порядке. Как и предлагается на стр.386-388 LPC2468 User Manual (rev.04 26.08.2009), при завершении чтения из буфера используется команда CMD_CLR_BUF, при завершении записи - CMD_VALID_BUF
обе команды переключают используемый буфер
если оба буфера не вычищены, аппаратно генерится NAK