TCP/IP + ATMEGA128 + CS8900, Подскажите с чего начать, примеры Опции

[cpl]

Требуется разработать TCP сервер для удаленных измерений.
за основу взял Мегу128 + CS8900 + RAM 64k
решил копать с сторону LWIP стека (с перспективой использования стека под арм).
Вопрос чего начать, по скудной документации понятно что лучше работь в режиме callback function (попроше), несовсем понятно с чего начинать как инитить сам стек и обрабатывать пакеты.

железо запустил, принимает пакеты и выводит в UART порт, подошел к стеку и попал в тупик, подскажите как с ним работать ?

[pitt]

http://www.ethernut.de/

[cpl]

Интерисует именно стек LWIP

[Nanobyte]

Интерисует именно стек LWIP

15 секунд поиска в Yandex дали:
http://www.sics.se/~adam/lwip/

[cpl]

с этого и начинал, примеров использования ненашел
ткните носом

[impatt]

с этого и начинал, примеров использования ненашел
ткните носом

The lwIP API uses a connection abstraction similar to that of the BSD socket APIThe lwIP API uses a connection abstraction similar to that of the BSD socket API

Это значит, что запускаешь свой любимый дистрибутив линукса, например, команда info libc sockets, там всё есть, с примерами. Заодно и проверишь на линуксе, свои примеры, а потом на контроллере.

Кстати, на сайте есть pdf-ка, там есть примеры.

Сообщение отредактировал impatt - Nov 8 2006, 05:53

[iosifk]

Требуется разработать TCP сервер для удаленных измерений.
за основу взял Мегу128 + CS8900 + RAM 64k

Могу прислать описания и софт для micrel.com - KSZ8842/1 - и это будет Ethernet 10/100.
Это примерно 6 Мег.
И сделайте поиск по нику "Волощенко". Он только что аналогичеую вещь закончил на CS8900, подумал над жизнью и попросил образец KSZ8842....
Вот для затравки пара документов.

Прикрепленные файлы

 KSZ884x_Programmer_s_Guide_v1.0.pdf ( 304.71 килобайт ) Кол-во скачиваний: 1347
 ____________________________.zip ( 49.82 килобайт ) Кол-во скачиваний: 81

 

[vesago]

Начать наверное лучьше с ознакомления с TCP/IP, тогда думаю и с lwip проще разобраться будет. Благо, что читать не очень много. Понравилось описание на www.protocols.ru. Можно и самому написать. Вам надо к блоку данных добавлять заголовок TCP или UDP, к этому пакету добавить заголовок IP и пулять в сеть. И обратно. По большому счету ничего сложного. Геморно только TCP реализовать - много факторов влияет на смену текущего состояния TCP. Больше всего и читать по нем. Может вам будет достаточно UDP, тогда все проще, но придется "самому" контролировать доставку.

[cpl]

с этого и начинал, примеров использования ненашел
ткните носом

The lwIP API uses a connection abstraction similar to that of the BSD socket APIThe lwIP API uses a connection abstraction similar to that of the BSD socket API

Это значит, что запускаешь свой любимый дистрибутив линукса, например, команда info libc sockets, там всё есть, с примерами. Заодно и проверишь на линуксе, свои примеры, а потом на контроллере.

Кстати, на сайте есть pdf-ка, там есть примеры.

Как я понял под BSD нужно ос, чтоб разруливать, ос непредполагается, поэтому callback
а на нее примеров нет

[cpl]

Начать наверное лучьше с ознакомления с TCP/IP, тогда думаю и с lwip проще разобраться будет. Благо, что читать не очень много. Понравилось описание на www.protocols.ru. Можно и самому написать. Вам надо к блоку данных добавлять заголовок TCP или UDP, к этому пакету добавить заголовок IP и пулять в сеть. И обратно. По большому счету ничего сложного. Геморно только TCP реализовать - много факторов влияет на смену текущего состояния TCP. Больше всего и читать по нем. Может вам будет достаточно UDP, тогда все проще, но придется "самому" контролировать доставку.

С протоколом ознакомился, думаю начальство неодобрит переписывания стека

[impatt]

