Учет электроэнергии и расхода воды
|
|
AlexAW | Дата: Понедельник, 12.02.2018, 15:42 | Сообщение # 41 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| pop, Вставлю свои пять копеек. Я не силен в высоком программировании. Но думаю "отслеживать системное событие", и есть работать с прерыванием вызванным тем или иным системным событием. Это может быть обнаружение изменение порта или отсчета таймера или что то там еще. И уже его обработка кодом своей программы.
Не знаю доступны ли прерывания от GPIO в Питоне, но если вы не знаете есть они там или нет поищите стандартное прерывание от системного таймера " системного тика" и запускайте свой код по прерыванию от этого таймера. А далее например как Zoolu предлагал с флагами отслеживать фронты . В итоге ваша задача будет запускаться достаточно часто, что бы вполне успеть отследить работу мигающего светодиода, и не будет висеть на обработке только этой задачи и сможет выполнять другой основной код.
Сообщение отредактировал AlexAW - Понедельник, 12.02.2018, 15:47 |
|
| |
pop | Дата: Вторник, 13.02.2018, 12:22 | Сообщение # 42 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Цитата AlexAW ( ) Но думаю "отслеживать системное событие", и есть работать с прерыванием вызванным тем или иным системным событием. Это может быть обнаружение изменение порта или отсчета таймера или что то там еще. И уже его обработка кодом своей программы. Ну да. Так оно и есть. Просто, есть аппаратные прерывания, и есть програмные. Сам процессор умеет использовать пины как источники аппаратного прерывания. Т.е., при изменении состояния входа, "бросать всё и надувать шарики" - т.е., жёстко передавать управление подпрограмме по фиксированному адресу, и возвращаться к тому месту, где его "прервали" по выходу из этой подпрограммы. ОС (драйвер), по идее, тоже должна уметь делать подобное, но там всё сложнее. Если проц не настроен на аппаратные прерывания по входу, то ОС тоже может как-то периодически отслеживать состояние входа, и при его изменении генерировать "системное событие", и выполнять определённую программу. Всё почти как в коде Zoolu. Это как бы общий принцип. Вопрос только в том, есть ли это уже в системе, или нет. Ведь, если есть, то можно использовать уже всёравно исполняемый по какому-то таймеру "вечный цикл", только перехватывая уже готовые "события".Добавлено (13.02.2018, 12:22) ---------------------------------------------
Код #! /bin/bash #Включаем нужный порт GPIO gpio -g mode 17 input #Подтягиваем внутренней подтяжкой на + (вариант down (подтяжка к 0), tri (без подтяжки)) gpio -g mode 17 up #Запускаем бесконечный цикл while ( true ) do #так как импульсов много (3200имп= 1КВт*час), то будем отправлять в БД по 100Вт*час, для этого задаем переменную i i=0 #будем считать количество импульсов по порту добавляя к переменной единичку, пока не насчитаем 320 while [ $i -lt 320 ] do #Следующая команда ожидает когда значение пина сбросится (falling), установится (rising), или и одно из двух (both) gpio -g wfi 17 falling #Защита от дребезга sleep .1 if [ $(gpio -g read 17) = 0 ] then i=$[$i+1] #Пишем при отладке echo $i fi done #Отправляем информацию в MySQL #sudo /script/gpio/mysql-add.sh done man gpio
|
|
| |
AlexAW | Дата: Вторник, 13.02.2018, 16:14 | Сообщение # 43 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| pop, Вот тут случайно набрел на интересную статью проливающую свет на тему вами поднятую, а заодно укрепляющую мою уверенность в том что на малинке нужно делать систему централизации распределенной "интеллектуальной периферии", а не занимать ее прямым управлением.... ИМХО конечно.
Сообщение отредактировал AlexAW - Вторник, 13.02.2018, 16:44 |
|
| |
pop | Дата: Вторник, 13.02.2018, 16:30 | Сообщение # 44 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| А ссылочку на статью можно? Впринципе, я с Вами согласен по поводу распределённой системы. Тоже считаю, что малинку нужно использовать как "выход в большой мир", и для удалённой настройки локальных "умных" модулей. Но что-то не слишком критичное, или чисто "для общей информации" можно и малинке поручить.
|
|
| |
AlexAW | Дата: Вторник, 13.02.2018, 16:47 | Сообщение # 45 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| Поправил пост. пока восстанавливал ссылку в поиске нашел много инфы по запросу "системные прерывания gpio в raspberry" Вот например
Сообщение отредактировал AlexAW - Вторник, 13.02.2018, 16:48 |
|
| |
pop | Дата: Вторник, 13.02.2018, 17:06 | Сообщение # 46 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| Цитата AlexAW ( ) Вот например Угу. Я тоже уже находил варианты реализации и на питоне, и на с.
|
|
| |
bagotu | Дата: Четверг, 15.02.2018, 22:27 | Сообщение # 47 |
Группа: Пользователи
Сообщений: 42
Статус: Offline
| А можно будет через данный прибор считывать показания?
|
|
| |
AlexAW | Дата: Пятница, 16.02.2018, 06:37 | Сообщение # 48 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| Цитата А можно будет через данный прибор считывать показания? Можно только читал чей то рассказ о том что при заказе продавцу нужно указать что бы был с RS485 Modbus
|
|
| |
Admin | Дата: Пятница, 16.02.2018, 17:59 | Сообщение # 49 |
Admin
Группа: Администраторы
Сообщений: 4260
Статус: Offline
| bagotu, поинтересуйтесь сначала у продавца протоколом обмена. Ибо китайцы большие любители проприетарных протоколов и уже откровенно задолбали своими извращениями с Modbus.
Недавно разбирался с одним китайским контроллером. По описанию - Modbus RTU. По факту - протокол "похожий на Modbus" - сначала (перед адресом слейва) передается "магическая константа" 55h, а CRC урезано до одного байта вместо двух. Причем, вычисляется этот байт CRC очень "оригинальным" способом - суммой всех предыдущих байт.
|
|
| |
AlexAW | Дата: Суббота, 17.02.2018, 16:05 | Сообщение # 50 |
Группа: Пользователи
Сообщений: 310
Статус: Offline
| У этого счетчика с протоколом вроде все нормально, просто выпускают его в двух исполнениях, только с импульсным выходом и с импульсным и RS485 Так вот продавец по умолчанию отправляет с импульсным, потому рекомендуют уточнять продавцу что нужен выход RS485. Хотя говорят выход там есть всегда! Просто разъем не впаян.
|
|
| |