Крч, как я понял, никто W-шкой через иде не занимался и особо не вникал в это...
Ну это вы про ардуинщиков. Приобщайтесь к тем, кто не тупо использует чужие библиотеки, а работает на более низком уровне, требующем понимания что и как там под капотом устроено.
У меня капот обычно на радиовещательных станциях, под ним я знаю от души , а для остального - скорость в реализации. Вопрос касался развития этого проекта, http://rw6hrm.qrz.ru/vigintos.htm Своё решение я доозвучивал в предыдущем посте.
Цена вопроса за официальное железо на тот момент и его доступность (2022 год). Плюс включение в сетку из 27 городов. Посему и телеметрия своя, и РДСики свои, и хотелки свои. А теперь и передатчики. (ну и элемент "психа", когда хочется получить результат как можно быстрее и не ждать, пока денежка выделится, пока поставка пройдёт) Ладно, а то в оффтоп валимся
Вопрос был не в том, почему не использовали готовые преобразователи Ethernet-EIA-485, а почему нагородили огород с аналоговыми мультиплексорами вместо одного трансивера для 485-го?
Повторяю - цена вопроса. В зоне доступности железа на то время не было, предлагались только преобразователи с 485 на 232. А на точке, тем более, все девайсы рядом, вот и соединились в один блок. А теперь 485 не нужен. А, ну и контроль - либо спецсофтина, только с одного рабочего места, либо любой бро с любой точки сети. Ну и в первом абзаце я объяснил причину.
Тогда "моих" плат ещё и в планах не было. А уж когда на ремоте поставил, то давать ходу назад не хотелось. Тем более, что в сетке есть передатчики, у которых только аналоговые выходы, без цифровых наворотов. Вот и остановился на этом. ...а что, атмегу можно подключить по 485? По 232 понятно,...
Приплыли. Только из уважения к человеку, который пусть и коряво, но пытается решить насущную проблему, отвечу по-доброму: легко!
На фото решение вашей задачи. Это ПЛК, из которого можно убрать всё, кроме последовательных интерфейсов и части DO. Высвободившиеся DI можно задействовать для ввода аналоговых сигналов хотя бы с минимальными защитами, которых в вашей схеме нет.
Кстати, один из ползунковых переключателей переводит ПЛК в режим конфигурирования, в котором активирует FTP-сервер, встроенный в ПЛК, что используется для загрузки конфигурационных файлов, в том числе и файл с настройками для IP-протокола.
> отвечу по-доброму: легко! Спасибо Если реально, то подобные поделки у меня спонтанны и одноразовы (и корявы, ага, хотя РДС-кодер пошел в серию. А, и только на DIP-ах!, более мелкого уже даже не вижу). Главное - нормальный сигнал в эфире, остальное приложится...
день добрый. ковыряю w5500, нужно разобраться с режимом http-клиент, т.е. - отправить на http-сервер запрос/сообщение - получить ответ/проанализировать - далее по "накаканной" ...
ваш "мини-конспект", сокращенный до минимума:
Код:
1. Создаем socket (записываем в него протокол и порт) - net_sock_init_xxx() 2. Открываем socket (OPEN) 3. Пишем IP (Destination), порт (Destination) сервера (HTTP 80 / HTTPS 443) 4. Подключение к серверу (CONNECT)
W5500_client подключается к серверу: >SYN >SYN ACK >ACK --> W5500_client подключился к серверу
5. После подключения к серверу сокет перейдёт в режим ESTABLISHED - Ждём пока сокет перейдёт в режим ESTABLISHED
6. Читаем начальный адрес буфера TX 7. Пишем данные с начального адреса буфера TX W5500_client должен прикинуться браузером, передать серверу пакет: 'GET /data.php?a=7 HTTP/1.1\r\nHost: 192.168.0.200\r\nUser-Agent: ................. \r\n\r\n|'
8. Пишем указатель буфера TX до увеличенного значения 9. Пишем команду передачи буфера TX (команда SEND) 10. Сервер прочитает наш пакет и ответит W5500_client пакетом: 'HTTP/1.0 200 OK\r\Conten-Type: text/plain; charset=windows-1251\r\n' // набивал вручную со скрина
- можем прочитать ответ сервера / можем не читать, - может просто подождать пока сервер закроет соединение (отправит нам пакетом FIN)
11. - Ждём когда сервер закроет соединение (принимаем пакет FIN от сервера). - или Закрываем socket и переходим к пункту -> Открываем socket (команда OPEN). - или не закрываем сокет и переходим к пункту -> Передача пакета серверу.
вопрос 1: 10/11-"пукнт" не раскрыт, т.е. прием ответа. можно подробненько (если не сложно) по полкам разложить?! в частности, не понятно как отследить прием ответа от сервера? переводить сокет в режим LIST, отслеживать SOCK_ESTABLISHED, потом обратно ...?
вопрос 2: - планирую "соединение" не закрывать принудительно, а работать с постоянно открытым соединением (когда оно будет закрыто по таймауту то открывать опять и... по кругу) возможен/рабочий такой вариант?! т.е. зачем закрывать соединение, если оно может понадобиться в ближ. время? ну а если не понадобиться, то "само закроется". :о)
переводить сокет в режим LIST, отслеживать SOCK_ESTABLISHED не надо.
в режиме ESTABLISHED достаточно прочитать размер принятых данных:
-если размер принятых данных больше нуля (if len > 0) значит сервер отправил нам данные. можем прочитать ответ сервера / можем не читать. переходим к следующему пункту.
-если размер принятых данных равно нулю (if len == 0) значит сервер не отправлял нам никаких данных. переходим к следующему пункту.
sunjob писал(а):
- планирую "соединение" не закрывать принудительно, а работать с постоянно открытым соединением (когда оно будет закрыто по таймауту то открывать опять и... по кругу) возможен/рабочий такой вариант?
возможен.
в режиме ESTABLISHED мы можем находиться сколь угодно долго... в режиме ESTABLISHED сервер и w5500 находятся в режиме удержания соединения. при этом сервер и w5500 каждые ~45 секунд обмениваются служебными пакетами ACK (подтверждая что соединение всё ещё открыто) сервер [TCP keep-alive segment] > w5500 [TCP keep-alive segment] сервер [TCP keep-alive segment] < w5500 [TCP keep-alive segment] сервер [TCP keep-alive segment] > w5500 [TCP keep-alive segment] .... .... .... всё это происходит автоматически... без нашего участия))
и так до тех пор пока мы (или сервер) не захочет разорвать соединение.
пока мы находимся в режиме ESTABLISHED мы можем в любой момент отправить данные серверу...
sunjob писал(а):
не понятно как отследить прием ответа от сервера?
второй способ отследить прием ответа от сервера: настроить вывод INT на приём.
-если вывод INT лог "0" (if INT == 0) значит сервер отправил нам данные. можем прочитать ответ сервера / можем не читать. переходим к следующему пункту.
-если вывод INT лог "1" (if INT == 1) значит сервер не отправлял нам никаких данных. переходим к следующему пункту.
я использую оба варианта одновременно: -сначала читаю вывод INT. -потом читаю размер принятых данных. это я делаю... для надежности))
зачем закрывать соединение, если оно может понадобиться в ближ. время? ну а если не понадобиться, то "само закроется".
само оно не закроется... кто-то должен его закрыть... или мы или сервер. иначе будем сидеть в режиме ESTABLISHED до бесконечности... пока не отключат Интернет))
вообще... не нравится мне логика работы w5500... поэтому я решил написать свой транспортный протокол... на меги328... чтоб было ещё интересней))
кто-то должен его закрыть... или мы или сервер. иначе будем сидеть в режиме ESTABLISHED до бесконечности...
Нет, закроется гораздо раньше. В доках на IP указано, через сколько времени соединение будет закрыто при отсутствии обмен. Заметьте, его закроет сам стэк, в вашем случае W5500.
В доках на IP указано, через сколько времени соединение будет закрыто при отсутствии обмен.
"доки на IP", в которых пишут, что должен делать tcp :rofl: Если серьёзно, при использовании tcp конечно важно, транспорт чего именно он контролирует. В случае интернет-сервисов всяких ("серверная" реализация IP, так сказать) используют RFC 1122 как референс. Это не "доки на IP", конечно - там правила по всем уровням
Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off.
Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours.
Краткое содержание данной серии: Можете использовать keep-alive. Можете не использовать. Будете использовать - должны задать интервал бездействия. Минимум два часа. По факту все операционные системы ровно так и делают - 7200 секунд. Интервал должен быть конфигурируемым, keep-alive отключаемым. По-умолчанию должен быть отключен. RFC писали в те благословенные времена, когда в Интернете все друг друга знали и к примеру SMTP не предусматривал никакой идентификации клиента Сейчас, конечно, на этот стандарт забивают. Но по "докам" если, то вот так.
На сколько помню, в BSD сокетах по умолчанию стояло 6 часов. Это сделано на случай, когда с клиента сняли напряжение питания, и он не смог отправить сообщение на закрытие соединения. В своих приложениях на стороне сервера я разрываю соединение сразу после ответа клиенту. В W5500 на одном IP-порту может быть только одно подключение, и сброс соединения после ответа позволяет опрашивать один ПЛК нескольким ОРС-серверам.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 14
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
, а для остального - скорость в реализации. Вопрос касался развития этого проекта, 
