Умный Дом по Ethernet
Re: Умный Дом по Ethernet
Создал проект в Proteus.
Работает. Сеть работает тоже - т.е. можно общаться с виртуальной мегой из браузера или сервера.
Если кому надо - обращайтесь.
Работает. Сеть работает тоже - т.е. можно общаться с виртуальной мегой из браузера или сервера.
Если кому надо - обращайтесь.
Re: Умный Дом по Ethernet
Да, очень удобно, я уже года три пользуюсь.DOCSIMUS писал(а):Создал проект в Proteus.
Работает. Сеть работает тоже - т.е. можно общаться с виртуальной мегой из браузера или сервера.
Если кому надо - обращайтесь.
Re: Умный Дом по Ethernet
Нужно, выложите пожалуйста.DOCSIMUS писал(а):Создал проект в Proteus.
Работает. Сеть работает тоже - т.е. можно общаться с виртуальной мегой из браузера или сервера.
Если кому надо - обращайтесь.
Re: Умный Дом по Ethernet
Проект делал для себя, возможны косяки, т.к. на скорую руку.
Proteus 7.10 SP0.
Файлы проекта должны быть размещены в папке с Си файлами, тогда будет возможность пошаговой отладки.
Путь к файлу elf задайте сами - клик мышкой на атмегу и редкатируйте в свойствах путь.
Также в свойствах enc28j60 необходимо прописать ip вашей сетевой карты. Желательно, чтобы у сетевой карты был статический IP, чтобы каждый раз не редактировать свойства энки. В архиве два скриншота.
Proteus 7.10 SP0.
Файлы проекта должны быть размещены в папке с Си файлами, тогда будет возможность пошаговой отладки.
Путь к файлу elf задайте сами - клик мышкой на атмегу и редкатируйте в свойствах путь.
Также в свойствах enc28j60 необходимо прописать ip вашей сетевой карты. Желательно, чтобы у сетевой карты был статический IP, чтобы каждый раз не редактировать свойства энки. В архиве два скриншота.
Re: Умный Дом по Ethernet
Обращаюсь к автору!
К сожалению информация на сайте и текущая прошивка не соответствуют друг другу в части описания.
Прошивка ушла далеко вперед, информация на сайте довольно устаревшая.
Поэтому, если вас не затруднит описать по состоянию на сегодняшний момент формат запросов сервера к меге и ответов меги на запросы, а также самостоятельные сообщения меги серверу, опишите пожалуйста.
Вот, что мне удалось "понять", читая ваш сайт, форум и анализируя прошивку (еще не до конца):
Запросы от сервера
http://192.168.0.14/sec/?pt=4&cmd=get - получение текущего состояния порта
ответ - ON (если порт находит в активном состоянии), OFF или текущее значение, если порт настроен в режим PWM (ШИМ) или ADC (АЦП). - актуально?
http://192.168.0.14/sec/?cmd=2:1 – изменение состояния порта SW
http://192.168.0.14/sec/?cmd=3:150 – изменение состояния порта PWM - актуально?
http://192.168.1.32/sec/?pt=12&pwm=10 – вроде бы то же, но что из этих двух вариантов на сегодня актуально?
cnt - ? - параметр для счетчика срабатывания порта, в каком формате запрос? что в ответ?
http://192.168.0.14/sec/?pn=14&m=0&misc=700 — изменение состояния ADC порта
почему где-то используется параметр pt, а где-то pn? хотя оба вроде про одно и то же
Сообщения от меги
http://192.168.0.250/megad.php?pt=6 – номер активированного порта
http://192.168.0.250/megad.php?pt=0&m=1 — при срабатывании на отжатие
http://192.168.0.250/megad.php?pt=14&v=940 — при срабатывании ADC порта (>,<)
http://192.168.0.250/megad.php?pt=14&v=940dir=1 — при изменении ADC порта (<>) - 1 – в сторону увеличения, 0 — в сторону уменьшения
http://192.168.0.250/megad.php?at=35 — при превышении температуры чипа выше Alarm Temp
К сожалению информация на сайте и текущая прошивка не соответствуют друг другу в части описания.
Прошивка ушла далеко вперед, информация на сайте довольно устаревшая.
Поэтому, если вас не затруднит описать по состоянию на сегодняшний момент формат запросов сервера к меге и ответов меги на запросы, а также самостоятельные сообщения меги серверу, опишите пожалуйста.
Вот, что мне удалось "понять", читая ваш сайт, форум и анализируя прошивку (еще не до конца):
Запросы от сервера
http://192.168.0.14/sec/?pt=4&cmd=get - получение текущего состояния порта
ответ - ON (если порт находит в активном состоянии), OFF или текущее значение, если порт настроен в режим PWM (ШИМ) или ADC (АЦП). - актуально?
http://192.168.0.14/sec/?cmd=2:1 – изменение состояния порта SW
http://192.168.0.14/sec/?cmd=3:150 – изменение состояния порта PWM - актуально?
http://192.168.1.32/sec/?pt=12&pwm=10 – вроде бы то же, но что из этих двух вариантов на сегодня актуально?
cnt - ? - параметр для счетчика срабатывания порта, в каком формате запрос? что в ответ?
http://192.168.0.14/sec/?pn=14&m=0&misc=700 — изменение состояния ADC порта
почему где-то используется параметр pt, а где-то pn? хотя оба вроде про одно и то же
Сообщения от меги
http://192.168.0.250/megad.php?pt=6 – номер активированного порта
http://192.168.0.250/megad.php?pt=0&m=1 — при срабатывании на отжатие
http://192.168.0.250/megad.php?pt=14&v=940 — при срабатывании ADC порта (>,<)
http://192.168.0.250/megad.php?pt=14&v=940dir=1 — при изменении ADC порта (<>) - 1 – в сторону увеличения, 0 — в сторону уменьшения
http://192.168.0.250/megad.php?at=35 — при превышении температуры чипа выше Alarm Temp
Re: Умный Дом по Ethernet
DOCSIMUS, вы абсолютно правы. Давно назрела необходимость описать API. Постараюсь в ближайшее время сделать.
Re: Умный Дом по Ethernet
Ну тогда выложу, то что для себя выписал.
Не описание API это конечно, но может быть будет полезно.
Не описание API это конечно, но может быть будет полезно.
- Вложения
-
- Запросы ответы.zip
- (64.38 КБ) 1003 скачивания
Re: Умный Дом по Ethernet
Андрей, у вас в прошивке в websrv_help_functions.c есть две функции:
find_key_val и find_key_val2
похоже, что find_key_val была слегка переделана по сравнению с оригинальной, а оригинальная была переименована в find_key_val2
судя по коду это совершенно идентичные функции
оригинальная возвращает 0 или 1
а вот переделанная возвращает длину value
вероятно было желание использовать это где-то, но оно не реализовалось
т.к. везде, где есть вызов этих функций, их возвращаемое значение используется в условиях, т.е. как это и было задумано в оригинале
но в некоторых местах вызывается функция find_key_val2, в большинстве же find_key_val
по хорошему надо использовать только одну - лучше оригинальную, хотя это все равно, но одну
вторую закомментировать, сэкономив на этом почти килобайт ROM
find_key_val и find_key_val2
похоже, что find_key_val была слегка переделана по сравнению с оригинальной, а оригинальная была переименована в find_key_val2
судя по коду это совершенно идентичные функции
оригинальная возвращает 0 или 1
а вот переделанная возвращает длину value
вероятно было желание использовать это где-то, но оно не реализовалось
т.к. везде, где есть вызов этих функций, их возвращаемое значение используется в условиях, т.е. как это и было задумано в оригинале
но в некоторых местах вызывается функция find_key_val2, в большинстве же find_key_val
по хорошему надо использовать только одну - лучше оригинальную, хотя это все равно, но одну
вторую закомментировать, сэкономив на этом почти килобайт ROM
Re: Умный Дом по Ethernet
Обращаю внимание, что в описании сказано, что формат поля Action - X:Y;X:Y;X:Y
Длина поля ввода ограничена 11 символами, соответственно в прошивке в EEPROM отводится по 11 байт на все порты.
Но что в случае, если номер порта больше 9? 10, 11, 12, 13... В этом случае три порта "не помещаются" в Action. Можно записать только 2.
И попутно вопрос - а в поле Action можно указывать PWM? Судя по прошивке - да. Но тогда то же самое. Либо два PWM, либо некое сочетание, может быть и три порта, если значение PWM будет односимвольным ну и т.д. К сожалению в EEPROM хранится массив символов строки Action, который при извлечении подвергается парсингу. Если бы в EEPROM хранился уже результат парсинга в бинарном виде (например, по 2 байта: первый - номер порта, второй - значение, неиспользованные "ячейки" - FF), то такой бы проблемы не существовало бы, а вместо 11 байт на порт в EEPROM достаточно было бы ограничиться 6ю байтами. Экономия составила бы 80 байт при 16 портах. Ну или бы можно было бы увеличить количество портов в Action до 5 (экономия 1 байт на порт) - на вкус. Но в этом случае придется немного переписать прошивку.
Не считаю это ошибкой или недоработкой, но просто необходимо указать на это ограничение. Ну или немного переписать Разделить port_execute - отдельно вынести парсинг и собственно выполнение. Парсинг, упаковка результата в массив из 6 байт, сохранение в EEPROM. При извлечении сразу выполнять, без парсинга. Поле Action в web-форме увеличить до 20 байт (3 порта PWM с 3х символьным значением - это максимум).
Длина поля ввода ограничена 11 символами, соответственно в прошивке в EEPROM отводится по 11 байт на все порты.
Но что в случае, если номер порта больше 9? 10, 11, 12, 13... В этом случае три порта "не помещаются" в Action. Можно записать только 2.
И попутно вопрос - а в поле Action можно указывать PWM? Судя по прошивке - да. Но тогда то же самое. Либо два PWM, либо некое сочетание, может быть и три порта, если значение PWM будет односимвольным ну и т.д. К сожалению в EEPROM хранится массив символов строки Action, который при извлечении подвергается парсингу. Если бы в EEPROM хранился уже результат парсинга в бинарном виде (например, по 2 байта: первый - номер порта, второй - значение, неиспользованные "ячейки" - FF), то такой бы проблемы не существовало бы, а вместо 11 байт на порт в EEPROM достаточно было бы ограничиться 6ю байтами. Экономия составила бы 80 байт при 16 портах. Ну или бы можно было бы увеличить количество портов в Action до 5 (экономия 1 байт на порт) - на вкус. Но в этом случае придется немного переписать прошивку.
Не считаю это ошибкой или недоработкой, но просто необходимо указать на это ограничение. Ну или немного переписать Разделить port_execute - отдельно вынести парсинг и собственно выполнение. Парсинг, упаковка результата в массив из 6 байт, сохранение в EEPROM. При извлечении сразу выполнять, без парсинга. Поле Action в web-форме увеличить до 20 байт (3 порта PWM с 3х символьным значением - это максимум).
Re: Умный Дом по Ethernet
Еще хочу обратить внимание. В коде встречаются строки:
memset(bits, 0, sizeof(bits));
memset(temp, 0, sizeof(temp));
Насколько я понимаю было желание заполнить массив нулями? Если так, то некорректно использовать sizeof - она выдаст размер переменной bits в первом случае (1, если не ошибаюсь) и размер указателя temp во втором (2, если не ошибаюсь), но никак не размер массива. В результате будет заполнено нулями первый байт в первом случае и 2 первых байта во втором. Вероятно это не критично для кода, но все таки...
можно так
#define temp_size 36
char temp[temp_size]
memset(temp, 0, temp_size);
ну или явно указывать без дефайна
memset(temp, 0, 36);
memset(bits, 0, sizeof(bits));
memset(temp, 0, sizeof(temp));
Насколько я понимаю было желание заполнить массив нулями? Если так, то некорректно использовать sizeof - она выдаст размер переменной bits в первом случае (1, если не ошибаюсь) и размер указателя temp во втором (2, если не ошибаюсь), но никак не размер массива. В результате будет заполнено нулями первый байт в первом случае и 2 первых байта во втором. Вероятно это не критично для кода, но все таки...
можно так
#define temp_size 36
char temp[temp_size]
memset(temp, 0, temp_size);
ну или явно указывать без дефайна
memset(temp, 0, 36);
Re: Умный Дом по Ethernet
Попытался осуществить вышесказанное.
Чуть чуть возрос размер кода, на 10 байт возросло использование RAM, но использование EEPROM уменьшилось значительно. Кроме всего прочего теперь можно реально вписать три порта (любых PWM, SW) в поле Action - всего 20 байт вместо 11, при сохранении в EEPROM 6 байт.
Файлы прилагаю - проверял достаточно быстро, вроде все работает корректно, но углубленно не тестировал.
Чуть чуть возрос размер кода, на 10 байт возросло использование RAM, но использование EEPROM уменьшилось значительно. Кроме всего прочего теперь можно реально вписать три порта (любых PWM, SW) в поле Action - всего 20 байт вместо 11, при сохранении в EEPROM 6 байт.
Файлы прилагаю - проверял достаточно быстро, вроде все работает корректно, но углубленно не тестировал.
Re: Умный Дом по Ethernet
Теперь можно оптимизировать использование EEPROM при сохранении NetAction - это чуть позже.
Но пока разбирался что и почем нашел еще пару ошибок, одна из которых довольно грубая.
1)
Под поле NetAction отводится 35 байт, которые и сохраняются в EEPROM (которые я и оптимизирую).
Однако не пытайтесь сохранить такую длинную строку - не получится, не получится и более короткую.
Дело в том, что при передаче данных строка
например 192.168.0.2/secpw/?cmd=6:128 - 28 байт будет заменена на 192.168.0.2%2Fsecpw%2F%3Fcmd%3D6%3A128 - 38 байт
далее в коде
считает только первые 36 байт в буфер temp, обрезав 3 последних байта (+0 в конец temp)
в результате в EEPROM запишется 192.168.0.2/secpw/?cmd=6:
необходимо увеличить буфер temp - ну например до 60 байт (можно и до 50 наверное) и
тогда все корректно сохраняется
2) грубая ошибка
длина считываемого из EEPROM NetAction - 35 байт
некоторое количество байт 13-15 - это IP адрес, который при парсинге сохраняется в _eth_addr
оставшиеся 22-20 байт (если строка в EEPROM максимальной длины - 35 байт) сохраняются при парсинге в urlpar, размер которого всего 10 байт... с выходом за границу массива с непредсказуемыми последствиями
необходимо увеличить размер массива urlpar до 25 байт при данной реализации
Но пока разбирался что и почем нашел еще пару ошибок, одна из которых довольно грубая.
1)
Под поле NetAction отводится 35 байт, которые и сохраняются в EEPROM (которые я и оптимизирую).
Однако не пытайтесь сохранить такую длинную строку - не получится, не получится и более короткую.
Дело в том, что при передаче данных строка
например 192.168.0.2/secpw/?cmd=6:128 - 28 байт будет заменена на 192.168.0.2%2Fsecpw%2F%3Fcmd%3D6%3A128 - 38 байт
далее в коде
Код: Выделить всё
if (find_key_val2((char *)&(buf[dat_p+4]),temp,36,"eth"))
{
//if ( strlen(temp) > 0 )
{
urldecode(temp);
eeprom_write_block (&temp, &ee_eth_cmd[atoi(gStrbuf)], 35);
reset_flag = 1;
}
}
в результате в EEPROM запишется 192.168.0.2/secpw/?cmd=6:
необходимо увеличить буфер temp - ну например до 60 байт (можно и до 50 наверное) и
Код: Выделить всё
if (find_key_val2((char *)&(buf[dat_p+4]),temp,60,"eth"))
2) грубая ошибка
Код: Выделить всё
if ( send_eth_flag2 > -1 )
{
if ( (tcp_client_state > 0 || tcp_client_state < 6) )
{
// to process the ARP reply we must call the packetloop
plen=enc28j60PacketReceive(BUFFER_SIZE, buf);
packetloop_arp_icmp_tcp(buf,plen);
//arp_timeout--;
eeprom_read_block (temp, &ee_eth_cmd[send_eth_flag], 35);
if ( temp[0] != (char)255 && strlen(temp) > 0 )
{
char ip_b[3];
char urlpar[10];
uint8_t ip_flag = 0;
uint8_t ip_cnt = 0;
//uint8_t url_cnt = 0;
for ( k = 0; k < strlen(temp); k++ )
{
if ( ip_flag < 4 )
{
if ( temp[k] == '.' || temp[k] == '/' )
{
ip_cnt = 0;
_eth_addr[ip_flag] = atoi(ip_b);
ip_flag++;
ip_b[0] = '\0';
ip_b[1] = '\0';
ip_b[2] = '\0';
}
else
{
ip_b[ip_cnt] = temp[k];
ip_cnt++;
}
}
else
{
urlpar[url_cnt] = temp[k];
url_cnt++;
}
}
некоторое количество байт 13-15 - это IP адрес, который при парсинге сохраняется в _eth_addr
оставшиеся 22-20 байт (если строка в EEPROM максимальной длины - 35 байт) сохраняются при парсинге в urlpar, размер которого всего 10 байт... с выходом за границу массива с непредсказуемыми последствиями
необходимо увеличить размер массива urlpar до 25 байт при данной реализации
Re: Умный Дом по Ethernet
Произвел оптимизацию EEPROM в части NetAction. Теперь вместо 35 байт в EEPROM сохраняется 25 байт, размер поля ввода остался прежним - 35 байт. Оптимизация за счет изменения формата хранения данных. В оригинале в EEPROM хранилась символьная строка 35 байт. В предложенном варианте - IP адрес хранится в бинарном виде в первых 4х байтах, под остальное отводится 21 байт в виде символьной строки. Размер использованной EEPROM после всех оптимизаций снизился с 84% до 59%. Проверял - работает корректно, но нуждается в более углубленном тестировании.
Если автора заинтересует, пусть решит применять или не применять данные предложения. Хотя такое ощущение, что форум мертвый...
Если автора заинтересует, пусть решит применять или не применять данные предложения. Хотя такое ощущение, что форум мертвый...
Re: Умный Дом по Ethernet
нет мы Вас внимательно слушаем продолжайте пожалуйста.Хотя такое ощущение, что форум мертвый...
Re: Умный Дом по Ethernet
Посмотрите количество скачиваний Вашего кода и это ощущение пройдет.DOCSIMUS писал(а):Хотя такое ощущение, что форум мертвый...
Re: Умный Дом по Ethernet
+1alexsis_76 писал(а):нет мы Вас внимательно слушаем продолжайте пожалуйста.Хотя такое ощущение, что форум мертвый...
тут много, очень много не особо профи, но которым тема сильно интересна.
просто, если, к примеру, взять меня, то в данную дискуссию я полноценно не влезу, поскольку мои знания на уровне любителя.
я по теме понимаю, о чём речь, ценю Ваш труд, особо ценю труд создателя этого ресурса, но... повторюсь, пишу редко именно из-за недостаточной компетентности.
а форум жив настолько, насколько возможен интерес такой узкой направленности. и в рунете он лучший, imho
Re: Умный Дом по Ethernet
Слава создателю, есть живые
Ну код то я видел, что скачивали, но поскольку никто совсем не комментирует - плохо/хорошо/никуда не годится - закралось ощущение отсутствие интереса. Но вы мои нехорошие ощущения развеяли. Еще раз повторюсь - никакой я не профи, просто любитель. В железе пока не воплощал данное устройство, хотел предварительно посмотреть в виртуале так сказать, понять логику работы и применимость для своих задач. Но уже вот вот воплощу. Пока дополнительно для себя добавил два порта - B0, B7. Но код выкладывать не буду, т.к. это расходится с концепцией автора. B0 - за счет купирования светодиода. Сразу оговорюсь - все читал в этой ветке... и про "моддинг" и прочее, но с моей точки зрения использовать порт для очень редкого подмигивания светодиодом... но это мое личное мнение. B7 - при условии тактирования от энки. В связи с этим вопрос - в ревизии 4-5 используется именно такой вариант? Тактирование от энки? Или отдельный кварц на атмегу? В смысле надежности.
И еще пара вопросов по железу (в электронике я совсем слаб). В Proteus'е я подтянул входы и выходы резисторами на +. Как оно на самом деле у вас? При подтяжке на + при NC состоянии на портах логическая 1. Это нормально? Другими словами при изначально пустом EEPROM - все порты в NC и соответственно все предполагаемые выходы (светодиоды в Proteus) включены. Меня волнует что при этом будет? Все выходы "включены" при первом включении... Прошу прощения, если задаю глупые вопросы, в связи со слабым знанием "железной" составляющей.
Ну код то я видел, что скачивали, но поскольку никто совсем не комментирует - плохо/хорошо/никуда не годится - закралось ощущение отсутствие интереса. Но вы мои нехорошие ощущения развеяли. Еще раз повторюсь - никакой я не профи, просто любитель. В железе пока не воплощал данное устройство, хотел предварительно посмотреть в виртуале так сказать, понять логику работы и применимость для своих задач. Но уже вот вот воплощу. Пока дополнительно для себя добавил два порта - B0, B7. Но код выкладывать не буду, т.к. это расходится с концепцией автора. B0 - за счет купирования светодиода. Сразу оговорюсь - все читал в этой ветке... и про "моддинг" и прочее, но с моей точки зрения использовать порт для очень редкого подмигивания светодиодом... но это мое личное мнение. B7 - при условии тактирования от энки. В связи с этим вопрос - в ревизии 4-5 используется именно такой вариант? Тактирование от энки? Или отдельный кварц на атмегу? В смысле надежности.
И еще пара вопросов по железу (в электронике я совсем слаб). В Proteus'е я подтянул входы и выходы резисторами на +. Как оно на самом деле у вас? При подтяжке на + при NC состоянии на портах логическая 1. Это нормально? Другими словами при изначально пустом EEPROM - все порты в NC и соответственно все предполагаемые выходы (светодиоды в Proteus) включены. Меня волнует что при этом будет? Все выходы "включены" при первом включении... Прошу прощения, если задаю глупые вопросы, в связи со слабым знанием "железной" составляющей.
Re: Умный Дом по Ethernet
беру свои слова обратно, sizeof указывает длину массива, если объявлен именно массивDOCSIMUS писал(а):Еще хочу обратить внимание. В коде встречаются строки:
memset(bits, 0, sizeof(bits));
memset(temp, 0, sizeof(temp));
...
Re: Умный Дом по Ethernet
так же как и у вас , это нормально , резистор на so , что бы не пожечь вывод encВ Proteus'е я подтянул входы и выходы резисторами на +. Как оно на самом деле у вас? При подтяжке на + при NC состоянии на портах логическая 1. Это нормально?
ничегоМеня волнует что при этом будет
в протеусе не делал , сразу в железе, вообще сделано все довольно примитивно(я имею ввиду подобие стека), из за багов в enc не задействованы некоторые возможности последней,делал несколько вариантов устройства.
бываетберу свои слова обратно, sizeof указывает длину массива, если объявлен именно массив
кстати после последних правок код перестал компилится для mega32 , ругается на отсутствие спользуемых аппаратных ресурсов
p.s возможно не в тему но есть(будет)SIM900 у кого нибудь есть опыт использования подобных железок
Re: Умный Дом по Ethernet
просто я использовал в своих функциях передачу массива в качестве параметра через указатели и sizeof естественно не давала размер массива, а показывала размер указателя - меня это смутило и сбило с правильного пути... потом вернулся на путь истинныйalexsis_76 писал(а):бываетберу свои слова обратно, sizeof указывает длину массива, если объявлен именно массив
Вообще сразу? Т.е. после того как я выложил самые первый вариант правки?alexsis_76 писал(а): кстати после последних правок код перестал компилится для mega32 , ругается на отсутствие спользуемых аппаратных ресурсов
Странно... Я конечно не проверял под mega32 - могу сегодня проверить, но по идее не должно быть... Я то вообще к аппаратным ресурсам не притрагивался. Посмотрю. Использую среду Atmel Studio 6.1, но там тот же AVR-GCC компилятор. Просто привык под ним работать и отладчик у него есть удобный.
Заодно вопрос. Не понял по логике работы - объясните, если не сложно.
Из описания и прошивки, если случился таймаут (не отвечает сервер), то мега отработает Action и в любом случае NetAction. Если имею несколько мег. Хочу например так - вход на меге 1, выход на меге 2. Сработал вход на меге 1 - сервер получил, обработал и отослал команду на исполнение меге 2. В Action на меге 1 будет пусто, а в NetAction для повышения надежности прописываю отработку выхода на меге 2. Насколько понимаю, что при работающем сервере произойдет дублирование? Если при этом захочу Toogle выхода? Сервер отошлет меге 2 например 10:2 - она переключит выход, а мега 1 тоже отошлет меге 2 10:2 и она его снова переключит - т.е. в изначальное состояние. Так? Если так, то не совсем хорошо...