Здравствуйте!
Придумал себе устройство, которое должно выполнять следующие задачи:
- снимать или выставлять показания на 20 дискретных выводов
- снимать показания с 2 выводов АЦП
- общаться с другим устройством по zigbee
- считывать дополнительные данные с sd карточки
- выводить свое состояние на большой экран, 6-7 дюймов.

От экрана я и начал плясать. Китайцы продают tft-модули с параллельным интерфейсом по 50 баксов за штуку. Цена очень привлекательна, я бы такой модуль и взял бы.
Однако, выясняется, что для реализации моих хотелок для разрешения 640х480 точек необходимо порядка 6 Мб оперативной памяти (по 1 Мб на меняющиеся основной и дополнительный буферы вывода, 4 Мб для supersampling-сглаживания линий).
Сглаживание линий мне довольно принципиально, потому использовать дисплей со встроенными буферами уже не сильно спасает ситуацию.

Какие бы комплектующие (помимо экрана) вы бы посоветовали бы взять?
Есть ли микроконтроллеры с такой большой ОЗУ?
Какой взять мк, чтобы выдержал нагрузку, и какую память, как подключать, желательно еще так чтобы в интернетах было достаточно информации?

Альтернативное устройство (китайский планшет итп) не рассматриваю - мне важно, чтобы устройство своевременно реагировало на изменение информации на датчиках. За жизнь человека не отвечает, но использовать прослойки из linux-ов уже не хотелось бы.

Благодарю за ответы.

Во-первых, можно включить видеорежим 640x480x8bpp. Это 300 кБайт. Палитры из 256 цветов хватит за глаза, если только не захотите выводить полноцветные фотографии.
Во-вторых, если изменения картинки происходят не часто, а прорисовка достаточно быстрая, то никаких тормозов на практике не заметно, то есть двойной буфер не требуется.
В третьих, откуда 4 Мб для сглаживания линий? Есть алгоритмы динамической прорисовки сглаженных линий. Кроме того, часто бывает достаточно иметь заранее заготовленные картинки в флэш.


Нет. И на 300 кБайт тоже нет.


Внешний графический контроллер. У Epson есть хороший ассортимент.


Любой 32-разрядный МК от 50 МГц должен подойти. Естественно, он должен стыковаться с графическим контроллером (внешняя шина). Причём желательно использовать ширину шины по максимуму для наиболее быстрой прорисовки.

Вы что хотите GUI на экран и вот всю эту обработку написать на голом С/C++ без использования операционной системы?


Судя по Вашим вопросам Вы совершенно не представляете с чем хотите связаться. Если будете продолжать в том же духе то вас ждет долгий путь с туманными перспективами.


Вот даже если взять планшет, т.е. уже готовое железо, zigbee подключить свистком на встроенный USB-host и где то на плате найти 20 свободных GPIO, 2 входа АЦП взять с микрофонного входа и использовать "прослойки из linux-ов" и то это достаточно сложная задача.

P.S. Или это я всё усложняю? С другой стороны, никаких цифр не озвучено, так что можно только гадать что имелось ввиду.

Контроллер Epson S1D13781.
480 * 272, SPI интерфейс. TFT.
Подойдёт?

Да, вы всё усложняете.
Не пугайте человека. Я делал подобные вещи на голом Си без всяких осей. Нет там ничего суперсложного. Графический драйвер для отрисовки примитивов (прямоугольники, тект, картинки, с макс. ускорением под выбранный графический контроллер) достаточно прост, особенно если иметь перед глазами примеры подобного кода. Рисование несложного GUI из примитивов - тоже ничего сверхъестественного.

Действительно все усложняете.
Я не вижу необходимости использования операционной системы для обработки датчиков в стиле (Pin1 = Pin2 && Pin3 ? 1 : 0), основная работа мк заключается в выводе нескольких показометров на экран.
Сглаживание необходимо для придания устройству готового вида, дабы устранить зазубрины на стрелках и все.
Какие цифры вам рассказать, я не представляю.


Да, пожалуй, вполне подойдет.


Недоставаемо.


