Делаю меню на LCD CX65

Заимел 5 штук дисплеев cx65. таки освоил как его подключать и даже вывел тестовую программу. и даже связал всё это удовольствие с RTOS
теперь у меня на него грандиозные планы: хочу сделать меню древовидной структуры.
то есть как в телефоне список пунктов и подпунктов и изменение параметров .
клавиатура 4х4 на тактовых кнопках (будет второй вариант на основе capsims, но это дело ближнего будущего)

дело в том что С++ я только недавно начал осваивать.
как сделать примерный алгоритм работы с меню, его прорисовкой, и всем прочим...
кто может помочь библиотеками, направлением куда рыть, какие запросы гуглить? буду благодарен рабочими примерами....

0

Сообщение от Orsomum .... на последней страницЕ рисуются только 5 строк из 10. то есть 5 элементов четвёртой страницы нарисовались но при этом нижние пять элементов предыдущей страницы остались и видны. было озвучено предложение очищать экран каждый раз перед отрисовкой строк. но это приводит к тому что экран очень неприятно моргает. как быть господа?

Озвучу предложение оставшиеся строки заполнять пробелами :)

0

а есть третий вариант: завести глобальную переменную где хранится текущая страница. при прорисовке сткрок идёт сравнение текущей локальной переменной с глобадбной переменной текущей страници. если НЕРАВНО то чистим экран и присваиваем глабальной переменной значение локальной.
//очистка экрана если происходит смена страницы.
if (MENU_Page_Current != MENU_previous_page)
{
MENU_previous_page = MENU_Page_Current;
fill_ssreen(0xFFFF);
}
конечно в лоб. но мерцает только при перелистывании.
но не мазохизм со строками

0

А в чем разница переписывать весь экран или оставшиеся строки?
По-моему второй вариант требует меньше времени.

Другое дело, если дисплей поддерживает комманду очистки экрана. Думаю, это было бы идеальным случаем. :)

0

Сообщение от Fohyvis А в чем разница переписывать весь экран или оставшиеся строки? По-моему второй вариант требует меньше времени. Другое дело, если дисплей поддерживает комманду очистки экрана. Думаю, это было бы идеальным случаем. :)

насколько мне пока известно - не поддерживает.

переписать экран - одна команда и одно условие.
пересписывать строки и символы в строке (если новая строка короче старой то "огрызки" старой будут правее новой) - это два цикла (символы и строки) . получается полигон из n ног на m пуль.

вообще - страдаю изобретением велосипедов... но интересно

0

Сообщение от SGE Добавить пару-тройку строк с пробелами до целого количества экранов - что может быть проще ?

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

0

Сообщение от SGE Так и появилась Wymdows 1.0/

поржал.

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

задумался.

0

Сообщение от Orsomum ...переписать экран - одна команда и одно условие.

Эта одна команда дисплею?

Или имеется ввиду одна процедура алгоритма управляющего МК, при которой МК прет в дисплей 100500 нулевых байтов?

0

Ух. Работа автора - типичный пример как не нужно делать. Сначала программируем потом думаем что именно хотим получить. Я уж молчу о простой алгоритмической базе.

0

Вообще из своего опыта работы и переписывания (дописывания) готового проекта под новый тип дисплея могу посоветовать следующее.
1) Отложить железо в сторону.
2) Взять лист буниги и карандаш.
3) Набросать эскизы страниц дисплея с менюшками, как бы хотелось чтобы это выглядело.
4) Посмотреть как это стыкуется с возможностями дисплея.
5) Начать писать менюшку и проверять в железе.

Это позволит сэкономить кучу времени.

0

Сообщение от sid_otix Вообще из своего опыта работы и переписывания (дописывания) готового проекта под новый тип дисплея могу посоветовать следующее. 1) Отложить железо в сторону. 2) Взять лист буниги и карандаш. 3) Набросать эскизы страниц дисплея с менюшками, как бы хотелось чтобы это выглядело. 4) Посмотреть как это стыкуется с возможностями дисплея. 5) Начать писать менюшку и проверять в железе. Это позволит сэкономить кучу времени.

Применимо к любой программе
для пунктов 4,5 можно использовать чужой мозг за деньги

0

Все навигации для маленьких экранов уже давно придуманы. никому не нужно 150 пунктов в ряд. Это бред полнейший. Если много настроек то все они должны быть сгруппированы логически. А листать корневой уровень влево-вправо это бред. Вообще первый уровень меню и другие вложенности не должны превышать 10-12 пунктов. Если сделать страницы, то в итоге пользователь запутается где он находится - в подменю или же просто на какой-то странице.
Вообщем, в любом случае перед тем как кодить нужно накидать концепцию и можно вынести на обсуждение. А закодить потом будет намного легче.

0