Как я понял под BSD нужно ос, чтоб разруливать, ос непредполагается, поэтому callback
а на нее примеров нет

Неправильно.
Написано, что механизм взаимодействия с библиотекой такой-же, как в BSD (такой-же, как в Линуксе, *BSD, такоей-же, как в винде 9х, если не ошибаюсь по поводу последней - та, что winsock.dll имеет).
Это значит, что у тебя есть несколько функций, посредством которых ты можешь получить доступ ко всем примочкам.
По поводу линукса (да хоть той-же *BSD) - эта ось на настольном компьютере поможет тебе нормально промоделировать работу твоей проги под эту библиотеку, ибо API - одинаков.
Ферштеен ?

Сообщение отредактировал impatt - Nov 8 2006, 11:46

[cpl]

Как я понял под BSD нужно ос, чтоб разруливать, ос непредполагается, поэтому callback
а на нее примеров нет

Неправильно.
Написано, что механизм взаимодействия с библиотекой такой-же, как в BSD (такой-же, как в Линуксе, *BSD, такоей-же, как в винде 9х, если не ошибаюсь по поводу последней - та, что winsock.dll имеет).
Это значит, что у тебя есть несколько функций, посредством которых ты можешь получить доступ ко всем примочкам.
По поводу линукса (да хоть той-же *BSD) - эта ось на настольном компьютере поможет тебе нормально промоделировать работу твоей проги под эту библиотеку, ибо API - одинаков.
Ферштеен ?

Спасибо теперь начинаю понимать, значит вовсе необязательно использовать низкоуровневые callback функции, (с winsock немного знаком)

как привязывается API к железу, через какую функцию ?
правильно ли я понял что низкоуровненвые функции ВВ находятся
\src\netif\ ethernetif.c
в частности low_level_output и low_level_input ?
для чего нужен loopif.c ?
slipif.c так понимаю для работы по протоколу slip.
поправте если неправ

[impatt]

Спасибо теперь начинаю понимать, значит вовсе необязательно использовать низкоуровневые callback функции, (с winsock немного знаком)

Никаких, как я понимаю, callback-ов. Если я и упомянул про winsock.dll (а не winsock2.dll), то только потому, что слышал, что в ней использовались фукции а-ля BSD. Сам winsock-ом не пользовался.

Так как я не пользовался этой библиотекой, то точно ответить на следующие вопросы не могу.
Могу посоветовать скачать доку http://www.sics.se/~adam/lwip/doc/lwip.pdf и поглядеть по главам, а также пытаться скомпилировать проект и поглядеть, что получается.

как привязывается API к железу, через какую функцию ?

Надо, главным образом, как я понимаю, пару функций принимающих пакет и отправляющих его. Это, условно говоря, связь с железом.

правильно ли я понял что низкоуровненвые функции ВВ находятся
\src\netif\ ethernetif.c
в частности low_level_output и low_level_input ?

Я не очень в курсе, что такое BB...
К сожалению, не могу подсказать и касательно указанных функций и файлов: не имел дела я с этой библиотекой.
Могу посоветовать пытаться скомпилировать проект (чего будет недостаточно, а конкретно, связь с железом - будет ошибка и там рыть надо, или, если скомпилируется, отладчиком смотреть, что куда пишется и обращается, станет понятнее), почитать доку неспеша, а также поэкспериментировать с высокоуровневыми функциями на работающей системе (Linux, *BSD).

[cpl]

Понял, попробую.

[defunct]

С протоколом ознакомился, думаю начальство неодобрит переписывания стека

Гм.. а я думаю начальству все равно какой там будет стек, больше всего их будет волновать функциональность.
На мой взгляд LwIp сделан криво.

[cpl]

С протоколом ознакомился, думаю начальство неодобрит переписывания стека

Гм.. а я думаю начальству все равно какой там будет стек, больше всего их будет волновать функциональность.
На мой взгляд LwIp сделан криво.

Встречный вопрос, какой стек считаете сделан номально ?

[ig_z]

На мой взгляд LwIp сделан криво.

Что вы имеете ввиду под "сделан криво"? Архитектурные решения? И что по вашему прямее?

