Прошивка MegaD-328 (релизы, обсуждения, предложения)

[kod.begemot]

Добрый день!
Вопрос уже поднимался когда-то, ещё в ветке "Умный дом по Ethernet", но тогда тема развития не получила. Вот реанимирую: Можно ли к МегаД прикрутить функцию WatchDog? В том смысле что при пропадании пинга на определенный (в настройках) адрес Мега дёргает заданным выходом на заданное время. Или это займёт много из и так ограниченного объёма памяти?

[Andrey_B]

В сеть утекли первые шпионские снимки платы нового исполнительного модуля MegaD-7I7O-SD.
Это первая плата проекте MegaD-328, где применяются в том числе отечественные микросхемы.

megad-7I7O-SD.JPG (106.31 КБ) 6866 просмотров

[Andrey_B]

kod.begemot, памяти, конечно маловато. Наверное, что-то можно придумать для реализации этой функции, где-то что-то соптимизировать. Но я не уверен, что она действительно будет востребована... А память - ресурс ценный.

[kod.begemot]

Насчет востребованности я тоже не уверен. Просто сейчас столкнулся - вставляю мегу с мосфетным блоком в свитч - для управления питанием на портах, развитие идеи самодельного PoE. Думаю пинговать сервером, и с сервера же давать команду на "дрыг ногой" для перезапуска по питанию того или иного девайса, ежели он вдруг не пингуется длительное время. Вот и подумал - а может Мега сама это сможет делать? Или сама мега сможет перезапустить сервер?
И вот, кстати, ещё идея. А почему бы не сделать для одного и того-же главного блока меги разные версии прошивок?
Ну к примеру -
1. Прошивка стандартная, порты конфигурируются, всё как сейчас.
2. Прошивка с вырезанными функциями Action / Net Action, по портам, но с поддержкой 1-wire (пускай только термометров) и некий Action на них (2-3 порта по 1-2 термометра).
Понимаю, что есть ветка с альтернативными прошивками, понимаю что про 1-wire уже наговорено более чем достаточно... Но на мой взгляд сейчас Мегадевайсу не хватает только 1-wire, причем именно термометров, для реализации простейших термостатов и сбора данных. Точность термоданных от DHT не высока.
И ещё на последок.. Раз разрабатыаете новые версии, может к базовому модулю прикрутить что-то вроде PoE? Я в своих уже это давно сделал, очень удобно Кинул 24 вольта, 3 мегагерцовый преобразователь от китайцев (50 руб в розницу)...
Просто мысли вслух
И ещё раз большое спасибо Андрею за превосходный проект, на мой взгляд МегаД - лучшее решение для Умного дома! Концепция превосходна!
P.S. на "Шпионских фото" диммирующий модуль?

[vtec]

Да, на коце буква D как бы об этом намекает

[Andrey_B]

megad-ds18b20.jpg (15.96 КБ) 6749 просмотров

DS18B20 можно подключить к портам C0-C5 (P0-P5).
Один на порт. Не шиной. На более сложную реализацию пока нет ресурсов.
Обязателен резистор подтяжки к питанию 4,7К. Конвертация 750 мс пока задержкой (блокируется работа остальных функций). Позже этот вопрос можно решить.

Прошивка сильно экспериментальная. На сайт не выкладывал. В рабочем режиме не использовать! Только для отладочных целей.
http://ab-log.ru/files/File/ip_manager3 ... a1-hex.zip

Да, со стандартным исполнительным модулем MegaD-7I7O на входах работать естественно не будет (как и DHT11/DHT22). Там аппаратная обвязка чисто для кнопок или чего-то аналогичного.

[kod.begemot]

Огромное спасибо! Завтра же попробую. Отпишусь.

[Andrey_B]

Мысли вслух относительно 750 мс.

