Привет всем.

Для решения одной задачи, нужно чтобы контроллер на LPC17xx мог брать файлы по сети с компа или NAS (в пределах локалки, хотя это вроде неважно).
Проще всего наверное по FTP, но если фтп-серверы для АРМов я встречал, то клиентов пока не нашел.

Не посоветует ли премудрый ALL где можно найти сорцы фтп-клиента, или может какое другое решение?

Если я не ошибаюсь, для простого клиента протокол FTP достаточно прост, чтобы можно было реализовать этого самого клиента самостоятельно без особых усилий. Особенно если заранее известно, с какими серверами этот клиент будет работать (какие опции поддерживаются и т.п.).

А где про это можно почитать? Дело в том, что основная часть проекта - ввод/вывод аналоговых величин, их обработка, управление процессами - тут я хорошо разбираюсь и приличный опыт имеется. А вот в сетевых устройствах и протоколах я пока слабо разбираюсь, и в данном случае это побочная и небольшая часть проекта. С эзернетом на LPC17хх пока дальше примеров на демоборде не продвинулся Собственно, на 50% из-за эзернета и USB и был сделан переход с AVR на LPC в новой версии девайса..

Я бы еще порекомендовал в сторону TFTP посмотреть. Как бы ни был FTP прост, а TFTP еще проще Он специально затачивался под "простые" системы.

http://ru.wikipedia.org/wiki/FTP
rfc внизу
дальше прямой путь в http://www.keil.com/support/man/docs/rlarm...m_tn_cfgtcp.htm

Сообщение отредактировал politen - Nov 13 2010, 21:16

RFC это понятно, мне непонятно другое - я вижу массу веб/фтп/тфтп-серверов, но не вижу ни одного клиента.
Возникают две мысли:
-или это настолько просто, что не заслуживает выделения в отлельный проект/пример и т.п.
-или это никому нафиг не надо.

во 2-м случае у меня возникает другой вопрос- может у нас неверно поставлена задача, и решать ее надо не методом фтп-клиента а другим?

На всякий случай, опишу эту часть задачи:
есть некое устройство, обрабатывающее входные аналоговые и цифровые сигналы, и выдающее опять-же аналоговые и цифровые обратно. в этой части проблем никаких нет.
в новой версии, хочется подключить устройство эзернетом к локалке, да и запитать его от нее (PoE). В локалке есть сервер, на который устройство периодачески должно сбрасывать логи, и периодически брать с сервера файлы конфигурации.
Т.е. если бы это было не устройство а комп, то я бы просто расшарил для него директорию на сервере и никаких фтп не надо было бы.

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

Вот тут Вы частично ответили на свой же вопрос Обычно, когда делаются устройства с возможностью дальнейшего развития в плане Ethernet и "установки их в другом городе", клиентские реализации уже не катят, т.к. Вы не знаете куда занесет устройство и, следовательно, оно само не знает куда ему коннектиться. А вот если оно - сервер, то уже не его забота знать где оно стоит. Опять же, возможно Вам захочется потом забирать логи с одного устройства двумя компами? Конечно, все зависит от конкретной задачи, но, как правило, все встроенные системы являются скорее серверами нежели клиентами, т.к. они предоставляют кому-то какие-то услуги, информацию, статистику и т.п.

Почему? Как раз если есть централизованный сервер для всех устройств, то устройство всегда знает куда ему коннектиться. А вот законнектиться к устройству которое находиться "где-то там" да еще и вероятно за проксёй - вот это задачка из гиморойных.

Вообще-то FTP клиентов довольно много открытых есть.
А вы где искали? Может вы не отличили клиента от сервера?

Это где-же так "обычно" делают Как раз в этом случае только клиент - сервер должен иметь внешний ip или маршрутизатор который будет перенаправлять соединение на нужные порты или весь трафик на него, а клиенту все равно - он может быть за NAT или proxy, ему как раз фиолетово какой у него ip, достаточно знать ip-адрес сервера и он законектится из любой точки мира где Интернет есть.

Ну, читать я вроде еще умею
А искал как обычно - гугглом, не считая просмотра аппликух - LPC, Keil, etc.
Если знаете что-то конкетное - буду очень признателен за ссылку.



Я конечно чайник в TCP/IP, но не настолько....
Как тут уже сказали - все наоборот, это серверу надо провисывать портфорвардинг или виртуальные серверы на роутере, а клиенту - надо знать только IP сервера.
Возьмите как пример E-Mule - как клиенту ему все равно где он стоит, лишь бы его порты небыли полностью закрыты на роутере. Ну даже если обратку не получит, будет в LowID, поганенько. но работать будет.
А вот как серверу (управление им извне через веб-интерфейс) - пока ему роутинг не пропишешь, кина не будэ.

Если Вы это планируете делать через Интернет в будущем - то логи и тем более конфиги по FTP - это офигенная дыра в безопасности.

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

на счет сброса логов: обычно как раз с устройства, которое ведет логи, эти самые логи снимаются внешним клиентом, а устройство выступает в роли сервера

Сообщение отредактировал politen - Nov 14 2010, 13:09

Предполагается два режима, в одном - раз в несколько часов, в другом - непрерывно.
После обсуждения у себя, остановились на FTP.
В локалке можно что-то другое (кстати, подскажите что, я знаю только NetBios, Samba), если оно проще в реализации чем фтп.

FTP клиенты есть в: eCOS, MQX, RTEMS, VxWorks, Nucleus и т.д.

Рекомендовал бы MQX и перейти на семейство Kinetis ARM Cortex-M4