Доброго времени суток форумчане.
Подскажите, где можно прочитать или посмотреть полную информацию насчёт регистра входов. Задача вот в чём. Имеется кнопка, подключенная к DI-входу ардуино на базе ATMega328 или ATMega8. Как отследить нажатие кнопки во время выполнения программы? Т.е кнопка нажимается в тот момент, когда опрос входов уже выполнен и выполняется основная программа, функции и т.д. Прерывания не в счёт.
Конечно не совсем корректное сравнение, но у ПЛК Siemens S7-300 к примеру, есть так называемая область входов, куда записываются данные с регистра входов. Если во время выполнения программы в организационном блоке ОБ1(по типу main или loop) мы нажмём на кнопку, в дальнейшем, при отжатой кнопке и опросе входов мы сможем отследить изменение фронта на конкретном пине, т.е информация об изменении или не изменении фронта сохранится и будет доступна для анализа.
Есть ли такая аппаратная или иная возможность у АtMega8/328?

У М328 PCINT позволяет фиксировать факт изменения уровня на любом цифровом выводе.
Но для кнопок обычно вполне достаточно делать опрос через короткие промежутки времени. Где-то здесь как раз была целая тема вроде "помогите опросить кнопку".

Все регистры в даташите.

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Конечно можно сделать! мешает только то, как это сделать?

Нашёл документ с Системами команд для АВР МК на ассемблере. Не нашёл команду, которая отвечает за выделение фронта. Опять таки про сименс, у которого есть команды FP/FN для выделения переднего и заднего фронтов.


-pyzhman- Вы наверное, говоря про чтение входов/выходов у ПЛК SIEMENS имели в виду команды A, O, X? Если мне не изменяет память, то сигнал на пине мы сможем увидеть только при первичном опрос, всё что далее, это чтение данных из области отображения процесса, а по факту на пине уже может быть 0 или 1 или ещё 100 единиц прийти.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

А, О это выход и вход. Да, всё верно, в начале цикла исполнения программы считываются входа и помещаются в область отображения входов. После исполнения цикла выхода помещаются в область отображения выходов. Естественно, за время цикла входа могут поменяться. Это особо оговаривается в документации. И разработчики программ порой прибегают к прямому чтению входа (если время цикла ну очень уж большое). Но Сименс к вашей задаче не клеится никаким боком.

Отследить можно только опрашивая. Либо прерыванием (а оно почему-то не в счёт) (прерывание же можно сделать не именно под вход, просто вход опрашивать периодически), либо прямым опросом.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

кнопку я к примеру привёл. По факту, есть расходомер, с которого Асинхронно будет приходить 0/1. Хочу сделать простенький тепловычислитель. Расход может меняться, в связи с этим, будет меняться скорость прихода сигнала от расходомера. Может возникнуть ситуация, что пока будет выполняться математика+вывод на дисплей, трансляция в сеть, может прийти сигнал от расходомера, мы его благополучно не увидим и расход получится не точным и далее все расчёты поползут.
А, О это не вход/выход это команды выполнения лог.операция И и ИЛИ.

Что мешает использовать прерывания?

В немецком (коим я пользовался) U и O. И не логического, а VKE. Ну да бог с ним, с Siemens'ом.

Тогда совершенно непонятно, как Вы собираетесь обходиться без прерываний и аппаратных "примочек". Ну поймаете Вы факт перехода, обработаете Вы его через определённое время, а как будете измерять время между импульсами ? На всяких delay_ms'ах ? Ваш расходомер будет показывать "погоду на Марсе", а не расход.

Курсач?

Тогда понятно.

Курсач?

Нет. Для автоматизации отопления гаража. В гараже 2 системы выработки тепла:
1) Твердотопливная водогрейная печь аля Самовар;
2) Тепловентилятор с жидкостным теплообменником от 10-ки с двумя эл.котлами 2х2кВт+циркуляционный насос.
Системы будут увязаны в единую тепловую сеть, с возможностью перемещения или самостоятельной работы тепловентилятора.

Стоит задача посчитать реальную производительность водогрейной печи. Вот для этого и делаю тепловычислитель.

Что же не так с прерываниями? Почему не хотите их задействовать?

Раз тему оформили в отдельную тему, буду задавать вопросы, но сначала, немного о том, о чём шла речь чуть выше.
На фото- водосчётчик с цифровым выходом. В шестерёнке, которая находится на валу, на который устанавливается стрелка показаний ЛИТРажа было просверлено отверстие, которое перекрывает световой поток оптопары. Сигнал с приёмника поступает на схему Опередления линии собранной давным-давно. Схему взята с сайта robozone.su а конкретно, вот ссылка : http://robozone.su/mrc28/15-modul-datchika-linii-na-osnove.html .

Спойлер

