| |
 atmega32u4+ENC28J60+uIP = HTTPD+CGI+DHCP+DFU bootloader, Собственно реальзация web сервера для atmega32u4 и enc28J60 |
|
|
|
|
 Jul 1 2009, 20:29
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Собственно проект: http://code.google.com/p/uhttpd-avr/ компилиурется WinAvr, прошивку можно обновлять с помощью FLIP'a через USB. Параметры сети хрянятся в EEPROM'e, можно менять через web, есть поддержка DHCP. Всё реализовано на основе uIP модифицированного для хранения данных в program memory. P.S. Работает медленно
|
|
|
|
|
|
2 страниц 
1 2 >
|
 |
Ответов
(1 - 14)
|
|
Jul 6 2009, 03:36
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Неужто никому не нужно?
|
|
|
|
|
|
|
|
Jul 6 2009, 05:18
|
Местный
Группа: Свой
Сообщений: 283
Регистрация: 13-06-07
Из: Челябинск
Пользователь №: 28 391
|
Вот этим отпугнул  Цитата(Ilmarin @ Jul 2 2009, 02:29)  P.S. Работает медленно Мне лично интересно, но я пока мельком глянул. PS. Не нашел кнопки в репозитории чтобы сразу архивом все файлы качнуть.
|
|
|
|
|
|
|
|
Jul 8 2009, 05:33
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Цитата(Rst7 @ Jul 6 2009, 02:01) Дык надо uIP хачить на предмет Delayed ACK. Будет лучше Приделал uip_split ( http://www.sics.se/~adam/uip/uip-1.0-refman/a00154.html ) заметно лучше не стало. Скорее всего из-за того что этот хак отсылает по-частям только пакеты максимальной длинны. Что интересно, если сравнивать скорость загрузки страннички с динамически сгенерированной формой на винде ХП и линиксе (Ubuntu) то на линуксе существенно быстрее (и там и там Firefox 3.0.11 , без прокси ). http://uhttpd-avr.googlecode.com/files/uht...-2009-07-08.zip
|
|
|
|
|
|
|
|
Jul 8 2009, 05:57
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Приделал uip_split заметно лучше не стало. Скорее всего из-за того что этот хак отсылает по-частям только пакеты максимальной длинны. Дык захачте его, чтобы любые пакеты пилил. Либо есть другой вариант (я так делал, пока не реализовал полноценную поддержку Delayed ACK у себя в стеке) - после каждого пакета с данными посылать пакет без данных с тем же SEQ - на такое что винда, что линух мгновенно отвечает ACK'ом. Цитата Что интересно, если сравнивать скорость загрузки страннички с динамически сгенерированной формой на винде ХП и линиксе (Ubuntu) то на линуксе существенно быстрее (и там и там Firefox 3.0.11 , без прокси ). Дело в том, что авторы стека TCP/IP в линухе видимо писатели, а не читатели (рекомендаций в RFC), посему линух отвечает ACK'ом на каждый пакет.
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 8 2009, 15:03
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Цитата(Rst7 @ Jul 8 2009, 01:57) Дык захачте его, чтобы любые пакеты пилил. Пробовал ( поменял условие при котором распил происходит ) - что-то нестабильно работать стало.
|
|
|
|
|
|
|
|
Jul 9 2009, 03:07
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Цитата(Rst7 @ Jul 8 2009, 11:55) В чем нестабильность выражена? Связь стала случайным образом подвисать. Цитата(Rst7 @ Jul 8 2009, 01:57) Дело в том, что авторы стека TCP/IP в линухе видимо писатели, а не читатели (рекомендаций в RFC), посему линух отвечает ACK'ом на каждый пакет. Нашёл в интернете что в виндах таймер на ACK - 200мс, а в Линуксе - 10мс. Кстати, в виндах можно настраивать количество пакетов : http://support.microsoft.com/kb/328890 , если поставить 1 то всё работает довольно быстро.
|
|
|
|
|
|
|
|
Jul 9 2009, 05:28
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Связь стала случайным образом подвисать. Хз, хз.. Цитата Кстати, в виндах можно настраивать количество пакетов : http://support.microsoft.com/kb/328890 , если поставить 1 то всё работает довольно быстро. Ну это не выход. Во-первых - нарушает чи большим братьям с полновесной реализацией TCP-стеков. Во-вторых - без полноценной поддержки Delayed ACK толку от этого на медленных каналах связи не будет - каждый пакет будет передаваться за время прохода туда и обратно. В принципе, можно дохачить uIP под полноценную поддержку Delayed ACK (и посылок размером в окно).
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 9 2009, 07:03
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
В общем нашёл ошибку ( надо было проверять что пакет уже ушёл, и в рассчёте размеров пакета в uip-split была ошибка). Ну и сделал отправку пустых пакетов. Теперь работает и то и другоe ( выбирается в uNetConfigure.h). Работать стало быстрее, но Линукс по прежнему опережает винду, почему то. Обновлённый релиз: http://uhttpd-avr.googlecode.com/files/uht...-2009-07-09.zip
Сообщение отредактировал Ilmarin - Jul 9 2009, 07:04
|
|
|
|
|
|
|
|
Jul 9 2009, 07:23
|
Участник
Группа: Участник
Сообщений: 20
Регистрация: 21-04-09
Пользователь №: 48 010
|
Цитата(Rst7 @ Jul 9 2009, 03:13) Да потому, что все это - костыли. Если такое просунуть через медленный канал, будет ужасно. Надо реализовывать правильную работу с окном. Ну, это всё делается не для того чтобы сотню запросов в секунду обрабатывать. Сейчас уже на мега32 память почти вся занята ( и это при том что буфер установлен в 400 байт и максимум 2 паралельных соединения): AVR Memory Usage ---------------- Device: atmega32u4 Program: 25658 bytes (78.3% Full) (.text + .data + .bootloader) Data: 2125 bytes (83.0% Full) (.data + .bss + .noinit) EEPROM: 19 bytes (1.9% Full) (.eeprom)
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