Конвертация температуры занимает время. Просто ждать 750 мс бессмысленно. За это время Едешко и Белов могли запросто похоронить надежды американцев на золото олимпиады.
Можно запрашивать температуру не в 12, а в 9-битном разрешении. Это быстрее в 8 раз, но фактически (учитывая текущую реализацию, упорно избегающую float из-за экономии) мы теряем десятые градуса, но зато освобождаем чуть памяти. Но даже в этом случае 95 мс - это много. За это время можно успеть нажать кнопку на выключателе и получить в ответ... да ничего не получить.
Выхода видится два. И оба не идеальные.
Оставить 12-бит, но:
1) Отдавать при запросе температуру из предыдущего измерения, запуская при этом новую конвертацию. Собственно, так работают, никого не стесняясь, датчики DHT11/DHT22. То есть, если мы хотим получить "свежую" температуру, мы делаем не один, а два запроса с разницей в секунду. Разумеется, если мы опрашиваем датчик в цикле, скажем, раз в минуту, то делать два запроса смысла не имеет, достаточно одного. Отставание в минуту погоду не сделает.
2) Запускать, скажем, раз в минуту по таймеру процесс конвертации. Общение с датчиком тоже построено на задержках, но совсем небольших, микросекундных. На это время запрещаются прерывания, так как границы кадра очень небольшие. Вряд ли это как-то существенно повлияет на работу устройства. Тогда, при опросе датчика мы не запускаем конвертацию, а просто считываем из памяти текущее значение. Отставание от реальности в зависимости от того, в какой момент времени мы попадем, от 0 до минуты (или как часто будет делаться такой опрос).

[507]

То же мысли и то же в слух.
Может тогда имеет смысл использовать драйвер 1Wire 2480 или 2482?
Тогда для считывания нужно всего 20 мс
Ну да это минус две ноги МК и никакого паразитного питания на линии 1W, но плюс - это полноценная 1W. А две ноги можно компенсировать восемью ногами DS2408.

[alexsis_76]

а может сделать так и все вопросы отпадут

Код: Выделить всё

// 1 ware раз в 1 секунды
		if(task_1_ware==NULL&&convert_busy==NULL)
		{
		convert_busy=start_convert();// начинаем конвертирование
		task_1_ware=1;
		}
		if(task_1_ware==NULL&&convert_busy!=NULL)
		{
		ware_result=read_temperature(buf_ware_ds1820,&buf_teperature);// можно читать температуру
		if (ware_result!=1){
		//client_send(temp_error);// сообщаем об ошибке
		LED_GREEN_OFF;// говрим об ошибке 1ware
		}else{
	    LED_GREEN_ON;// ВСЕ НОРМАЛЬНО
		}
		convert_busy=0;// флаг в 0 (можно заказать следующий цикл
		convert_char(buf_teperature); // конвертируем температуру
		//read_adc();
		task_1_ware=1;
		}

измеряем температуру раз в 1 сек(можно поменять) если конвертирование не производится то можно запускать измерение

Код: Выделить всё

convert_busy=start_convert();// начинаем конвертирование
		task_1_ware=1;

во второй строке заводим счетчик на 1 сек

Код: Выделить всё

convert_busy

указывает на то что было запущено конвертирование и в следующем такте(через 1 сек) мы будем читать значение температуры

Код: Выделить всё

if(task_1_ware==NULL&&convert_busy!=NULL)
		{
		ware_result=read_temperature(buf_ware_ds1820,&buf_teperature);// можно читать температуру

если прошла 1 сек и convert_busy!=0; читаем температуру
затем

Код: Выделить всё

if (ware_result!=1){
		//client_send(temp_error);// сообщаем об ошибке
		LED_GREEN_OFF;// говрим об ошибке 1ware
		}else{
	    LED_GREEN_ON;// ВСЕ НОРМАЛЬНО
		}
		convert_busy=0;// флаг в 0 (можно заказать следующий цикл
		convert_char(buf_teperature); // конвертируем температуру
		//read_adc();
		task_1_ware=1;
		}

и все снова(всем будет фиолетово какое разрешение у датчика,пнули и пошли делать свои дела, через секунду прочитали температуру)
507 у вас еще проще, в вашем коде уже есть готовые неблокируемые временные задежки(вплоть до нескольких дней)
если хотите могу дать весь код

[507]

Код конечно хочу.
Только не понял про то что он мой? и если он мой, то почему у он у Вас есть, а у меня нет? (LOL)

[Andrey_B]