[defunct]

Встречный вопрос, какой стек считаете сделан номально ?

Нормально сделнный возможно и не влезет в m128.. ;>
Для embedder'овских нужд считаю, что лучше опираться от uIP в силу того, что он меньше и его проще дорабатывать под свои нужды.
Ну а также попробуйте предложить вашему начальству применить UDP, если согласятся - вам будет гораздо проще.

[vesago]

Имхо я особой нужды в TCP тоже не вижу. Как правило TCP требуют от нашего брата писатели верхнего софта из-за лени несколько усложненить верхний софт при работе с UDP. Кстати хотел спросить народ - я закончил написание TCP, чтоб передавать данные через GPRS. Теперь совершенно не представляю как отладить. Непосредственно с сервером опсоса дороговато как-то. Может кто поделится мыслями?

[defunct]

спросить народ - я закончил написание TCP, чтоб передавать данные через GPRS. Теперь совершенно не представляю как отладить. Непосредственно с сервером опсоса дороговато как-то. Может кто поделится мыслями?

Через LAN, т.к. для TCP физика непринципиальна, а GPRS обеспечивает полноценный доступ в инет.

[vesago]

Понятно это. Получается надо брать вроде реалтековской микрухи или инного изернет контроллера с обвязкой и подключать к моей меге? Или есть инной способ? Я имею ввиду вот что - виртуальных портов встречал массу. Есть ли в природе прожка - мосто между ланом и ком портом, которая не режет заголовки, а отправляет в порт и наоборот.

[defunct]

Я имею ввиду вот что - виртуальных портов встречал массу. Есть ли в природе прожка - мосто между ланом и ком портом, которая не режет заголовки, а отправляет в порт и наоборот.

Ну это скорее девайс, а не прожка ;>
Хотя для отладки можно поднять PPP/SLIP и работать через UART.

[dch]

На мой взгляд LwIp сделан криво.

Не сколько стек криво сделан сколько продукция micrel выглядит привлекательной

[vesago]

Хотя для отладки можно поднять PPP/SLIP и работать через UART.

Поясните, пожалуйста, что вы имеете ввиду? PPP у мнея написан, т.к. GPRS это подразумевает. Но я на данный момент не представляю, как я могу воспользоваться этим. Мне нужно проверить взаимодействие моего TCP с другим. Допустим Windows посредством какого телнета или терминальной программы. Правильно ли я понял, что вы мне предлагаете самому написать прогу, которая будет принимать IP пакет, завернутый в PPP и кидать в лан и обратно? Или как-то можно иначе сделать?

[defunct]

Правильно ли я понял, что вы мне предлагаете самому написать прогу, которая будет принимать IP пакет, завернутый в PPP и кидать в лан и обратно? Или как-то можно иначе сделать?

Можно и так, кстати совсем неплохой вариант.
Хотя я подразумевал использование имеющихся средст удаленного доступа к сети.

[vesago]

Хотя я подразумевал использование имеющихся средст удаленного доступа к сети.

Правильно ли я понял, что вы имеете ввиду идею создать модемное соединение, дивайсом проэмулировать процесс инициализации модема, а затем гонять данные в PPP?

[defunct]

Правильно ли я понял, что вы имеете ввиду идею создать модемное соединение, дивайсом проэмулировать процесс инициализации модема, а затем гонять данные в PPP?

Да,
это будет самый простой и правильный в плане отладки способ, с учетом того, что у вас уже сделано.

[alekseykoj]

Я впринципе реализовал стек протоколов самостоятельно. По объему не так и много получилось. Намного выгоднее чем заморачиваться с системой. Библиотеку реализации стека могу подогнать. Не забесплатно конечно

[vesago]

Я тоже сам накатал под мегу128. Но у меня частный случай - сокет нужен один, принимать кроме ацков ничего не надо, рамы под это дело максимум байт 500 - 700. В принципе писать легко. Только TCP геморно. Впервые пришлось накидать алгоритм, а то путаница с этими флагами. Еще так и не понял с контрольной суммой для TCP. В стеках смотрел и читал, что и для ip и для tcp одна функция расчета. Как не пробовал - муть получается. В смысле не сходится с тем, что в лане передается. Пришлось для tcp отдельную функцию написать с переворотом внутри слов. 2 defunct, спасибо. Самому как-то даже в голову не пришел такой вариант отладки. Подключу модем, сниму лог соединения - попытаюсь реализовать. Благо движок обработки месаг модемных у меня уже сидит в проге.

