Nord, Добрый вечер! Спасибо за рекомендации. Все получил буду пробовать.
Отредактировано qewin (2019-02-01 23:08:11)
Программирование ATMEL в BASCOM. |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Программирование ATMEL в BASCOM. » Дисплеи и индикация » LCD дисплеи Nextion ?
Nord, Добрый вечер! Спасибо за рекомендации. Все получил буду пробовать.
Отредактировано qewin (2019-02-01 23:08:11)
Тот пост - Приём по USART в прерывании. который описал sasha_1973, да , я по нему и делал только заменил - Принятый_код_символа_usart = " Udr0" на " Inkey() "
так как это был не буфер а бегущая строка
В отношении "бегущей строки"...
А чего вдруг дисплей постоянно в UART молотит ? 
Сделать отправку команды по событию.
Прошла минута - выплюнул время.
Было "нажатие на кнопку" - передал команду...
В остальное время в UART-е тишина.
Nord, Привет! Что хочу сказать про UART , принцип у меня пока такой
1. Все переменные идут на дисплей , проблем нет!
2. С дисплея я получаю ( пока) только когда нужно установить время ( переменные на данный момент час:минуты) нажимаю на дисплее в МК перехожу на подпрограмму, в этот момент весь UART в " стопЕ", на дисплее набираю нужное время (переменные) и по нажатии на др.клавишу уходят на МК. Там их я принемаю четко в строковом формате, но не получается их перевести в переменную которая может быть сохранена (час)15 "str" и час= 15 в "Byte" 
А чего вдруг дисплей постоянно в UART молотит ?
Сделать отправку команды по событию.
Да, только не дисплей а МК молотит! Думал об этом то есть нужно . Пока с улице темпер. прилетает каждые 8 сек. после надо будет сделать через ~ 1 мин. а вот с датчика BME280 шлет непрерывно.
Отредактировано qewin (2019-02-02 12:14:28)
Да, только не дисплей а МК молотит! Думал об этом то есть нужно . Пока с улице темпер. прилетает каждые 8 сек. после надо будет сделать через ~ 1 мин. а вот с датчика BME280 шлет непрерывно.
Температуру можно замерять вообще через 10 мин.
Домашний климат - не производственный процесс, где иногда даже 1 сек - слишком редко... 
В ВМЕ чего всполошился ?
Он сам слать не будет, если его не просить... 
Тут опрос можно вести еще с бОльшими периодами...
Замер давления раз в полчаса - вполне достаточно, чтоб понять растет оно или снижается..
Ну, с влажность., возможно, нужно почаще...
Резюмирую: чаще раза в 10 мин. климатические датчики в бытовых условиях опрашивать нет смысла.
Да, только не дисплей а МК молотит!
Если в UART молотит МК, то это уже проблемы дисплея, а тут, как я понимаю, жалоб нет... 
Вопросы по приему от дисплея.
МК ждет от него ответа на свои посылки ? Зачем ?
Резюмирую: чаще раза в 10 мин. климатические датчики в бытовых условиях опрашивать нет смысла.
Это обязательно учту! Я тут полазил инфу почитал, так как есть проблемы, если я правильно понял, что BASCOM AVR IDE 2.0.7.8 который есть , проблемы с переводом "STR" формата в другие
. Ладно , буду копать дальше.
Я тут полазил инфу почитал, так как есть проблемы, если я правильно понял, что BASCOM AVR IDE 2.0.7.8 который есть , проблемы с переводом "STR" формата в другие
Ссылочку, плиз...
Впервые слышу, у самого 2.0.7.8... 
Жалоб не было...
qewin написал(а):
Да, только не дисплей а МК молотит!
Вопросы по приему от дисплея.
МК ждет от него ответа на свои посылки ? Зачем ?
Да нет, Nord, я может не правильно объясняю. Молотит то есть МК собирает все данные с датчиков ( правильно ты пишешь что и достаточно раз в минуту, ну по нужде) и время и шлет их на показометр Nextion
Да нет, Nord, я может не правильно объясняю. Молотит то есть МК собирает все данные с датчиков ( правильно ты пишешь что и достаточно раз в минуту, ну по нужде) и время и шлет их на показометр Nextion
У дисплея есть свой модуль RTC ?
Если да, то удобнее его использовать.
В моем варианте МК практически вертится в цикле.
Каждую минуту от дисплея (есть нем RТС) прилетает время.
МК в ответ отправляет имеющиеся данные о состоянии периферии и данные датчиков.
Каждую 9-ю минуту (МК отсчитывает) производится опрос датчиков (освежение данных).
Если в дисплее нет RTC, то можно от внешнего модуля настроить прерывание и плясать уже отсюда.
qewin написал(а):
Я тут полазил инфу почитал, так как есть проблемы, если я правильно понял, что BASCOM AVR IDE 2.0.7.8 который есть , проблемы с переводом "STR" формата в другие
Ссылочку, плиз...
Впервые слышу, у самого 2.0.7.8...
Жалоб не было...
Ссылка на пост 2 BASCOM-AVR (версия BASCOM-AVR: 2.0.8.1) но не знаю.
- Передача строковых констант со встроенным {034} привела к дополнительному (нежелательному) пространству.
- доступ к массиву переданных строк в sub без информации о длине, но с постоянным индексом.
- добавлена функция crcmb funtion. (контрольная сумма для modbus)
- для xmega i2cstop вы можете определить константу с именем _TWI_STOP_1 или _TWI_STOP_2, чтобы изменить поведение.
- функция makemodbus () 1, 2 и 4 добавлена в modbus.lib
- поддержка xmega добавлена в getrc
- загрузка в PDF теперь также проверяет / загружает руководство BASCOM-AVR
- PRINTBIN не принимает константу для дополнительного канала: printbin #someconst , Исправлена.
- обновление из приложения упрощено. см. справку.
- printbin поднял ошибку при печати нескольких переменных
- симулятор не показал правильное шестнадцатеричное значение для отдельных переменных.
- fusing, который использует ftoa, использует таблицу, которая может быть загружена на границе страницы. это может привести к проблемам rampz. исправлено.
- crc8UNI добавлен для обычного crc8 CCITT
Я не ищу никаких оправданий и отговорок, буду переписывать пробовать.
Отредактировано qewin (2019-02-02 12:48:41)
Ссылка на пост 2 BASCOM-AVR (версия BASCOM-AVR: 2.0.8.1) но не знаю.
Так там про 2.0.8.1...
Причем тут 2.0.7.8 ? 
И про "проблемы с переводом "STR" формата в другие" что-то не встретил... 
qewin написал(а):
Да нет, Nord, я может не правильно объясняю. Молотит то есть МК собирает все данные с датчиков ( правильно ты пишешь что и достаточно раз в минуту, ну по нужде) и время и шлет их на показометр Nextion
У дисплея есть свой модуль RTC ? - Нет!
Если в дисплее нет RTC, то можно от внешнего модуля настроить прерывание и плясать уже отсюда.
Понимаешь..... ,Nord, тут как бы настроился уже, как бы нарисовал все в голове ....! А тут переменную все уперлось! Пес его знает !
тут как бы настроился уже, как бы нарисовал все в голове ....! А тут переменную все уперлось! Пес его знает !
Я в таких случаях банально начинаю все сначала... 
От Nextion в МК какие-либо команды идут ?
Если да, то вопрос приема для МК актуален.
Если нет, то приемом по UART можно не заморачиваться.
Посылка "Т2415" и ее дальнейшая разборка в МК лишена смысла, т.к. время приходит из другого источника.
От Nextion в МК какие-либо команды идут ?
Идут только при условии , остальное Nextion работает на прием.
Nord я тебе в личку кинул небольшой кусок видео
Идут только при условии , остальное Nextion работает на прием.
Вообще тогда проблем не вижу... 
Команду можно передать одним символом, если отсутствуют сопутствующие данные.
Т.к. RTC в дисплее нет, то передать можно только команду от кнопки и значения слайдера, если они задействованы. А это не настолько длинная посылка...
"Бегущей строки" в буфере тоже не должно быть при правильной организации приема.
Я с самого начала твержу - надо добиться уверенного приема по UART от Nextion... 
Видео гляну вечером, на работе некогда... 
С дисплея я получаю ( пока) только когда нужно установить время ( переменные на данный момент час:минуты) нажимаю на дисплее в МК перехожу на подпрограмму, в этот момент весь UART в " стопЕ", на дисплее набираю нужное время (переменные) и по нажатии на др.клавишу уходят на МК. Там их я принемаю четко в строковом формате, но не получается их перевести в переменную которая может быть сохранена (час)15 "str" и час= 15 в "Byte"
Это все понятно, непонятно другое - насколько устойчивый (правильный) прием посылки от дисплея.
Меня все-таки смущает "бегущая строка" в буфере UART... 
Дисплей должен "выплюнуть" Т2415 и замолчать.
Получается, что не замолкает или МК не завершает прием...
Я еще не дошел до правки. Типа "бегущая " была, когда было так : Принятый_код_символа_usart = " Udr0" сделал так перестало " Inkey() "
Отредактировано qewin (2019-02-02 15:10:43)
Я еще не дошел до правки. Типа "бегущая " была, когда было так : Принятый_код_символа_usart = " Udr0" сделал так перестало " Inkey() "
Inkey ждет прихода очередного символа, потому и идет некая селекция при приеме.
При приеме по прерыванию (как изначально) буфер набивается до прихода 13.
Кроме того, контролируется количество принятого.
Надо бы еще проверить, каким образом дисплей отправляет.
Да, еще вспомнил одну фичу ! 
У Nextion UART мощнее, чем в МК и при ошибочном подключении может "задушить" модуль UART в МК...
Тогда при приеме/передаче тоже каша будет...
Обязательно надо поставить резисторы 100...300 Ом
Я себе так один спалил, лежит теперь, "инвалид без UARTа"... 
Nord, чесслово ты наверное писал дольше
, я в личку кинул ссылку на яндексе 3 мин. посмотри. Думаю из него будет видно.
А, может ты с телефона "трафик " ну тогда пардон 
Отредактировано qewin (2019-02-02 15:41:00)
Nord, чесслово ты наверное писал дольше , я в личку кинул ссылку на яндексе 3 мин. посмотри. Думаю из него будет видно
Не могу я на работе туда попасть... 
Политика IT-безопасности такова, что ряд ресурсов - "ошибка 404" 
Например - Однопупсики, Вконтакты и пр. соцсети, Ютубы, Али...
Я.Диск тоже в списке. 
Посему - кино только вечером. 
К вопросу об отправке из дисплея...
print выдает в UART все как есть, без оконечных 0xff 0xff 0xff
print t0.txt - выдаст голый текст - значение текстового поля.
print "Uraaaa!" - напечатает Uraaaa!
---------------------------------------------------------------------------------------------------------------------------------
printh загонит в UART один в один то, что будет стоять в аргументах в hex формате через пробел с маленькой буквы:printh a0 fe 11
К чему я - в конце пакета отправки при любом способе должен быть байт 0D (Chr(13)).
Т.е., не printh a0 fe 11, а printh a0 fe 11 0D
Это соблюдается ?
Если его не будет, то код Александра (по прерыванию) будет крутиться практически вечно и тогда возможно появление "бегущей строки" в буфере.
Inkey использует другие алгоритмы приема, тут 0D не нужен.
Отредактировано Nord (2019-02-02 17:21:08)
К вопросу об отправке из дисплея...
print выдает в UART все как есть, без оконечных 0xff 0xff 0xff -------------------- print выдает в UART все как есть, без
print t0.txt - выдаст голый текст - значение текстового поля. -------------------- print t0.txt - выдаст голый текст
print "Uraaaa!" - напечатает Uraaaa! --------------------- печатает Uraaaa!
---------------------------------------------------------------------------------------------------------------------------------
printh загонит в UART один в один ------------------------------ Nextion гонит при нажатии кн.print "T"
print ho.txt ' 21час ------------------------------- На МК приходит Т2117
print min0.txt ' 17мин
printh 0dК чему я - в конце пакета отправки при любом способе должен быть байт 0D (Chr(13)).
Т.е., не printh a0 fe 11, а printh a0 fe 11 0D
Это соблюдается ? ---------------------- ДаInkey использует другие алгоритмы приема, тут 0D не нужен. ------- Очень хорошо
![]()
Отредактировано Nord (Сегодня 17:21:08)
Ну , теперь что сделал и появились новые вопросы.
Переписал как Александр и ты прислал.
Получается
в бувер приходит от Nextion пример: T2135
chass1 = Mid(priem, 3, 1) ' Так не проходит = Mid(priem, 3, 2) получается Х....
chass2 = Mid(priem, 4, 1)
minuts1 = Mid(priem, 5, 1)
minuts2 = Mid(priem, 6, 1)
chas(1) = val(chass1)
chas(2) = Val(chass2)
minut(1) = Val(minuts1)
minut(2) = Val(minuts2)
xxx=chass1+chass2 ' Собираем вместе. Час А, это правильно или есть функция склейки байтов?
yyy=val(xxx)
Lcdat 1 , 1,priem ' Str Буфер
Lcdat 2 , 1,chas(1) ' Старш.р Часа 2
Lcdat 3 , 1 ,chas(2) ' Мл.р Часа 1
Lcdat 4 , 1 ,minut(1) ' Старш.р Минуты 3
Lcdat 5 , 1 ,minut(2) ' Мл.р Минуты 5
Lcdat 6 , 1 ,xxx ' "str " Час 21
Lcdat 7 , 1 ,yyy ' "hex" Минуты 35
Отредактировано qewin (2019-02-02 20:59:24)
' Собираем вместе.
А, это правильно или есть функция склейки байтов?
Нет, не привязывайтесь полностью к моему варианту.
У меня каждая цифра выделяется, чтоб потом отправить вторичным часам.
В них для каждой цифры свое место.
Так проще... 
В вашем случае надо выделять часы и минуты двухзначные и ими оперировать.
Посмотрел видео...
Все настраивается, передается...
По крайней мере, на контрольном дисплее адекватность.
Считаем вопрос закрытым ? 
qewin написал(а):
' Собираем вместе.
А, это правильно или есть функция склейки байтов?Нет, не привязывайтесь полностью к моему варианту.
.
Я спрашивал , есть функция склейки байтов? Не 2+2=4 а 2+2=22
По поводу привязки к вашему проекту нет, просто легче было скопировать и вставить сюда 
Посмотрел видео...
Все настраивается, передается...
По крайней мере, на контрольном дисплее адекватность.
Считаем вопрос закрытым ?
Видео было для UARTа на котором вообще строковые не конвертируются в нех как надо зато можно забирать из буфера сразу число 12 а сейчас только по одной 1 потом 2 !?
Иначе белиберда какая то
Думаю вопрос с UARTом можно закрыть а с переменными буду дальше разбираться. Спасибо!
А не было мысли на уровне дисплея конвертировать значение текстового поля в байт и его уже передавать ?
У Nextion есть для этого возможности.
Думаю, было бы гораздо проще, т.к. в передаче было бы всего два байта (+0D
).
А, это правильно или есть функция склейки байтов?
Не 2+2=4 а 2+2=22
Только на уровне строковых переменных с последующим Val()
Upd...
Хотя нет, вот тут преобразовать строку в байтовый массив есть хорошие решения !
Отредактировано Nord (2019-02-02 23:36:46)
| Дисплей DWIN | Дисплеи и индикация | 2025-01-13 |
Вы здесь » Программирование ATMEL в BASCOM. » Дисплеи и индикация » LCD дисплеи Nextion ?