507, и как драйвер DS2480B решит описанную выше проблему? Конвертированием температуры занимается сам датчик. И на время в 750мс драйвер никак повлиять не может. А команды раздавать МК в состоянии и сам - это не трудно.
alexsis_76, если я правильно вас понял, вы предлагаете то же, что я описал в пункте 2. То есть отправлять в цикле команду на конвертацию. Только вы предлагаете делать это часто. Долбить датчик раз в секунду? Не знаю. И, кстати, в этом случае я не уверен в отсутствии "self heating problem".

[507]

Повлиять нет, а вот освободить МК от ожидания, да.
Нет никакой необходимости МК ожидать эти 750 мс.
В первом цикле запрос, во втором считывание но не раньше чем 750 мс.

[Andrey_B]

alexsis_76, да никто не мешает, поэтому я предложил к обсуждению этот вариант. Возможно, целесообразно реализовать комбинированный подход, когда циклический опрос является настраиваемой через Web-интерфейс опцией, подобно тому как это работает сейчас с АЦП портами.
Но, может быть, есть какой-то еще 3-ий или 4-ий вариант?

[Andrey_B]

507, проблема даже не в ожидании МК, а в ожидании, скажем так, "пользователя".
Когда мы запрашиваем сейчас состояние того или иного порта через HTTP, мы получаем значения относительно сразу.
Но в случае с DS18B20 этого "сразу" не выйдет. И тут уже не важно как именно это реализовано. МК может отправить команду на конвертацию, вернуться к выполнению своих привычных дел, а через 750 мс, считать значение из памяти датчика, но что в это время будет делать "пользователь", учитывая, что мы имеем дело с однопакетным, однозадачно-однопоточным TCP-процессом? А если в это время придет другой запрос или будет сгенерировано два десятка новых событий? Да просто пользователь ничего не получит. И тут неважно кто именно "выдерживал" эту паузу, МК или драйвер. То есть отдавать пользователю нужно либо уже заранее подготовленные данные, либо разбивать сие чудное действие на два акта.

[Dron]

Мои размышлизмы-вопросы:
Скажите, Андрей, а почему именно 5 ног, а не все? память?
зачем выдавать пользователю моментальные данные? думаю, редко кто использует 1-wire градусники в местах, где скорость обновления данных реально критична. не та система.
почему бы не реализовать 1-2-3 полноценных шины 1-wire, точнее часть про термометры? и опрашивать их раз минуту. а по запросу выдавать последние данные.
повторюсь, за минуту температура в комнате вряд ли сильно изменится.
а если градусник используется в месте типа котла отопления, то "простите, не рекомендуем"...

[Dron]

кстати! как вариант... с сервера пришёл запрос на температуру. мега обработала запрос и ничего не ответила. а спустя секунду уже сама отправила запрос на сервер с готовой температурой.
имхо, вообще идеальный вариант

[alexsis_76]

Код: Выделить всё

Но, может быть, есть какой-то еще 3-ий или 4-ий вариант?

как я уже писАл есть такой замечательный компилятор CVavr, его мастер позволяет создать 1 ware мастера на 8(насколько помню)устройств, так вот указываете ему(мастеру) куда подключен термометр и что хотите использывать много устройств , жамкаете клавишу и без лишних вопросов получактк рабочюю программу причем вы можете даже не знать как работает шина, но есть одно но указанный компилятор категорически не сочетается с тем что используете вы, вам придется воздать отдельное устройство и соединить его по шине (uart,i2c,spi)c основным устройством,но зато вы получите возможность мерить температуру асинхронно, вас ничего не будет стеснять

имхо, вообще идеальный вариант

с подобным устройством вариант не плохой

[alexsis_76]

да никто не мешает, поэтому я предложил к обсуждению этот вариант

да только учитывая размер оставшихся ресурсов ,количество возможных вариантов стремится к 0

[Andrey_B]

http://ab-log.ru/files/File/ip_manager3 ... a2-hex.zip

Датчики DS18B20 можно подключить к любому порту (но по 1 шт на порт).
В данной версии считывается существующее в памяти датчика показание и запускается следующий процесс конвертации. Для получения текущего значения температуры можно сделать запрос 2 раза с разницей в секунду. Но значение отображается мгновенно. Паузы нет. Функционирование устройства не нарушается. В этом режиме опрос датчика работает также как DHT11/22.

Если сделать несколько запросов в течение секунды, то датчик может вернуть некорректное значение. Тогда устройство вместо температуры отобразит "---".