Можно в прерывании (например 1 ms) выводить по одному символу на дисплей (задержка будет обеспечиваться за счёт прерывания). Данные на дисплей будут выдаваться из буфера (массив в памяти). И для того, что бы поменять символы на дисплее нужно будет только заполнять буфер дисплея нужными значениями. Как это работает можно посмотреть здесь uC/avr_menu: https://disk.yandex.ru/d/GBRtXyNC0KdEeA В примере показана работа с двумя буферами дисплея: пока заполняются данные в буфер дисплея на дисплей выводится данные из другого буфера (для исключения видимого изменения данных на дисплее).
завидую я людям, которые берут 72-мегагерцовый МК и пишут программу управления термоядерным реактором, единственным узким местом в которой является медлительность двух команд ЖКИ аж с 32я символами! вот чую подвох в этой ситуации, да не пойму, где он...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
А что, дисплей - это самая главная деталь конструкции и обязательно нужно ставить цветной TFT 480х420 туда, где по функционалу достаточно текстового 1602? Тем более, что медлительность интерфейса дисплея как раз и обходится с другой стороны - не через постоянный опрос бита BSY, а через прерывания таймера, который просто отсчитает заданный интервал. Никаких проблем! Я тут говорю не о 72 МГц, а о несоразмерности длительности поллинга в пересчете на такты. Если величины 125 нс и 40 мкс - это еще терпимо, то 14 нс и 40 мкс - это уже неэффективность. Мышление программиста должно быть гибким, а не следовать единственному выученному 10 лет назад методу.
Самыми лучшими параметрами по энергоемкости, сроку хранения, температурному диапазону и номинальному напряжению обладают батарейки литий-тионилхлоридной электрохимической системы. Но при длительном хранении происходит процесс пассивации. Разберем в чем плюсы и минусы, как можно ее избежать или уменьшить последствия и как проводить депассивацию батареек на примере продукции и рекомендаций компании FANSO EVE Energy.
К 2029 году в России прогнозируется увеличение числа зарядных станций до 40 000. При этом отечественный рынок электротранспорта имеет климатические, потребительские и географические особенности. Для успешной разработки и построения инфраструктуры станций заряда в России идеальным вариантом является использование решений и электронных компонентов китайских производителей – лидеров индустрии электротранспорта и возобновляемой энергетики, которые уже представлены в КОМПЭЛ.
... берут 72-мегагерцовый МК и пишут программу управления термоядерным реактором...
Я тоже им завидую, бо мне пришлось в прошлом тысячелетии на Меге 8МГЦ измерять в реальном времени 4 канала хоть и 50-Гцовых, но по 64 точки на период, рассчитывать где-то там с дюжину параметров с плавучкой и функциями, следить за кнопками управления, выдавать по запросу нужную лабуду на этот самый дисплей, да ещё и по RS485 от компа верхнего уровня отбрехиваться. Опрос готовности дисплея не использовал. Сам удивляюсь - как это мне удалось. Вспомню - вздрогну. ---------- СпойлерНемножко лукавлю: АЦПшной частью занимался подчинённый мелкий МК и выдавал уже готовые оцифрованные точки. ---------- PS Кажется, мои усилия пропали даром. Судя по не обновляемому годами их сайту, фирме уже крындец. И не мой уход тому причиной - глобальные и местные обстоятельства. Ну как тут будешь компенсировать реактивку без польских конденсаторов...
Видимо, у ARV мало опыта в деле, зато много опыта в словах, коль не понимает, какие бывают задачи и конструкции Выучил один-единственный способ, а посылка по прерываниям для него уже настолько сложная тема, что он аж в ступоре Ну чтож, бывает и такое! 1,5 мс молотить в ожидании бита - это конечно похвально. хахаха. Хотя какая, в сущности, неразрешимая сложность в организации отправки команды по прерыванию таймера? Сложно для понимания? Ну что тут сказать, бывает, бывает. Я раньше встречал две крайности. Вторая крайность - на СТМке через DMA и таймер организовать полностью автоматическое дергание всеми ногами и заставить непрерывно по кругу слать буфер дисплея. Был тут, на радиокоте и на другом форуме один "товарисчь" с характерным ником STM32F0, особо радевший за этот способ. Ну да, я тоже попробовал тот способ. Не понравилось, оверинжениринг. Так что, есть две крайности, а истина - она посередине.
... дисплей - это самая главная деталь конструкции и обязательно нужно ставить цветной TFT 480х420 ?
... с анимацией и озвучкой У программистов это называется "бантики завязывать".
Цитата:
посылка по прерываниям для него уже настолько сложная тема,
Сами говорите - истина где-то посерёдке Перегружать прогу лишними прерываниями тоже не гут, если их по функционалу без того достаточно. Но - какой конкретно проект...
Я имел ввиду посередине между полностью автоматической постоянной перерисовкой дисплея и полностью ручным ногодрыгом через ожидание. И говорил, что если на 8 МГц МК такое ожидание еще ниче, пойдет, то при 72 МГц МК это уже будет слишком большим процентом неэффективного расходования частоты МК. И даже в конкретных цифрах - 40000/14. Потому что 72 МГц неспроста же выбирают. Значит, они нужны для другой работы. И не обязательно, что простой дисплей подразумевает несложную работу. На квадрокоптере вон вообще две лампочки, а математики - дайбоже.
до тех пор, пока не узнаю, в чем смысл экономии "простоя", останусь при своем мнении. если на 8-битном 8-мегагерцовом МК тупое ожидание 1,5 мс зачастую ничего не стоит, то на 32-битном 72-мегагерцовом и подавно. а неумение организовать простейшие алгоритмы без DMA и т.п. аппаратной поддержки тоже многое сообщает о программисте
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
я использую библиотеку, которая работает по ожиданию готовности контроллера ЖКИ, т.е. считывает его регистр статуса и анализирует бит занятости. т.е. как бы делает кучу "лишних" обращений. <...> я настаиваю на том, что <...> по прерываниям, не только не даст положительного эффекта, но и ничего, кроме гемора, не даст вообще.
то это ваше священное право, коль вы испытываете гемор с организацией передачи по прерываниям. Видимо, вы просто не понимаете разницы между 72 МГц и 8 МГц и выполняемых задачах. Но это тоже ваше право не понимать и тупить пять раз подряд. Вы свободны и вольны делать что вам лично угодно. Но это не говорит о том, что вы безоговорочно правы. Просто вы не совсем верно информированы по теме, только и всего. Но это тоже ваше священное право быть плохо информированным, не понимать и тупить. Так что на ваши права никто не покушается, вы свободны в своем решении тупить.
Как фанат аналоговой техники, некоторое время назад я был категорически против использования микроконтроллеров для простых действий: реле времени, температуры и т.п. Во время своих экспериментов с микроконтроллерами для хобби понимал, что с цифровыми методами намного проще. Хоть реле времени, хоть датчик температуры я уже предпочитаю подключать к микроконтроллеру и думаю уже радикально противоположное - все: на микроконтроллери . (друг шутит: уже предохранитель - с MCU ).
Здесь не все профессионалы (примерно 90%), а примерно MCU и программирование для отдыха и хобби. MCU в большинстве случаев в цикле (почти) ничего не делать. Так что загрузка данных на дисплей с методической погрешностью будет работь, а в хобби это важно. А напр. мне попадались профессионалы, которые так и остались на уровне "сложной" простой операции (написание все кода: только на ассемблере). У их устройство никогда не усложняется в функционале. Всегда нет времени.
Всегда можно лучше. Правда, каждый способ интересен, но не стоит усложнять до бесконечности. Современные контроллеры допускают загрузку по, казалось бы, неоптимальным алгоритмам. И если это улучшите, эффект будет (почти) нулевым (в 95% случаев на практике). ЦОС с MCU не все делаем. Правда, не буду управлять атомную станцию, ни в Космос не буду летать со своим конструкциями. Личное мнение. (частично пользуюсь переводчиком БГ -> РУ)
P.S. ATmega328P в Arduino Nano пишет обе строки на LCD1602 (123456789012345 и ABCDEFGHIJKLMNOP) за 9632 µs (с двумя перемещения позиции курсора: в начале строк). Однако код состоит из 4 строк.
конечно, я не понимаю разницы между 72 Мгц и 8, потому что никто так и не смог объснить, какие такие задачи не позволяют "тупить" на 72 Мгц, как никто и не смог объяснить или хотя бы продемонстрировать, на что полезное будут потрачены сэкономленные 1,5 мс...
лично я ни разу не сталкивался с тем, что об этом нужно беспокоиться на 8 Мгц, хотя приходилось решать достаточно "большие" задачи - МК успевал "в реальном времени" абсолютно всё. поэтому я и не могу представить, чем можно нагрузить 72 Мгц. это как если бы для текстового редактора не хватило мощности i7. кстати, я в курсе, что плоды рук современных программистов не на всяком i7 нормально работают, и даже знаю, почему...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Что же вы, господа профессионалы, сидите на такой не эффективной операционной системе, там столько тактов процессор простаивает по посту. Заставьте его на благо работать, что нибудь полезное делать.
как раз в этой ОС процессор не скучает: где-то проскакивала инфа, что на каждое нажатие клавиши на клаве винда выполняет больше команд, чем было выполнено за весь полет к Луне Аполлона. современные программисты умеют рационально использовать мощность аппаратуры!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Да когда же я увижу на прилавках наших магазинах их современное творение, телевизоры, тв-приставки, стиральные машины и пр, только противокражные этикетки и вижу.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
на Меге 8МГЦ измерять в реальном времени 4 канала хоть и 50-Гцовых, но по 64 точки на период, рассчитывать где-то там с дюжину параметров с плавучкой и функциями, следить за кнопками управления, выдавать по запросу нужную лабуду на этот самый дисплей, да ещё и по RS485 от компа верхнего уровня отбрехиваться. Опрос готовности дисплея не использовал. 
Выучил один-единственный способ, а посылка по прерываниям для него уже настолько сложная тема, что он аж в ступоре 
