GUI (графический интерфейс)

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

Приобрел для своего проекта набор: Ардуино Мега, дисплей 480х320 графический, GPRS и клавиатуру цифровую. Ну и так еще, по мелочи, что сейчас не важно. Проект - контроль полупромышленного оборудования. Ардуинка будет контролировать работу самого оборудования, а также собирать данные, накапливать их на флэшке и передавать по каналам GPRS на сервер. В пятницу долгожданная посылка до меня добралась (неделю пришлось из почты выбивать), все выходные просидел над сборкой тестовой платформы. Освоился, научился шагать двигателями, отображать данные на экране, читать и писать в файлы, gprs модуль тоже вроде освоил. Теперь хочется бОльшего.

Хочу графический интерфейс для своего проекта.

Не обязательно, как у винды, но хотя бы как TurboVision (наверное, мало кто помнит, но в эпоху программирования под ДОС был такой псевдографический интерфейс под Turbo Pascal, и кажется под С++ тоже).

Уточню - не графическая среда разработки, а графический интерфейс для созданной программы!

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

В общем, есть ли готовая библиотека графического интерфейса под ардуино? Желательно, конечно, объектная.

 

Столкнулся с подобной задачей - нужен графический интерфейс для отображения параметров и настроек. Думаю сделать гибридно МК + смартфон/планшет на Андроид. Это будет более реально чем рисовать графику на экранчике.

 

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

Хм, использовать смартфон тоже прикольно... Это у меня уже следующий шаг предполагался - удаленный интерфейс, который в точности повторяет локальный, только работает через GPRS. Вот только не знаю, как достучаться до ардуинки извне. Наверное надо будет сделать web-сервер, который будет посредником, а саму ардуинку тогда придется держать все время онлайн, или по крайней мере разв несколько секунд проверять, не ожидает ли кто ее "у аппарата"

 

Вывести надпись (разными шрифтами), нарисовать картинку или простой график, это все вполне по силам Ардуино + LCD. Но вы то хотите графический интерфейс! Я бы понял еще выводить инфо в текстовом виде, но графику вряд ли потянет на приличном уровне.
А мне и вовсе надо с тачскрином, чтобы можно было пальцами ползунки двигать и цифры менять нажатиями на рисованные кнопки. Как без смартфона такое реализовать, ума не приложу.

 

Я еще помню времена, когда операционная система влезала на дискету, а первый мой компьютер был Синклер, с оперативной памятью аж 32 кБ. И что удивительно, на нем в графические игры играли, многие из которых по сей день остаются классикой жанра. Так что сделать графический интерфейс МОЖНО. Конечно, придется отказаться от таких наворотов, как тени, скругление букавок, но самое необходимое вполне можно реализовать. Кстати, графический интерфейс сразу предопределяет переход к событийному программированию. Но это отдельные тонкости.

По сути самые основные элементы это собственно окно, текстовое поле, поле ввода данных (текстовых или числовых), чекбокс, радиобаттон, кнопка и меню. Ну и вспомогательные элементы - рамка и линия. Дальше уже можно добавлять закладки для страниц, ползунки, прокрутку, списки, картинки, графики и сетки. Но это необязательно. Это все таки микроконтроллер, а не микрокомпьютер. Так вот именно основные элементы интерфейса реализовать мне кажется несложно. Удивяюсь, почему на готовую библиотеку нет ссылки в описании дисплея ;-)

 

Подумаешь Синклер, у меня первый был Д3-28, это такой большой калькулятор с чугунным экраном и магнитофонной кассетой вместо флешки. Так что теперь в лес и на ветки? ))

Сделать, наверное, можно. Более того, на ютубе есть примеры подобного. Вот только какой смысл? Почти вся память и ресурсы МК будут уходить под работу с экраном, а на собственно то чем он там должен руководить почти ничего не останется. Как вариант, можно сделать собственное подобие контроллера экрана, то есть один МК выделить сугубо на интерфейс с готовыми формами, на который передавать данные что именно показывать. На спор сделать можно, конечно. Этакий экранчик с отображением температуры и влажности, например.