Miko32, assembler - https://www.youtube.com/watch?v=SYzqYTsX3gc.

0

Недурно! Интересно, сколько памяти это занимает?
Что мне не понравилось - тормозное "перемигивание" выбранного пункта меню.
Видимо МК тут загружен до предела. За тормознутость интерфейса сомневаюсь.
Хотя могу и ошибиться - с графическими дисплеями дела еще не имел.

0

Сообщение от Fohyvis Интересно, сколько памяти это занимает?

Проект в протеусе под М8.

[31.39 Кб]

0

Сообщение от SGE Интересно было бы взглянуть на исходники.

Не советую... т.к.

Сообщение от tyzord66 assembler

можно будет в психушку угодить )))

0

ShodS прав. )

А если в двух словах, то это одна увесистая процедура с множеством параметров, которая многократно, рекурсивно вызывает сама себя с сохранением в стеке указателя на элемент структуры на эти параметры и текущего состояния, применяя параметры подменю нижнего уровня. При выходе процесс обратный. Среди параметров ширина окна, со строкой прокрутки или без, с заголовком верхнего уровня или без, координаты окна, с дополнительным окном параметров или без, элементы меню из FLASH/EEPROM/ROM и т.д.

0

Сообщение от SGE у меня была отдельная в памяти цепочка записей для хранения параметров и связок открытых окон, вместо содержания этого в стеке, как у вас.

В стеке сохраняется всего два байта, первый – ID меню (индекс элемента массива указателей на элемент структуры с параметрами окна), второй – номер текущей выбранной опции. Такой способ облегчает рекурсию.

0

ОДнако, доброго времени суток!
спешу доложить о результатах трудов что я наделал.
что есть сейчас в проекте:
RTOS.
примитивная работа с экраном cx65 на чипе L2F50 (строки, очистка экрана, немного цветов.)
пока псевдоменю. реализована навигация по папкам.

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

что осталось сделать: конфигурационные строки и запуск приложений. собственно то ради чего всё это и задумывается.

по поводу критики - принимаю и аргументирую

Ух. Работа автора - типичный пример как не нужно делать. Сначала программируем потом думаем что именно хотим получить. Я уж молчу о простой алгоритмической базе.

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

Вообще из своего опыта работы и переписывания (дописывания) готового проекта под новый тип дисплея могу посоветовать следующее. 1) Отложить железо в сторону. 2) Взять лист буниги и карандаш. 3) Набросать эскизы страниц дисплея с менюшками, как бы хотелось чтобы это выглядело. 4) Посмотреть как это стыкуется с возможностями дисплея. 5) Начать писать менюшку и проверять в железе.

читаем выше. у меня 70% процентов времени - работа с блокнотом. весь стол в листах буниги(жена психует бардаку на столе, но бардак только на столе). 20% ловля косяков и 10% само программирование.
причём я вопросы начинаю завадавать только после того как несколько дней самостоятельного мозгования проблемы.

никому не нужно 150 пунктов в ряд

может и не нужно. согласен. потому и сделал динамическое отображение страниц.
есть 4 устройства.
устройство 1 - 2 настройки.
устройство 2 - 20 настроек.
устройство 3 - 8 настроек.
устройство 4 - 50 настроек.
значит будет 4 папки в корневом каталоге:
папка1 с двумя настройками первого устройства
папка2 с двадцатью настройками второго устройства
папка3 с восемью настройками третьего устройства
папка4 с пятьюдесятью настройками четвёртого устройства.
но вот незадача... на экранчике можно показать только 8(восемь) строк в один момент времени максимум. и всё финиш.
что делать? плодить ещё подпапки? зачем, если логически настройки итак уже собраны каждая в свою кучку(папку)
поэтому я и сделал постраничное изображение. при этом в папке может быть от 1 до 255 элементов. значит страниц может быть от 1 до n элементов/ m строк на экране. всё настраивается. и процедура прорисовки сама считает с какой строки по какую рисовать в данный момент.

вот видео как работает

http://www.youtube.com/watch?v=w2a-AIhhP2k
исходник прикладываю

[78.28 Кб]

0

Я год назад делал нечто подобное: пульт управления несколькими устройствами с отличающимся функционалом. Поскольку устройства были близки по функционалу, то я сделал меню по запросу. Пульт получает от устройства ID и список возможных регулировок. В зависимости от этого и реализовывалось меню. Потратил я на это довольно много времени, но теперь мне не нужно переписывать программу пульта для управления новым устройством с новым функционалом. Общаются они по двухстороннему однопроводному уарту, так что всё подключение - стерео мини джек.

0

Мне кажется проще добавить в устройство BT / BLE / WiFi адаптер и на любом индроиде / Chrome сделать меню.

Произвольной красоты и без глазонапрягов и геморроя.

0