[alekseykoj]

У меня впринципе немного покруче будет.... Поддерживаются протоколы TCP и UDP. По протоколу TCP устройство может быть как сервером так и клиентом. Занимает это все добро около 10 кБ

[impatt]

Кстати хотел спросить народ - я закончил написание TCP, чтоб передавать данные через GPRS. Теперь совершенно не представляю как отладить. Непосредственно с сервером опсоса дороговато как-то. Может кто поделится мыслями?

Если осилил написание TCP (хотя наверняка получился недоделаный и дырявый - даже на очень эксплуатируемых стеках во всех, думаю, осях ошибки находят чуть ли не по сей день), то осиль запуск pppd (сервис ppp) на каком-нибудь *NIX-е, например, Линукс или *BSD.
Это процесс, который цепляется на указанный, условно говоря, ком-порт (реально терминал или поток ввода/вывода из другого процесса) принимающий оттуда ppp кадры, и создающий/удаляющий IP интерфейс в системе.
Таким образом сможешь проверить, как работает твой софт.
Для того, чтобы убедиться, что правильно настроен pppd, проще, если работаешь в винде, создать модемное соединение на каком-нибудь КОМ-порту и соединить машину с pppd и виндой нульмодемным кабелем.


Вопрос: зачем изобретать велосипед и делать что-то снова своё, а не брать уже готовое и отлаженое ?

[vesago]

Изобретать велосипед пришлось из-за ограниченности ресурсов. Как я указывал максимум 500-700 байт рамы. Мне показалось, что готовые требуют поболее. Куда ни глянь - везде лополнительная внешняя рама. Да и тяжеловато пока читать чужой код. Хотя много времени потратил в первую очередь на изучение сабжа. По поводу вашего совета - спасибо, но мне как-то строашно слово линукс. Это его на компьютер ставить надо. Я то в виндовсе не особо силен. Наверное быстрее я допишу модемную связь в своем дивайсе.

[impatt]

Изобретать велосипед пришлось из-за ограниченности ресурсов.

Ну, что-ж, тут возразить нечего.

Хотя много времени потратил в первую очередь на изучение сабжа.

Это, ИМХО, полезно.

По поводу вашего совета - спасибо, но мне как-то строашно слово линукс. Это его на компьютер ставить надо.

Желательно, но необязательно: есть же LiveCD.
Впрочем, если опыта в юниксах мало, то то, что сложно - понимаю. Однако настоятельно советую иметь под боком и по возможности экспериментировать, ибо там очень много полезных концепций. Полагаю, что многие согласятся с тем, что способы решения многих технических вопросов, в частности, с сетью, в юниксах (имею в виду linux, *BSD) сделаны существенно нагляднее, чем где бы то ни было, включая виндовс.
Есть чему поучиться, причём дело даже не в исходниках, а в программных и прочих интерфейсах.

[vesago]

А можно какую ссылочку - отправную точку по этому вопросу?

[vesago]

Попросил - состряпали для меня мост - гоняет из изернета и обратно ип пакеты, обрамленные в ppp. Одно не учел, что параллельно работает TCP винды. Я шлю через мост на удаленый TCP запрос соединения, он возвращает ACK + SYN. Винда естественно шлет RST удаленному TCP. Как сделать, чтоб винда игнорировала пакеты по такому-то порту никто не знает. В общем не пройдет такой номер. Поэтому точно буду через модем отлаживать. Как тут быть? Исходящее или входящее соединение? Лучьше входящее. Пробовал создавать и в терминале руками общаться. Не могу пройти этап соединения. Как только ввожу коннет, винда шлет +++ и ложит трубку. А я хочу, чтоб пошли ppp пакеты, согласовать параметры и получить доступ к TCP винды.