Но для реальных промышленных применений этого маловато. Данных много надо отображать, возможно в нескольких окнах. Разрешение 480х320 не позволит многого. А как быть с обратной связью? Чтобы не только на экран но и с экрана данные приходили?

Сколько стоит такой экранчик? Намного дешевле простенького смартфона?

 

Такой экранчик стоит, возможно, даже дороже простенького смартфона. Дело тут в другом - в законченности решения. Возможно, стоило вообще получше присмотреться и взять микроконтроллер на базе Linux. Там вроде как проблем с памятью таких нет.

Надо подумать. Имеем 8 кБ оперативки под переменные. Из которых 1.8 кБ (20%) сразу съедают объявление экземпляров gprs и utft. Не очень понятно, зачем им столько. Ну да ладно. Под логику работы самой программы мне за глаза хватит 1 кБ. Но лучше перестраховаться. В общем, пусть под графический интерфейс можно будет использовать только 1.2 кБ, чтобы под все остальное оставалось 5 кБ. При этом на объем памяти под код такого жесткого ограничения нет, этой памяти в избытке, при такой скромной SRAM. Значит, объекты интерфейса надо создавать на ходу программно. Если ограничиться только простейшими возможностями и делать интерфейс по принципу вложенных объектов (т.е. дочерний объект всегда входит в родительский), то это избавляет от необходимости отслеживать перекрытия объектов при отрисовке (самая сложная часть интерфейса), соответственно каждый объект - это четыре координаты и два цвета, плюс отображаемая им информация. Информацию никуда не денешь, под нее память так и так нужна. Но все остальное - это 14 байт. На полсотни объектов должно хватить... Мда, не густо.

 

Смотря что отображать. Просто текст или еще картинки-графики-диаграммы?

Кстати, вот простейший способ не только отображать что-либо через смартфон, но и воздействовать через него на Ардуину.

 

А вот такой вопрос... Структура, объявленная как const - она в какой памяти хранится, в ОЗУ или на FLASH вместе с кодом?

 

В оперативке. Если нужен флэш - используйте при объявлении макрос PROGMEM, но перед использованием все равно придется копировать из флэша.

 

Создать GUI на ардуино можно вы правы, можно даже создать Arduino OS при желание с командой строкой, вопрос только зачем.
Я сейчас в фоновом режиме когда есть время занимаюсь созданием своей распределенной системы управления помещениями, система состоит из трех базовых концепций:
Устройства контроля, стоят физически в помещении и имеют прямой доступ к физическим устройствам, датчикам, свету и тд и тп, имеют в себе только базовую критическую логику и не больше.
Сервер, он общается с этими самими контролерами помещений, он нифига не знает о физических датчиках он общается на уровне абстракций, температура воздуха, свет и тд и тп. Но зато содержит всю высокоуровневую логику, где когда и при каких обстоятельствах например включить свет, так же содержит состояние всей системы.
Клиенты, это все что угодно, декстоп-программа под винду, смартфон, веб сайт, пофигу, все что может подцепится к серверу по TCP/IP, клиент не имеет никакой логики это чистой воды GUI для отображения данных и отдания команд, по средствам нажатия красивых удобных кнопочек. Клиент не решает включить что то или нет, это лишь трансляция нажатий в сторону сервера и отображения информации от сервера.. и точка.

Если вы говорите о событийных моделях, то значит ООП вам не чужд как и базовые концепции отделения данных от представления, но почему то многие помнят про ООП когда пишут программу но забывают о нем когда проектируют всю систему (Сейчас я это понимаю, но до сих пор помню один свой глупый вопрос который я задал Мегакотейке не подумав, а точнее не понимая этого)

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

Я отделил данные, логику и представления не на уровне кода а на уровне элементов системы, сделав её гибкой и использовав для каждого уровня наиболее подходящие инструменты, не нужно превращать бедный МК в целую операционную систему, делающего все что он бедный только потянет, расширение, сопровождения и изменения станут просто всеми кругами ада

