Начал использовать W5500 в связке с STM32. Библиотека от WiZNET ioLibrary_Driver-master/ Все хорошо, создаю сокет, инициализирую устанавливаю в Listen, происходит соединение с клиентом (W5500 в режиме сервер). Данные принимаю и отправляю и по опросу и по прерыванию (на линии INTn). Все работает, до определенного момента. А именно контроллер W5500 рвет сессию с возвратом байта состояния Sn_SR = 0x64 открытого сокета. А такого состояния нет даже в datasheets!!! После этого я спокойно снова устанавливаю в режим listen и он снова принимает соединение и снова прекрасно работает. Сейчас я решил эту проблему на стороне клиента, проверяю connect и если разрыв, то поднимаю соединение снова. Но это не правильно.
Если, кто сталкивался или есть мысли, прошу подсказать или направить в нужное русло. Убил уже два дня.
Причем время непредсказуемо, от 2 мин до 2 часа, при этом обмен пакетами идет с интервалом через 5 сек и длиною 10-20 байт.
Да работаю на скорости по SPI=18. Работаю в FreeRTOS, менял размер стека для задач, ничего не меняется. Использовал разные версии FreeRTOS - ничего. Да, чип в экспериментах один, есть конечно и другие, но пока боюсь распаивать если не пойму причину.
Я думаю, что это глюки поддельных чипов. Модуль W5500 наверное на Али покупали, такой синенького цвета рублей за двести с доставкой. .У меня тоже были проблемы с подобными модулями - периодически обнулялись сетевые настройки. Пришлось ставить костыль на проверку обнуления. Я долго бился с этой проблемой, все думал, что я что-то делаю не так. Но если запустить тот же код на фирменной плате, которая правда и стоит как чугунный мост, то проблема исчезала. Так что с большой долей вероятности ваша проблема - это доплата за низкую начальную стоимость модуля. P.S. Не заметил сразу - у вас не модуль, а чип. Но это сути дела не меняет.
В общем проблема решилась, но дело было не в чипе. Если честно не понял в чем, но решение такое - отказался от FREE RTOS и написал свой диспетчер задач, благо не так много их. Чип покупался в Промэлектронике: 200 руб./шт. терпимо. 0х64 скорее всего вытаскивался из стека, хотя я до безобразия увеличивал стек и кучу. Не знаю в чем было дело. Работает более 24ч без сбоев и разрывов, передергивал шнурок - бодро подхватывает и восстанавливает соединение. Посмотрим. Возможно чуть позже покопаю библиотеку, но не сейчас.
А сетевые настройки все обнулялись или какие-то отдельные? Вы именно из регистров читали или смотрели в структуре?
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Я тоже использую w5500..... - это глю какой-то)) W5500 не понял команды и завис... )).....
Не понял команды так же не соответствует моему случаю, т.к. я продолжал читать регистр в бесконечном цикле и ответ был 0х64. Я не писал, что контроллер завис. Он продолжал нормально работать. Ни один регистр своих значений не терял и не изменял. В целом проблема решена, но не имеет ответа причины такого поведения.
И насчет UDP, в моем случае неприемлемо т.к. требуется гарантированная доставка пакета. Скорость не важна, размер пакетов не более 100 байт, интервал обмена на более 200 мсек. Так, что TCP!
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Ну бывало из-за плохого контакта или нестабильного питания у меня W5500 выдавал "мусор"... При этом W5500 продолжал принимать и отправлять пакеты... Для этого у меня есть RESET ))
А UDP проще... быстрей... надёжней... )) За гарантированную доставку пакетов у меня отвечает МК. Если с первого раза пакет не прошёл, то МК повторит передачу... UDP... > UDP... > UDP... > UDP... > UDP... > UDP... > И так хоть до посинения)) Пока пакет по дойдёт.)) Тем более всего 100 байт.))
Задачи во FREE RTOS - асинхронны и получалось так, что двум разным задачам нужно было получать данные с w5500! Первая задача отправляла запрос, происходило прерывание и передача управления второй задаче. Вторая задача отправляла свой запрос, но получала данные, которые были предназначены первой задаче. Эти данные, разумеется, были не корректны для второй задачи.
Мое решение: вытащил в отдельную задачу получение состояний с приоритетом Normal. Получаю состояния, в этой задаче 3 раза с интервалом 10 мсек, если все три раза совпали значения - значит истинные, если нет - просто не меняю и в паузу на 50 мсек. Можно было конечно сделать высокий приоритет и/или запрещать все задачи до получения состояний, но пока такое решение работает.
Если у кого-то есть идеи лучше, готов рассмотреть и прислушаться.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