Мне кажется, что легче взять нулевой камень и написать для него чистую программу, нежели сначала раскурочить планшет, узнать, что в нем нет ни usb-хоста, ни свободных выводов, затем писать подвисающую программу под андроид или типа того (мой 700 мгц телефон подвисает с графикой, не знаю что уж у него внутри). В итоге все становится похоже на покупку Arduino для моргания светодиодом.

Задача в плане GUI не раскрыта, а от этого и надо плясать. От его сложности и "красивости" будет зависеть всё остальное. Если там нет каких то особых задач по остальной функциональности. Дьявол то он в деталях как всегда.

Просто меня убил вопрос про контроллер с мегабайтами ОЗУ на борту

Можно взять LPC178x и навесить SDRAM. Тогда будут мегабайты ОЗУ, как вы и хотели :-)

Не, есть... А где искали? Или уточните страну.
Если даже это останавливает... что же дальше будет, если потребуется что-то отличающееся от IN74AC74?
Действительно, для выдачи показометров лучше отдельный контроллер - не будет эффекта "опускающегося занавеса" при перерисовке или смене картинки.

GUI: никаких эффектов, ничего трехмерного, никаких даже меню.
Просто набор из трех-четырех стрелочных показометров и нескольких текстовых надписей в определенных местах экрана.
Сперва в буфер надо положить задний фон, считанный с карточки SD, затем на нем в нужных местах нарисовать стрелки и буквы.
Почти статичная картинка, хотя показания могут меняться каждую секунду и их надо соответственно быстро отображать.

Мегабайты ОЗУ нужны для графических буферов. Пусть даже буду использовать по 256 цветов на каждую из 640х480 точек экрана, это 600 кб на два буфера.
Так и быть, со сглаживанием можно повоевать, однако превращаться в филиал NVidia мне тоже не хочется, потому рассматриваю самые простые алгоритмы сглаживания границ полигонов.
Тем не менее, памяти уже надо поболее того, что обычно встречается в МК.

Бекенд с обработкой портов простейший, плюс по zigbee небольшие порции данных, не чаще раза в минуту - также пара удаленных простых датчиков.

Я почему-то все думаю про реализацию видеоконтроллера и прочей мути в едином камне.
Сказывается различие цены за голый tft модуль ($50) и модулем со встроенным контроллером с работой по SPI (медленно?) ($200).
Еще вижу интересные примеры работы с lcd через STM32 fsmc, но там рассматриваются только мелкие экраны.

Потому я и начал делать свой.
Стирание экрана около 2 мс (в режиме 8 бит на пиксель, 63 МГц тактовая частота внутри контроллера) - затраты только на передачу команд.
Смена цифр оставляет впечетление, как будто смотришь на газоразрядный индикатор на ИН - просто мгновенно (посторение из битмапа в видеопамяти).

Если фон произвольный и есть сглаживание, то это alpha-blending, то есть геморрой. Гораздо проще, когда фон однородный. В этом случае можно прикинуться Nvidia, не так уж это и сложно.


Я выше писал про МК+SDRAM. Не совсем один камень, конечно.

Да нет никакого гемороя, в ucGUI есть антиалиасинг для всех графических примитивов.
Но антиалиасинг требует повышеной мощности проца и пропускной способности видео ОЗУ.
Поэтому на STM32 даже не пытался бы.
Нужно выбирать процессор с отдельной шиной с DMA на дисплей (из семейства iMX например) и включать в GUI функцию прорисовки в памяти.

По моему, любого Cortex+sdram хватит за глаза. Простой gui, даже 3D запросто на голом c++ прописывается, сам делал.
Тут от дисплея надо плясать - какой у него интерфейс(киньте документ-попробуем что-то подобрать), абы заранее заложить максимально простое управление с точки зрения процессорного времени.

Я подобный (только 3.5") цеплял к внешней шине LPC1788 (starterkit'овской отладке).

Ну эт Вы зря... На 300 - есть и в 10 раз больше есть
см. например: http://www.toshiba-components.com/microcon...er/TMPM320.html
причём - в LQFP

Да вот что-то такое:
http://www.cec-mc.ru/pdf/AT056TN52%20V.3%20F(V01)_0818.pdf
Параллельный ввод rgb + еще пара контактов

Тошиба шикарен.

Посмотрите у МЭЛТ, может что-то Вам и подойдет.