Сделайте ваш МК прсото неким устройством который будет работать с физ устройставми и организуйте связть этого МК с чем либо, используя некий протокол обмена данными и командами, в самом простом случае с мобилой по Bluetooth, а уж на том же Андроиде создавать GUI в целом занятие не сложное, хотя и потребует работу с потоками что бы не повешать GUI поток и не получить ANR в случае если ответ от устройства на команду будет дольше 5 сек, но зато получите удобный, расширяемый GUI а главное сможете все это менять не трогая МК, крутить вертеть, да хоть OpenGL с 3D

У каждого свои цели и задачи и средства достижения цели, я вам описал своё решение, которое возможно вас натолкнет к каким то идеям, но я не предлагаю такое решение как единственно верное, просто делюсь своими решениями

 

Привет, NR55RU Давно не слышно было

 

ИгорьК, и вам моё почтение как и всем участникам форума с кем знаком
Всячески прощу прощения за офф-топ, но что бы не отвечать каждому из старых знакомых по форуму, отвечу.
Отсутствовал временно так как активно изучал разработку под Android, пришлось от всего абстрагироваться что бы изучение шло эффективнее и базовые концепции Android не перемешивались с другими, теперь буду неспешно мелкими шажками вновь появляться, а то я уже забыл как в С++ класс объявляется, все эта Java проклятущая

 

Я бы с этим слегка не согласился, или, как минимум, уточнил. Но, видимо, не в рамках этой темы.

 

Тема как раз подходящая. Данная концепция очень интересна. Правильно ли я понимаю, что для сервера объектом является зона (помещение), со своими физическими характеристиками и объектами воздействия, а контроллер - это канал получения информации и воздействия. Т.е. может быть зона, в которой нет контроллера (например, сгорел), и таким образом зона есть, но она слепая, глухая и безрукая. А клиент работает с уровнем управляемого объекта в целом. Он видит зоны, но ему пофиг на средства взаимодействия с зоной. Для него сервер является средством взаимодействия.

Насчет моего вопроса - речь не идет о создании полноценного пользовательского интерфейса. Мне нужен лишь базовый графический интерфейс. Например, вызываю команду (условно) СоздатьНадпись(Х, У, ширина, высота, "Заголовок", ССЫЛКА_НА_ПЕРЕМЕННУЮ, Формат) и далее у меня на экране постоянно отображается значение данной переменной в заданном формате. Когда я в программе меняю эту переменную (например, считал с порта новое значение, или вычислил) - значение на экране тоже меняется, а мне не надо ни о чем париться.

Я прикинул, оперативной памяти, если экономить, хватит штук на 40 графических элементов. Т.е. примерно одного порядка величин с тем, сколько у контроллера портов ввода-вывода. Если же для создания интерфейса использовать память программы (т.е. интерфейс полностью статический, а для разнообразия можно использовать подгружаемые картинки с флэшки, как это делают в онлайн компьютерных играх), то ограничений особых нет.

МЛИИИИИН!!!! ОСЕНИЛО!!!!

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

 

И будет каждая кнопка прорисовываться по несколько секунд.

 

Я попроще выскажусь. Чтобы дом был реально умным, надо чтобы:
- каждый управляемый объект имел свой собственный управляющий элемент,
- имеющий независимую от ЦП (центрального процессора) логику работы и,
- оповещал о своем состоянии ЦП, а также
- мог получить от ЦП информацию о необходимости смены режима, причем
- ЦП агрегирует и отражает информацию о каждом управляемом элементе таким образом, что
- жителю дома не нужно постоянно нажимать на какие-то кнопки, и
- вообще не нужно никуда смотреть, потому что
- умный дом имеет специальный пуш-канал для удара по башке жителя если что-то идет не так.

 

- это сильно!

 

(дополнительно)
- отдельные элементы могут и не иметь связи с ЦП, потому как режим работы их не меняется (например, всякие подсветки на движение - чего на них пялиться?)