Организация простого одноуровнего меню
- Войдите на сайт для отправки комментариев
Чт, 19/03/2020 - 22:12
Нужно сделать "простое" меню для 1602, выглядещее как
> Volume: <50dB>
Balance: <Stereo>
Level: <OFF> // пункты ниже отображаются на след экране
и так 20-30 пунктов вниз, отображающие текстовые или цифровые значения, которые можно менять программно в цифровом виде и выводить цифро-буквенное значение на экран. Действия в каждом пункте повторяются - поместили указатель и влево-вправо поменяли значения. Но значения могут быть любыми (целое, дробное), с разным шагом, в разном диапазоне, с разным текстовым эквивалентом для вывода на экран и с разными действиями после их установки. Все просто, но я не знаю как организовать данные, чтобы было удобно при 20 пунктах - одномерным или многомерным массивом, или другой структурой.
Например массивами:
char* MenuName[] = {"Mute", "Level", "Balance", "Vol On"};
float DefaultValue[] = {0, 0, -50, 1.5};
или отдельно расписывать каждый пункт меню, внутри которого будут действия для конкретного пункта с заданными диапазоном изменения переменной, ее значениями, и текстовым эквивалентом на экране.
И еще нужно 20 переменных читать-писать в еепром, желательно разом. Нашел такое:
struct strMenu { // структура данных
int Volume;
int Balance;
int Mute;
int Level;
}
Вроде struct выглядит норм. Какие функции-классы-структуры мне посмотреть для использования в меню?
*Вроде struct выглядит норм. Какие функции-классы-структуры мне посмотреть для использования в меню?
Массив экземпляров виртуального класса-родителя всех возможных вариантов пункта меню.
Ответ на вопрос во многом зависит от того, является ли меню плоским или древовидным.
том на экране.
И еще нужно 20 переменных читать-писать в еепром, желательно разом. Нашел такое:
struct strMenu { // структура данных int Volume; int Balance; int Mute; int Level; }typedef struct { // структура данных int Volume; int Balance; int Mute; int Level; } values_t; #include <avr/eeprom.h> values_t STORED EEMEM = { 1,0,0,1 }; // Тут начальные значения values_t values; // читаем блок из памяти eeprom_read_block(&values,STORED,sizeof(values_t)); // Пишем изменения в пямять eeprom_write_block(&values,STORED,sizeof(values_t)); http://arduino.ru/forum/programmirovanie/klassy-arduino-po-qwone-dlya-ch...
https://tsibrov.blogspot.com/2018/10/LiquidCrystalI2CExt.html
А на чем меню делать будете (в железе)?
А виртуальных меню тут Вам туеву хучу насоветуют.
Azathtot зачем такие сложности c епроме?
у меня работает проще:
struct strV { float Volume; } V; EEPROM.put(address, V); EEPROM.get(address, V);А где сложности-то? У вас просто обертка над тем же самыми методами, если что.
Ну и к тому же я как ни странно не пользуюсь Arduino библиотекой. Да и саму Arduino IDE видел только на картинках :)
А, теперь понял. Я еепром библиотеку во внимание не беру, она не мешает.
Как мне сделать чтобы структуры V и VDefault (и соответственно переменные V.Volume, V.Mute), определенные в Setup(), были видны глобально - в Loop() и функциях?
struct strV { float Volume; byte Mute; // и куча переменных }; // значения по-умолчанию и текущие: strV Vdefault = {-50, 0} ; strV V ;Объявить их в области глобальных переменных, например.
Угу, объявил и обиделся на нану и вообще на ардуино. Нана на 74% рама меня послала, а писать код еще нужно.
Когда /космические корабли../ другие производители ставят в ту же плату условно 1ГГц проц и 0.5 гига памяти, ардуино штампует zx-спектрум-совместимые платы на 16 МГц ДУА-МЕГА-размеров с характеристиками спектрума и древними процами размером с пол-платы, в половине из которых даже епрома нет, и все довольны, видимо мигают светодиодом и писаются от бегущей надписи хелоу ворд.
Нашел Teensey 2.0++, прифигел от количества портов и памяти в том же размере платы (не нужно вешать 16 битный экспандер портов - еще доп. экономия места), поставил надстройку ТинсиДуино для Arduino IDE, скомпилировал тот же скетч без изменений. Результаты Нано/Тинси: 13772 / 14644 флеш, 1533 / 1458 рам. Обмен -872 флеш на +75 рам.
Причем компилятор тинси (? или кто там щас компилил) выдал мне кучу недоработок и рекомендаций по улучшению, которые ардуиновский компилятор 1.8.9 просто проглатывал. Более того, ардуиновский компилятор игнорирует существенную ошибку - объявление переменной в switch...case без заключения кейса в скобки, и я мозг парил, не зная причины, почему кейсы, следующие за кейсом с объявленной переменной - игнорируются при вызове, хотя переменная использовалась только в тот кейсе, где она была объявлена, и даже если ардуиновский комилятор это прое..пустил, то сама логика работы программы не будет нарушена (нахрена программе лезть в кейс, который не подходит, если рядом есть следующие?), но в реале все наоборот. Арррр. Компилятор тинси эту ошибку показывает и не позволяет скомилировать.
Абидчивый? Ну, бывает :-)
Угу, объявил и обиделся на нану и вообще на ардуино. Нана на 74% рама меня послала, а писать код еще нужно.
А может стоило изучить магические слова #include <avr/pgmspace.h> и PROGMEM? Тогда и обижаться не надо.
Помнится делал я один проект на XMega, так там радости было полные штанишки - 16кб SRAM. Я туда даже java-машину на радостях запихал.
Не хочу с ним извращаться. После дражайшего счёта каждого бита оставшейся рам, магия испарится при расширении программы. У меня там уже Serial, SPI, I2C, OLED (может и графический будет), уже как минимум 32 внешних порта + забиты все ардуиновские, куча динамических переменных, а мне всё мала. И все это шевелится если ткнуть палочкой. Нана мне явно мала, а ардуино не производит платы, которые я хочу. Зато ардуино делает плату Micro (!) с двумя пятаками NC. Сделали бы 4 - была бы MicroNC.
Nya - когда человек, который не знает элементарных вещей, типа области действия переменных (привет переменным в кейсе) - берется за проект с таким количеством портов и функций - остается только пожелать ему удачи... (проекту, а не человеку :)
Это я к тому, что желание ничего не умея - сразу построить марсолет - характерно для новичков. и если у них из этого ничего не выходит - стоит ли обижаться на ардуино, она ли виновата? :))))
У меня там уже Serial, SPI, I2C, OLED (может и графический будет), уже как минимум 32 внешних порта + забиты все ардуиновские, куча динамических переменных, а мне всё мала.
Вы эта как - пугаете что ли? Дык я, не особо напрягаясь, под пиво, организую Вам на 1 порту ардуинки уно 16 портов, а малость подумав и 64. Ну а если Вы и правда марсолет запускаете, то да - тут нужен суперкомпьютер под собственноручно написанной ОС и ИИ в придачу.
Объектно ориентированное программирование было создано именно для того, чтобы превратить не читаемую и многокомпонентную программу в логичное обращение с объектами. Почитайте - очень полезно.