Далее. Тепловентилятор с жидкостным теплообменником(радиатор от 10-ки), двумя эл.котлами мощностью 2кВт каждый. Теплоноситель цирк.насос крутит по системе. Данная "установка" находится в стадии пусконаладки.

Водогрейная печь аля САМОВАР. Работает в комплексе с тепловентилятором. Естественной циркуляции теплоносителя не закладывал, только принудительно цирк.насосом.

Так вот задача стоит такая, что необходимо посчитать производительность водогрейной печи. Можно косвенный расчёт произвести, можно вообще не заморачиваться, но ведь это всё скучно Конечно, можно установить ВКТ7 к примеру и голову не греть, но это деньги и пара плат арудино будут скромно пылиться в коробке дожидаясь часа, когда их продадут или выкинут.
В общем, мне самому интересно собрать тепловычислитель, получить опыт и знания!
Т.к система закрытая, т.е нет отбора теплоносителя, значит можно обойтись одним расходомером. Температуру буду мерить на подача и обратке. Датчик температуры есть от Данфоса 0-10В выход, но думаю, обойтись без него.
Вся математика сводится к подстановке значений от вышеупомянутых датчиков: Qгв= Gгв *(tгв - tхв)/1000 = ... Гкал
Сразу скажу, что раньше занимался программированием, но уже давно не кодил, поэтому много забылось.
В данный момент думаю над логикой работы программы. Кстати в сети, только 2 статьи нашёл на тему самодельного тепловычислителя.
Что должен представлять из себя тепловычислитель.
Теститься программа будет под мега328, по факту будет мега8.
ЖК дисплей. В наличии двухстрочный по 8 вроде символов в строке.
Кнопки для навигации. Получается что будет небольшая операционная система.
На ЖК дисплее можно будет посмотреть часовой расход, возможно МГНОВЕННЫЙ, температуру подачи/обратки, суммарно выработанная энергия за сеанс(от затопки до погасания печи), опять таки мгновенная или часовая мощность.
Аппаратная часть есть, дело встало за программной. Работу думаю начать с разработки структурной схемы, что бы было понимание и наглядность для дальнейшего написания программы.
Жду ответов, если есть недочёты, поправляйте. Огромной помощью будет какая то "рыба" для программы.

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

На самом деле, я их не опасаюсь, я с ними просто в своё время не работал Думаю, сложностей не возникнет.

И сразу вопрос! Сигнал от расходомера подключим на пин с прерываниями int0 к примеру. Что будет с дисплеем в момент прихода импульса? Допустим, я буду просматривать инфрмацию-температуру на подаче интересно узнать. Брожу по менюшке и тут бац и прерывание сработало. Экран зависнет с последними значениями или вообще погаснет? Как я понял и предполагаю, будет зависание той информации, которая была до прерывания.

Да ничего с ним не будет. У него же собственный буфер. В него информацию можно хоть раз в год записывать, она будет постоянно на нём "висеть".
Да и даже если бы было необходимо постоянное обновление, ничего бы не случилось. Вся обработка по INT сведётся лишь к записи значения таймера в переменную, с последующим его обнулением. Это максимум пару десятков тактов.
Если все эти процессы "долгие", то можно вообще не париться с внешним прерыванием. Заведите обработчик прерываний на 1 миллисекунду, в нём опрашивайте вход со счётчика на изменение (ловите фронт). Далее заведите переменную, которая будет считать эти миллисекундные интервалы между фронтами. Как фронт пришёл - сохранили значение этой переменной, обнулили её и выставили флаг. Флаг потом спокойненько в основной программе обработали и сделали все необходимые вычисления.
Если дискретности в 1 мс будет мало, можно сделать системные тики по 0.1 мс, думаю, этого будет вполне достаточно.

Да, зависнет с последними значениями. Зависнет на десяток микросекунд, или даже меньше, пока обрабатывается прерывание. Я, например, не заметил бы задержку в 10 мкс...

Если серьезно, в правильно написанной программе прерывания отрабатывают настолько быстро, что человек заметить их эффекта на отзывчивость UI не в состоянии.

А какой вообще планируется приблизительный класс точности вычисления тепла? Ведь погрешность вычисления (это просто математика) будет зависеть от погрешности измерения расхода и от погрешности измерения температур. Причём, чем больше погрешность измерения температур, тем больше погрешность вычисления тепла при малой разнице между температурами. Ну и вертушка имеет большую погрешность на малых расходах с очень нелинейной характеристикой. Также желательно обеспечить достаточную длину прямого участка перед расходомером по потоку для минимизации разных турбулентностей. Исходя из фактического наличия больших погрешностей измеряемых величин нет смысла переживать о пропуске некоторых импульсов от расходомера.

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

Пропускать импульсы ни в коем случае нельзя. Закладывание в проект базовых ошибок - порочный подход.

Если ТС тема еще интересна, кое-какие замечания по реализации я бы указал.