Хочу подключить SDRAM к LPC4370. Хочется использовать более мелкий корпус (BGA100), и там выведено только 8 линий данных (D0..D7). А в мануале всюду говорится о 32-разрядном и 16-разрядном режиме (chip select width). И только в таблице возможных конфигураций есть строчки типа 2Mx8, 16Mx8 и т.д. Причём эти строчки есть как в таблице про 16-разрядную шину данных, так и про 32-разрядную.
Вот как это понимать? Дурдом какой-то.

Полноценно работать с 8-битной скорее не получится. Для SDRAM нужен пин EMC_A14, которого в BGA100 нет. В BGA100 шина для статики сделана. Доступные режимы EMC SDRAM только 16 и 32 бита. Но можно ли работать в "неполноценном" режиме с каждым вторым мусорным байтом - это может быть. (с EMC_A14 это не связано)


Для 16-битного режима: на A0-A7 весится первая 8-битная SDRAM, на A8-A15 вторая. Для 32-битного четыре микросхемы SDRAM.

Это я заметил. Не получится использовать банки 3 и 4. Либо забью на них (памяти и так хватит), либо подцеплю к GPIO и буду колхозить переключение "страниц" в софте.


При этом зачем-то вывели RAS, CAS, DYCS. Вот не верится, что у них там в NXP совсем крыша съехала.


На это и рассчитываю. Если не получится цивилизованным способом, буду городить огород.

Пины многофункциональные.

Блин-зачем??? Нельзя все сделать без огорода? Или у нас это в крови?

Вообще-то да, справедливо.

Но всё равно не оставляю надежду. Читаю на сайте ARM документацию на контроллер памяти PL-176 (внутри LPC4370 вроде бы сидит PL-172, но в этой часто должно быть похоже):

Пытаюсь понять, как может быть одновременно "external bus width 16-bit" и "device width 8-bit".
Загадка природы.


Не нервничайте, уважаемый. И пекитесь о своей крови, у меня в этом плане проблем нет.
Хочется использовать BGA100, потому что BGA256 сильно больше. В условиях моих конструктивных ограничений это важно.

Никаких тормозов может и не быть. Просто софт писать соответственно. Только стандартные memcpy и прочие будут медленнее работать, если скомпилятся в байтовом режиме.

На заре микропроцессоров приходилось подключать даже 1-битный чип статики. И всё работало, программно пересобирая байты. А этот случай вообще вариант нормы.

А почему вас это волнует? В смысле тормоза. Я-то никуда не тороплюсь, мне просто много памяти надо.

Разве меня это волнует?
Шёл мимо. Смотрю, человек беспокоится. Решил успокоить.

Собственно, для процессора это будет обычный 16-битный режим SDRAM. А то, что вторые 8 бит данных снаружи процессора никуда не подключены, он даже не узнает. Нужно только не забыть EMC_DQMOUT0 подключить, чтобы нечётные байты не затирали чётные. Но такой режим лично я не тестировал. Теоретически должно работать. Т.к. невыведенные наружу управляющие сигналы EMC не должны что-то менять во внутренней логике EMC. Например, для работы 16-битного режима SDRAM в корпусах процессора, в которых не выведены на пины часть сигналов EMC_CLKх, их всё-равно нужно программно настраивать. Или настраивать два пина в режимах CLK01 и CLK23.

Оказывается есть грабля. У BGA100 не выведены DQMOUT. Поэтому с байтовым доступом к области памяти SDRAM надо быть очень осторожным. Не пользоваться memcpy и другим непрозрачным функционалом. И невыровненную 16 и 32-битную запись в SDRAM вообще избегать. Только выровненную 16 и 32-битную можно.


В последнем юзер мануале на LPC43xx v1.9 есть упоминание только о 16 и 32-битных режимах.

Видимо, не буду заморачиваться с BGA100. Не стоит оно того.

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

Если скорость не важна, и данных много не большого размера, то легко написать пару своих функций по копированию из SDRAM во внутреннюю RAM, которой там много. И обратно. И уже из внутренней RAM полноценно работать с чистыми данными, размером например до 64 КБ.