А что там такого страшного? Только не "попиксельный", а побайтный/пословный. И не "на дисплей", а в видеобуфер. А уже видеобуфер, после отрисовки всей страницы, отправлять на LCD. The Dot Factory создаёт пару массивов. Из них и несложно сделать вывод.
Можно взять готовую либу "EmWin" или подобную. Тут ничего подсказать не могу - не пользовался никогда, всю графику всегда писал сам.
Если б хотя-бы дефолтный режим подсветки синтаксиса при вставке фрагмента кода сменили на "си", вместо мало кому здесь нужного "HTML". А также остальную кучу ненужных на этом форуме режимов подсветки "Ruby", "Python" и прочий "PHP" заменили на более нужный "ассемблер". Когда ещё просил, а воз и ныне там, никакой реакции....
Делать самому шрифт - это лишнее. Можно наковырять шрифтов из винды. Поищите в инете утилитку "The Dot Factory" - с помощью неё можно конвертить виндовые шрифты в удобный формат для включения в исходный код МК.
Берите любой удобный, в котором есть достаточно ОЗУ для хранения видеобуфера размером по требуемому количеству точек экрана.
Видимо любой МК на базе Cortex-M будет наиболее подходящ для вашей задачи.
Почему беспокоитесь об "избыточности"? Нужно серийное производство?
Думаю - лучше взять какой-либо со встроенным контроллером и подключением по SPI. Например подобный этому: https://ru.aliexpress.com/item/SPI-TFT-LCD-Display-Module-Chip-ILI9340C-PCB-SD-Card-2-2-Serial-240x320-New/32266092912.html
Есть и OLED с SPI.
Тут многое зависит от требуемой тиражности вашего устройства: один-два экземпляра или серия? Если второе - то надо думать над удешевлением, если первое - брать что помощнее, с запасом.
В смысле где? В МК есть память (Flash и ОЗУ), там и храните. Зачем какая-то ещё память? У Вас же не мегабайты этих текстов?
Если Ёбург неудобен, то могу посоветовать для пробы плату SK-MLPC1788 (есть на starterkit.ru или на его украинском варианте (наверное он ТСу ближе) - http://otladka.com.ua/). Схема на эту плату говорит что на ней стоит как раз MT48LC16M16A2TG. Правда на имеющемся у меня экземпляре стоит K4S561632N-LC75 - видимо у меня ещё старая ревизия платы. В любом случае можно связаться с ними и уточнить. Плата проверено рабочая - я на ней начинал некоторые свои проекты. В том числе у меня есть тест всего объёма SDRAM для неё (на разные режимы, в том числе и проверка времени хранения без рефреша).
И да - на плате стоит LPC1788, а не STM32, но мне кажется МК для пробы не принципиален. А может на других их платах с STM32 есть такая же SDRAM.
PS: Да уж - на украинском варианте этого магазина цена конечно какая-то негуманная....
Тут дело не в SRAM/не_SRAM, а в том - мультиплексирована шина адреса или нет. У рассматриваемого чипа SDRAM шина адреса мультиплексирована. И адрес делится на адрес строки + адрес столбца. Именно поэтому перепутывать нельзя. Если есть в природе SRAM с мультиплексированной шиной адреса, то для неё тоже это ограничение возможно будет справедливо.
Ну уже не говоря про пакетный доступ.
Если Вы имеете в виду: формировать все сигналы ногодрыгом GPIO - то пожалуй можно, но будет реально медленно
А через контроллер SDRAM - сильно сомневаюсь, что получится при произвольных перепутанных ногах адреса. Проблема тут в том, что контроллер SDRAM должен знать какие разряды адреса относятся к строке, а какие - к столбцу. Иначе - не получится.
Посмотрите какие там размер строки и столбца: ваша 4Мб требует больше адресных линий (как минимум 11), а в 1Мб возможно всё влазило в 10 адресных линий.
Например в моей IS45S16400J (1 Meg Bits x 16 Bits x 4 Banks (64-MBIT)):
#define SDRAM_RAS_L 2 //RAS latency (active to read/write delay)
#define SDRAM_CAS_L 2 //CAS latency
#define SDRAM_ROWS 12 //разрядность строк
#define SDRAM_COLS 8 //разрядность столбцов
#define SDRAM_BANKS 2 //разрядность кол-ва банков (кол-во банков == 1<<SDRAM_BANKS)
#define SDRAM_WIDTH 16 //разрядность шины данных чипа SDRAM (16 или 32)
#define SDRAM_BUS 16 //разрядность шины данных контроллера SDRAM (16 или 32)
#define SDRAM_SIZE \
(SDRAM_WIDTH / 8 << SDRAM_ROWS + SDRAM_COLS + SDRAM_BANKS)
Т.е. - нужны A0...A11, но у вас может другая конфигурация.
Не знаю, так как работаю сейчас не в РФ.
Вот с документацией у Infineon не очень: не раз уже натыкался на ошибки в мануале (описание регистров Ethernet-DMA в мануале вообще не соответствует действительности, пришлось брать из примеров - там было верное описание; ну и на другие баги натыкался) и errata сделана неудобно (когда выпускают новую ревизию чипа, errata обновляют и из неё удаляют описание старых багов, т.е. - вообще удаляют(!); поэтому если на плате стоит старая ревизия чипа - смотришь в errata - а бага то и нет, и надо ещё догадаться что они просто описание удалили, а на их сайте не так то просто найти старые errata). Да и полнота описания периферии в мануале оставляет желать много лучшего. Но это, впрочем, касается и других вендоров.
Я сейчас с LPC4370 не работаю :( Да и тогда, когда работал, проект не был завершён, так что до M0 дело не дошло.
M0 я там планировал использовать не для увеличения вычислительной мощности, а для экономии батарейки.
Да, сейчас главным образом с XMC47xx. Немного с STM32F4xx
Вот слышал что NXP с начала 2019-го запускает новую линейку Cortex-M с дополнительным DSP-ядром. Очень интересно: что это за ядро такое будет? Полноценное DSP-ядро или просто какой-то периферийный блок умеющий делать некоторый ограниченный набор операций?
Нашёл на их сайте https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/lpc-cortex-m-mcus/lpc5500-series-cortex-m33-mcus:LPC5500_SERIES
видимо это оно. Два ядра Cortex-M33 (одно с FPU) + DSP-акселератор + PLU (что-то типа простейшей ПЛИС видимо). Но про DSP там почти ничего не сказано (про его возможности). Жаль.... :(
Но всё равно интересно - 100-ногий LQFP и в нём 3 ядра! Вот это круто! :))) Если конечно там реальный DSP, а не какой-то обрезок....
Конечно у них давно уже есть LPC4370 с 3-мя ядрами, но он только в BGA. :( А тут LQFP.
Вы как-нить почитайте мануал на семейство XMC47xx Infineon - вот здесь реально куча программируемых сигналов от одной периферии к другой, которые очень гибко программируются для разных функций (не только запуск, а много чего ещё можно сделать). Практически можно связывать внутреннюю периферию этими сигналами, почти произвольные её блоки между собой. :)
И оно уже много лет как есть.
Может лучше стоило поискать какую-то готовую отладочную плату с этим чипом?
У меня такой нет, но есть плата с K4S561632N-LC75. Это чип такого же объёма как у Вас и вроде такой же конфигурации (4 банка, шина 16 бит). Правда на ней LPC1788. В работе и инициализации никаких проблем не было - делал давно, всё работало.
В другом проекте было две MT48LC32 - тоже всё ок. Правда тоже другой МК.
Если при таком переносе проявляются какие-то баги, то это уже хорошо, что они проявились - их надо искать и устранять. Только из-за одного этого стоит переносить туда-сюда.
Нормально написанное ПО как правило не перестаёт работать при переносе в разные области памяти. А сам перенос настолько прост, что сам по себе не должен создавать дополнительных ошибок.
Я сам активно использую отладку в RAM или SDRAM почти во всех проектах. И везде у меня ПО работает одинаково и в FLASH и в RAM и в SDRAM. Изменяется только загрузка CPU и скорость загрузки отладчиком.
