Многие из тех, кто имел дело с микроконтроллерами, наверняка слышали о микросхеме конвертере SPI <-> Ethernet W5500. В свое время эта микросхема стала поистине "народной" по многим причинам, к которым можно отнести как низкую стоимость самих микросхем и готовых модулей для прототипирования на их основе, так и наличие готовых библиотек под разные платформы для легкой интеграции чипа в различные проекты. К тому же, из-за относительно легкой модели взаимодействия между микросхемой и микроконтроллером, не составляло труда взаимодействовать с микросхемой без сторонних библиотек.
Однако времена шли и появлялось все больше дешевых микроконтроллеров, которые содержали внутри себя MAC уровень, требуя лишь снаружи микросхему PHY. А для ленивых производитель давал готовые решения по интеграции в проект LWIP со стороны софта и демо платы и примеры разводки PHY под свой микроконтроллер со стороны железа. Изредко появлялись чипы с PHY прямо на кристалле микроконтроллера.
Именно в этот момент WIZnet сделала следующий шаг - выпустила чип, который должен был сочетать функциональность W5500 с функциональностью обычного микроконтроллера, объединив тем самым в себе 2 микросхемы. Это техническое решение получило название W7500p.
Рассмотрим, что же из себя представляет W7500P в боевых условиях.
Общие сведения о чипе
У WIZnet имеется две реализации чипа линейки W7500. С суффиксом P (W7500p) и без (W7500). Разница лишь в наличии у W7500p внутри отдельного кристалла PHY (вторым этажом), который подключен к основному кристаллу микроконтроллера через выводы, не выведенные на пригодные для внешней пайки контакты микросхемы.
Вариант реализации без встроенного PHY может быть полезен в ряде случаев, в перечень которых входят жесткие требования к используемому PHY и требования к электромагнитной совместимости в целом. Также стоит помнить что PHY относительно сильно греется.
Я же буду рассматривать вариант с встроенным PHY, наиболее подходящим для дешевых интернет вещей.
Документация, ознакомительные примеры и демонстрационные платы
Так как WIZnet не является сильно популярным производителем микроконтроллеров, то на пути освоения их продукции пришлось столкнуться с множеством "детских" болезней начинающих разработчиков.
На официальном сайте W7500p имеется ссылка на покупку официальной демонстрационной платы, а также ссылки на документацию и готовые библиотеки. Однако не все так радужно:
Данная плата отсутствует в продаже как на официальном магазине, так и на AliExpress. Так как я хотел лишь изучить этот чип для себя, то не стал обременять себя с поиском остатков на Mouser или Элитан. Да и даже если бы я нашел ее там, то стоимость с доставкой одной единицы оставляла бы желать лучшего. Вместо нее на AliExpress есть клон этой платы, на которой убрали слот для модуля расширения, конвертер USB<->UART и добавили разъем программирования и разъем под Micro-SD карту, подключенную по SPI. Именно ее я и приобрел. И о ней далее пойдет речь.
Документация очень скудная. На описание работы TCP/IP стека приходится всего 2 страницы. На остальные модули и того меньше. Отдельно заслуживает внимания политика компании. "В документации этого нет, потому что это уже есть в демонстрационной библиотеке и знать вам об этом не надо". В ряде случаев единственное, что вы можете сделать, так это бездумно копировать "магические" строки из библиотеки себе в проект. Или использовать готовую библиотеку "на веру".
Все примеры, которые имеются под плату хоть и собраны под GCC и Keil, но работают только под Keil. Да, там почти одни и те же файлы, но почему-то ни один пример под GCC у меня из коробки так и не взлетел. И, что интересно, размер собранных bin файлов отличается в несколько раз. И рас уж мы говорим про примеры, то отмечу, что примеры из официального хранилища компании с этой платой работать не будут. Ни из под Keil, ни из под GCC. Там магические строки немного другие. Но об этом позже. Нам на помощь приходит хранилище от разработчиков неофициальной платы. Внутри там как obj файлы, так и исходники. К тому же, имена врут. Видно, что делали или в спешке или не очень добросовестно, но рабочий проект под Keil, что я нашел (для GCC по прежнему не работает ничего из коробки даже отсюда) назывался w5500.
Проект к статье
В своих домашних проектах я предпочитаю делать все с пониманием дела и на регистрах. Этот проект не стал исключением. Воодушевившись наличием рабочего проекта (хоть и не рабочего, если собирать GCC) я начал писать демо-проект с нуля. В готовом виде вы можете увидеть его здесь. Я буду подробно останавливаться на том, что касается именно данного чипа и вскользь упомяну инфраструктуру, на основе которой будет построен проект (о некоторых частях планирую написать отдельные статьи). Проект собирается cmake-ом и написан на C.
Проект включает в себя следующие субмодули:
vsrtos – очень маленькая операционная система реального времени собственной разработки без излишков. Использую ее в своих проектах и фриланс-проектах. О ней напишу в другой раз подробно. А для последующей части статьи достаточно знать, что ее внешний функционал похож на функционал FreeRTOS.
lib_service – библиотека с базовыми компонентами, отвязанными от аппаратной части, которые работают совместно на vsrtos. Из нее будет использован механизм мигания светодиодом в потоке ОС.
lib_w7500x – библиотека для работы с периферией микроконтроллеров W7500 и W7500p. За исключением самого проекта, весь аппаратно зависимый код находится здесь. Файлы из данного хранилища будут рассмотрены в этой статье.
Постановка цели проекта и описание требований
Для того, чтобы оценить возможности чипа, я решил написать небольшой демонстрационный проект, который бы использовал ключевую периферию.
Проект должен:
Работать на максимально возможной частоте.
Содержать операционную систему реального времени.
Из потока ОС мигать светодиодом, расположенным на плате, с частотой 1 Гц.
Из потока ОС раз в 500 миллисекунд отправлять на компьютер по UDP значение счетчика uint32_t переменной.
Хоть поставленные цели и звучат легко, но вот чтобы их реализовать на этом чипе пришлось изрядно постараться, но обо всем по порядку.
Пустой проект
Для начала было бы неплохо собрать проект, который просто инициализирует области в RAM и встает на бесконечное ожидание в функции main. Поскольку перед нами микроконтроллер с ядром Cortex-M0, то тут обошлось без приключений. В общем виде потребовалось написать:
mem.ld – файл с описанием деления памяти микроконтроллера на разные блоки (FLASH, RAM, STACK). Для удобства я всегда выделяю начальный стек в отдельный блок памяти. Этот же стек будет использоваться и обработчиками прерываний. В данном файле я использовал лишь 16 килобайт из первого блока RAM. Однако в чипе содержится 2 блока RAM. Один на 16 килобайт, а второй на 32 килобайта. Интегрированный TCP/IP стек использует второй блок памяти (на 32 килобайта) для приема и передачи Ethernet транзакций совместно с ядром (об этом подробнее далее). Так как 16 килобайт для моих задач было более чем достаточно, то я оставил весь второй блок для TCP/IP стека (о том как TCP/IP стек использует этот блок памяти сообщений, также будет сказано далее). Интересно также, что flash расположена не от 0x08000000 как в STM32, а от 0x00000000.
section.ld – файл с описанием расположения секций кода и данных по блокам памяти, описанным в mem.ld. Тут все как обычно: область .isr_vector а начале FLASH, хранящая таблицу векторов прерываний, за ней .text, хранящая код демонстрационной программы и стандартных библиотек компилятора, и области .data с .bss, расположенные в RAM, хранящие глобальные переменные, заполненными ненулевыми (.data) и нулевыми (.bss) значениями.
vector.c – файл с таблицей векторов прерываний для стандартных прерываний от Cortex-M0 + специфичных для W7500/W7500p. Неиспользуемые прерывания, в случае вызова, переводят выполнение процессора в код-заглушку для последующих исследований. Таблица составлена на основе кода из хранилища рабочего проекта разработчика платы и отличается от таблицы, представленной в документации.
loader.c – файл с методами копирования данных из flash в .data, очистки .bss, заполнения стека начальным, удобным для отслеживания переполнений значением, вызова main и, в случае выхода из main, программной перезагрузки ядра.
main.c – main функция с бесконечным циклом.
Данного набора достаточно, чтобы собрать ничего не делающий пустой проект, запустить его в отладчике и убедиться, что все работает.
Отладка проекта
Чип подключается к клону J-Link и отлаживается через pyOCD последней версии. В openocd для него нет скриптов. Для Keil есть pack, включающий в себя отладку. Отладка в обоих случаях происходит через SWD. Используется аппаратный reset вывод.
Для отладки в среде требуется настроить embedded GDB сервер со следующими параметрами:
'target remote' args: localhost:3333.
GDB Server: pyocd.
GDB Server args: gdbserver --target w7500 --connect halt.
В среде CLion настройка будет выглядеть следующим образом:
Сам процесс прошивки и начала отладки:
pyocd gdbserver --target w7500 --connect halt
0001317:INFO:board:Target type is w7500
0001698:INFO:dap:DP IDR = 0x0bb11477 (v1 MINDP rev0)
0001706:INFO:ap:AHB-AP#0 IDR = 0x04770021 (AHB-AP var2 rev0)
0001728:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=43b part=471)
0001751:INFO:rom_table:[0]<e000e000:SCS-M0+ class=14 designer=43b part=008>
0001768:INFO:rom_table:[1]<e0001000:DWT-M0+ class=14 designer=43b part=00a>
0001786:INFO:rom_table:[2]<e0002000:BPU class=14 designer=43b part=00b>
0001788:INFO:cortex_m:CPU core #0 is Cortex-M0 r0p0
0001790:INFO:dwt:2 hardware watchpoints
0001794:INFO:fpb:4 hardware breakpoints, 0 literal comparators
0001806:INFO:server:Semihost server started on port 4444 (core 0)
0001860:INFO:gdbserver:GDB server started on port 3333 (core 0)
0002593:INFO:gdbserver:Client connected to port 3333!
0002717:INFO:gdbserver:Attempting to load argon
0002717:INFO:gdbserver:Attempting to load freertos
0002718:INFO:gdbserver:Attempting to load rtx5
0002718:INFO:gdbserver:Attempting to load threadx
0002718:INFO:gdbserver:Attempting to load zephyr
[====================] 100%
0006312:INFO:loader:Erased 5120 bytes (20 sectors), programmed 5120 bytes (20 pages), skipped 0 bytes (0 pages) at 1.39 kB/s
Resetting target
Debugger connected to localhost:3333Мигаем светодиодом
Как говорилось ранее, в lib_service есть готовый модуль, который в потоке vsrtos инвертирует светодиод с заданным периодом. Однако он требует пользовательский метод для инвертирования светодиода. А значит настало время познакомиться с аппаратной периферией микроконтроллера. Заодно и сравним ее с периферией STM32.
Структуры модулей периферии микроконтроллера
На все модули периферии кроме TCP/IP стека имеются структуры с регистрами периферии в демонстрационном коде из хранилища. Данные структуры отличаются от того, что можно составить по документации, так как в документации множество ошибок. Структуры из рабочего демонстрационного проекта являются истиной в последней инстанции.
На модуль TCP/IP стека не было структур. Только макросы, которые оборачивали адреса регистров периферии.
Для единообразия я переписал эту часть на манер структур от более популярных производителей типа STM. Структуры периферии ядра описаны в файле core.h, а периферии микроконтроллера в periph.h библиотеки lib_w7500x.
Clock Reset generator (CRG)
Это аналог RCC у STM32. Однако он имеет ряд следующих отличий:
Вся периферия по умолчанию включена.
PLL по умолчанию включен. В качестве источника используется внутренняя RC цепь на 8 МГц, а коэффициенты деления с последующим умножением составляют 5 и 2 соответственно.
Все линии тактового сигнала после PLL подключены к блокам периферии с делителем 1 (bypass).
Отсутствуют механизмы анализа выхода на требуемую частоту или детектирования отказа внешнего HSE. Вместо этого есть возможность вывести с любой шины тактирования сигнал на вывод GPIO.
Имеется отдельный генератор частоты для MII_RXC и MII_TXC, работающий от отдельного внешнего кварцевого резонатора. Его можно только включить или выключить. Кварцевый резонатор должен быть на 25 МГц. По умолчанию он включен.
Какие-либо рекомендации по последовательности настройки в документации отсутствуют. Также как и механизмы восстановления в случае установки ошибочных коэффициентов. Микроконтроллер просто начнет вести себя неадекватно при неверных коэффициентах HSE или в случае установки некачественного HSE.
Основываясь на выдвинутых требованиях к проекту, требуется настроить PLL на максимальную частоту 48 МГц и при этом переключить источник с HSI на HSE. После чего выключить HSI. Это делается в 3 строчки кода в файле crg.c библиотеки lib_w7500x.
Порты ввода-вывода (GPIO)
Тут все достаточно сложно. Вместо одного модуля GPIO + EXTI, как это сделано у STM32, тут у нас 3 + EXTI:
Alternate Function Controller (AFC) – данный модуль предоставляет функционал аналогичный выбору альтернативной функции AFx в STM32F4 и схожих. В отличии от STM32, все выводы по умолчанию имеют не функцию входов, а альтернативную функцию, соответствующую наиболее вероятному сценарию использования, которую предполагает производитель. В связи с этим, для того, чтобы помигать светодиодом, для начала нужно убедиться, находится ли требуемый вывод в режиме GPIO, а не подключен к какой-либо периферии. Если подключен, то требуется перевести его в режим работы с GPIO.
External Interrupt (EXTI) – в этом модуле примерно то же, что и в модуле EXTI у STM32F4, только проще. Можно выбрать, генерируется ли прерывание по переходу в требуемый уровень шины сигнала или нет, и по переходу в какой уровень (0 или 1) оно произойдет (речь идет именно о сигнале на внутренней шине между EXTI и GPIO, а не сигнале на входе пина).
-
Pad Controller (PADCON) – этот модуль предназначен для конфигурации параметров выбранного пина. Тут можно настроить:
Нужна или нет подтяжка к питанию или земле.
Ток выходного сигнала (большой/маленький). Конкретные значения для разных конфигураций указаны в reference manual на странице 150, раздел GPIO.
Является ли выход выходом с открытым коллектором или нет (если нет, то, как я понял, это аналог push-pull).
Включен ли встроенный буфер на входе или нет.
Включен триггер Шмитта на входе или нет.
-
General-purpose I/Os (GPIO) – модуль сочетает в себе часть RCC и часть GPIO из stm32 и позволяет:
Включать/выключать выходы на пины (режим входов всегда включен).
Считывать данные с входов (после прохождения через буферы и триггеры Шмитта, если включены).
Выставлять данные на выходы пинов (будут выведены только если выход на пине включен).
Считывать/очищать состояния наличия прерываний на пинах.
Выбирать режим срабатывания прерывания: по уровню или спаду/подъему.
Выставлять полярность (в случае срабатывания по совпадению уровня) или границу (в случае срабатывания по фронту или спаду) возникновения прерывания.
Работать с модулем через пространство масок.
Вышла достаточно сложная структура. Для упрощения логики работы с ней был написан ряд простых методов, которые позволяют сделать вид, что весь перечисленный функционал находится в одном модуле. Найти эти методы можно в файле gpio.c библиотеки lib_w7500x.
Для наших целей нам нужно было помигать светодиодом. Он расположен на выводе PC13, который по умолчанию является одним из выводов UART. В файле gpio.c демонстрационного проекта можно посмотреть на его инициализацию, а также на функцию установки состояния на выходе. Последняя передается в аппаратно независимый модуль и мигает светодиодом с заданным периодом.
SYSTIC
Для работы vsrtos, как и для любой RTOS с вытесняющей многозадачностью нужен таймер. В данном микроконтроллере имеется стандартный SYSTIC, который при входной частоте 48 МГц, подаваемых на ядро, тактируется от 6 МГц. Однако есть нюанс. В документации отсутствует бит CLKSOURCE из CSR. Я так и не смог понять, откуда идет частота при 0 в этом бите. Но при 1, все сходится с теоретическими расчетами.
Работа с TCP/IP стеком
Вот мы и добрались до основного модуля, ради которого всё и затевали. Чисто теоретически, для того, чтобы начать отправлять сообщения по UDP, достаточно лишь настроить выводы микроконтроллера, настроить PHY, дождаться подключения кабеля, открыть RX сокет и отправлять в TX сокет свои данные, игнорируя данные в RX сокете (запускаются парами). Однако тут возник ряд нюансов:
Так как внутри нашей микросхемы два кристалла, то часть выводов микроконтроллера не выведено наружу и подключено сразу к PHY. Однако какие именно это выводы - нам не сказано. Но изучение исходников библиотеки, которые писали магические константы по несуществующим адресам + немного дедукции навели на мысли в какие именно регистры какой периферии идет запись.
В подключении между двумя кристаллами (MAC на одном и PHY на другом) есть не подключенный контакт, который приводит к тому, что временами в транзакциях ping скачет с 1 мс до 700 мс. Что для отправки UDP пакетов напрямую кабелем в сетевую карту компьютера значительно. К счастью, в errata по этому поводу имеется специальный раздел. Там просят присвоить константы по постоянным адресам, которых нет.. Опять же, почитав код в пункте 1, стало понятно, что на определенные выводы вешается подтяжка к земле, а на другие к питанию. А на один вывод вообще выставляется логическая единица. Сборную солянку этого можно увидеть в функции init_miim_pins файла eth.c библиотеки lib_w7500x.
Инициализация PHY происходит не через интерфейс MDIO. Его тут попросту нет. Или есть, но нам и тем, кто писал демонстрационный код и документацию об этом не сказали. Все происходит средствами ручного управления пинами. Как принято говорить среди разработчиков "ногодрыгом". Попеременно меня назначение пина. Посмотреть на чуть измененный код ногодрыга для MDIO можно в функциях mdio_idle, mdio_out, mdio_turnaround, mdio_in. Эти методы используются методом mdio_get_data, предназначенным для получения содержимого регистров PHY. Метод phy_init инициализирует пины, и средствами метода get_phy_id пытается получить ID интегрированного PHY. В моем случае он был равен 5.
-
Как я говорил ранее, второй блок RAM предназначен для TCP/IP стека. А именно:
32 килобайта поделены на два. 16 килобайт для отправки и 16 килобайт для приема. Эти значения фиксированы и не могут быть изменены.
Внутри каждого блока по 16 килобайт можно разбить память для используемых сокетов. В зависимости от задачи. По умолчанию 32 килобайта делятся на максимальное количество поддерживаемых сокетов - 8 штук. То есть, по 2 килобайта на сокет для отправки и 2 килобайта для этого же сокета на прием.
Размер буфера для передачи и приема у одного сокета можно задать разный. Однако размеры кратны двойке: 0, 1, 2, 4, 8, 16 килобайт. То есть, в теории, можно создать один сокет, который будет иметь 16 килобайт для приема и 16 для отправки. Я же оставил данные параметры по умолчанию.
-
Те участки памяти, которые предназначены для каждого сокета для приема и передачи представляют внутри себя кольцевой буфер. Разберу на примере передачи. Пусть у нас сейчас только началась работа системы. Мы хотим передать 4 байта. Для этого нам нужно:
Считать из специального регистра-указателя текущее положение в кольцевом буфере.
Взять адрес начала буфера и прибавить к нему смещение внутри кольцевого буфера.
Скопировать данные для отправки в буфер по полученному адресу в пункте 2. Если буфер закончился в процессе помещения данных для отправки, то продолжить писать сначала.
Положить в регистр-указатель из пункта 1 прежнее значение плюс длина данных, которые мы приготовили для отправки.
Весь TCP/IP стек представляет для разработчика конечный автомат с множеством состояний и флагов. То есть для того, чтобы начать коммуникацию первый раз, сначала понадобится уточнить, что машина состояний сброшена - сокет закрыт. Далее требуется настроить параметры и дождаться, пока машина состояний перейдет в нужное нам состояние - соединено. С отправкой то же самое. Убеждаемся, что машина состояний находится в состоянии ожидания следующей транзакции, настраиваем пакет для отправки, переводим машину состояния в состояние отправки, и ждем либо переход в состояние истечения времени ожидания, либо окончания передачи. За открытие сокета и последующую отправку в него (с возможным закрытием по желанию пользователя) отвечают методы socket_udp_close, socket_udp_open и socket_udp_send файла eth.c библиотеки lib_w7500x.
Копировать в кольцевой буфер данные можно с помощью DMA. Но я для теста делал ручное копирование, поскольку это лишь первый опыт и реального применения пока не было.
У TCP/IP стека имеется прерывание. Его можно настроить как на срабатывание по общим событиям всего модуля, так и по конкретным на каждом из каналов. Однако при передаче мелких пакетов его надобность практически равна нулю. Так что в примере прерывание не применяется.
В файле eth.c демонстрационного проекта есть задача eth_thread, которая настраивает PHY, открывает сокет со статическими параметрами в режиме UDP, и производит отправку значения счетчика каждые 500 миллисекунд. Поток не рассчитан на отключения кабеля в ходе процесса отправки. При отключении кабеля закрытие канала не происходит. И после его подключения обратно отправка продолжится сама.
В хранилище разработчиков используемой платы имеются библиотеки для DHCP, эхо-ответа (тест через утилиту nc), HTTP сервера/клиента. В случае надобности, можно продолжить доработки на их основе.
Подключение к компьютеру
Собрав и зашив проект в микроконтроллер, он после перезагрузки начнет отправлять данные в UDP сокет на статический адрес и порт. Важно, чтобы сеть на компьютере была в той же подсети и была настроена статически. Пример для Ubuntu:
В проекте есть python скрипт rx_udp.py, который открывает сокет-приемник и выводит приходящие сообщения в бинарном виде:
$ python3 rx_udp.py
b'00000000'
b'01000000'
b'02000000'
b'03000000'
b'04000000'
b'05000000'
b'06000000'
b'07000000'Об оставшейся периферии
Периферия, которую заложили в данный микроконтроллер, достаточно специфична, и всем своим видом дает понять, что не предназначена для широкого применения. По всей видимости данный микроконтроллер задумывался исключительно как конвертер интерфейсов ETH <-> SPI/I2C/UART/PWM.
Выводы
Рассмотрев данный микроконтроллер на практике, можно смело сказать, что он не предназначен для широкого применения повсеместно ввиду своей специфичной периферии. Отсутствие возможности самодиагностики и наличие недокументированных обязательных действий в коде не позволяют использовать его в ответственных приложениях. Однако данный микроконтроллер хорошо себя показал как средство агрегации данных с различных периферийных источников (USART/I2C/SPI) с последующей запаковкой и отправкой по UDP/TCP на компьютер для дальнейшего анализа.
Комментарии (44)
smart_pic
29.07.2021 06:41+1Однако времена шли и появлялось все больше дешевых микроконтроллеров, которые содержали внутри себя MAC уровень, требуя лишь снаружи микросхему PHY. А для ленивых производитель давал готовые решения по интеграции в проект LWIP со стороны софта и демо платы и примеры разводки PHY под свой микроконтроллер со стороны железа. Изредко появлялись чипы с PHY прямо на кристалле микроконтроллера.
Микроконтроллеры PIC18F67J60 и PIC18F97J60 со встроенным PHY появились давно.
PIC32MX795F512L и аналогичные из этой серии с МАС на борту так же появились давно.
Стек протоколов достаточно хорошо описан и документирован, были курсы по применению ТСР стека и данных микроконтроллеров. Информации очень много. Легко сделать веб интерфейс настроек своего устройства и организовать обмен с сервером. А легко ли сделать ВЕБ интерфейс на данном МК? ВЕБ с которого настраивают и управляют устройством?
По всей видимости данный микроконтроллер задумывался исключительно как конвертер интерфейсов ETH <-> SPI/I2C/UART/PWM.
Уже было подобное , называется X-port , даже вмонтированное в разъем RJ45, но не взлетело.
Применение в качестве ETH <-> SPI/I2C/UART/PWM это совсем маленький круг задач.
Если только интегрируют в экосистему Ардуино, может тогда что то получится. Но если будет сложно делать ВЕБ управления своим устройством - то точно никому не нужно.
Данные структуры отличаются от того, что можно составить по документации. Так как в документации множество ошибок.
Признание этого факта , а также совмещение на кристале МК , которые сложно настраиваются, отталкивает от использования данного МК в своих проектах.
Vadimatorikda Автор
29.07.2021 06:53Честно признаться, W7500 мне на глаза попался случайно. Когда я в очередной раз полез за документацией на W5500 на сайт производителя спустя долгое время после последнего использования. Там наткнулся на него.
Микроконтроллеры PIC18F67J60 и PIC18F97J60 со встроенным PHY появились давно.
PIC32MX795F512L и аналогичные из этой серии с МАС на борту так же появились давно.
Стек протоколов достаточно хорошо описан и документирован, были курсы по применению ТСР стека и данных микроконтроллеров. Информации очень много. Легко сделать веб интерфейс настроек своего устройства и организовать обмен с сервером.
Даже не слышал о них. В основном только что "PIC уже мертв". Но, думаю, стоит и с ними поработать для расширения кругозора.
А легко ли сделать ВЕБ интерфейс на данном МК? ВЕБ с которого настраивают и управляют устройством?
Как я и сказал в статье, если нет неприятных ощущений от использования в своем проекте неизвестного, небрежно выглядящего, кода, то можно поднять WEB сервер с HTTP достаточно просто.
Вообще, если бы я просто использовал готовую библиотеку и Keil, то всей этой статьи, по сути, и не появилось бы. Потому что используешь функции, в которых непонятно что творится и достаточно. Если бы применял на работе и были бы сильно сжатые сроки, то так бы и делал. А тут, когда есть возможность разобраться, не стал упускать возможности.
Уже было подобное , называется X-port , даже вмонтированное в разъем RJ45, но не взлетело.
Тоже не слышал. Спасибо. Ознакомлюсь.
Применение в качестве ETH <-> SPI/I2C/UART/PWM это совсем маленький круг задач.
Вынужден согласиться. Я вижу тут дополнительный логгер в flash/eth и конвертер интерфейсов. Еще можно через PWM чем-то управлять.
Если только интегрируют в экосистему Ардуино, может тогда что то получится. Но если будет сложно делать ВЕБ управления своим устройством - то точно никому не нужно.
Сложно будет... В отличии от Arduino (atmega, имею ввиду), тут очень так себе периферия. Но можно и ее хотя бы. Сейчас делать WEB на нем относительно легко с библиотеками. Я только глянул код готового проекта. Но оно... Скажем начистоту. Достаточно медленное. 48 МГц не могут покрыть канал в 100 мегабит. Да и внутри там очень много overhead-а. Копирование вот 1.5 кб части TCP запроса происходит процом, а не DMA. Хотя в это время можно было бы с другого сокета разобрать пакет пришедший. В общем оно требует доведения до ума. Или смириться со скоростью.
Признание этого факта , а также совмещение на кристале МК , которые сложно настраиваются, отталкивает от использования данного МК в своих проектах.
Я его и не защищаю. Я тут тоже пользователь. Можно использовать библиотеку и тогда все станет значительно легче. Она вроде на вид легче чем тот же HAL у ST. Кстати отмечу, что для работы WEB сервера с DHCP очень сильно используется куча. Имею ввиду используется библиотекой. Так что если вам нужно что-то надежное, то все равно придется переписывать...
smart_pic
29.07.2021 08:15+1Так что если вам нужно что-то надежное, то все равно придется переписывать...
Да , многое переписано. В частности сделана возможность работы с ВЕБ которы хранится в программной памяти проца и во внешней памяти. Сделана работа с динамическими переменными для облечения совместной работы над ВЕБ интерфейсом. Выпущено около 5-8 типов устройств небольшим тиражом на PIC18F67J60 и PIC18F97J60 со встроенным PHY . Работают в ответственных местах. В основном конференц залы топ уровня. Выполняемые задачи: организация различных интерфейсов управления оборудованием через ТСР. Веб используется в основном для настройки и проверки работоспособности.
Сейчас уже 8 устройств в серийном производстве на PIC32MX795F512L с очень достойным веб интерфейсом и широким функционалом по работе железа.
Нельзя сказать что "PIC уже мертв" - просто для самодельщиков он был немного дороже. Но для серийного производства разницы в цене практически нет. А сейчас, когда тот же STM стали клепать все кому не лень, появилось много клонов , которые частично совместимы, и стало много сообщений о том что, что то не работает в уже налаженном устройстве. А дальше будет еще хуже по этой части. Что нельзя сказать о ПИКах.
Vadimatorikda Автор
29.07.2021 09:49Да. Подделок PIC еще не видел. STM видел, ATMEGA видел. Про переписанный код. Как понимаю, все закрыто? Посмотреть можно только устроившись в компанию?)
smart_pic
29.07.2021 13:30+1TCP/IP Microchip стек открыт много примеров как с ним работать. Есть уроки с Masters. Дружелюбное сообщество. Так ка вы уже в теме TCP/IP и микроконтроллеров - то проблем совсем не возникнет.
Первоначально можно взять что то готовое и проверить в работе, но что бы сделать под свои задачи - то лучше брать стек 5 версии , он функциональный , стабильный , нет глюков и в нем нет лишнего мусора , который придется вычищать.
Lucky007
29.07.2021 07:27+2Применение в качестве ETH <-> SPI/I2C/UART/PWM это совсем маленький круг задач.
Я бы поспорил с этим утверждением. Огромное количество вполне работоспособных устройств было произведено на ENC28xx.
Вообще, отличие ETH <-> SPI от МК со встроенным MAC только в скорости.
Для грамотно написанных Web интерфейсов скорости SPI будет достаточно.
Vadimatorikda Автор
29.07.2021 09:51Там просто еще сверху свой протокол есть небольшой. Который тоже съедает немного. Ну и ограничение хоть и 80, но я выше 30 проверенных официально не использовал у W5500.
dcoder_mm
31.07.2021 05:44отличие ETH <-> SPI от МК со встроенным MAC только в скорости
BOM и футпринт еще.
Lucky007
31.07.2021 05:50Это понятно, но как раз в этом случае мост зачастую получается выгоднее. Цены на PIC покусываются, и у них много ног, а к SPI можно подцепить любой недорогой МК с небольшим количеством ног.
smart_pic
31.07.2021 06:29+1С этим не соглашусь . Цены на ПИКи меньше чем цена вашего любимого мк и той же ENC. PIC18F67J60 в tqfp корпусе места занимает немного. Проще разводка платы.
Вот пример универсального моста RS232 RS485 и ИК управления. Размер платы 70х45мм.
Не хочется разводить холивар, но с предвзятым отношением к ПИКам имеет место быть.
Автору - респект. Проделал работу , оценил работу W7500 , сделал обзор . Теперь когда нужно будет выбирать - то уже есть информация. И автор прав МК нужно выбирать под решаемые задачи для обеспечения функционала и надежности изделия в целом.
Lucky007
31.07.2021 07:19Предвзятого отношения к ПИКам нет. Возможно не совсем адекватные сейчас цены, но розница : PIC18F67J60 = 500р KSZ8851 = 200р плюс любой МК 100р
Насчёт компактности:
Это китаец с KSZ8851 и Atmel на борту. Оба чипа производства Microchip.
smart_pic
31.07.2021 08:00Возможно не совсем адекватные сейчас цены,
Но это розница. В серии при заказе на фабриках Китая, ПИКи выросли в цене меньше STM. Недавно столкнулись при начале производства нового изделия.
Вот аналогичные https://www.olimex.com/Products/PIC/Development/PIC-MINI-WEB/
Есть даже вмонтированные в корпус разъема DB25 https://www.chipdip.ru/product/pic-micro-web
Lucky007
29.07.2021 07:16+2Есть более дешёвый вариант платы на Али на W7500 с внешним PHY. Ищется по "FS100P" https://a.aliexpress.com/_ASERZ6
Vadimatorikda Автор
29.07.2021 09:52Компактно, на видел. Но я особо и не искал. Гуглил сразу со встроенным. Спасибо)
usa_habro_user
29.07.2021 09:52+2Я понимаю, что продвинутые парни легких путей не ищут, но, все-таки, почему не копеечный ESP32, который еще N лет назад, заработал у меня out of box без единой проблемы, и до сих пор который я использую "за все про все" (благо, закупился "по дешевке" на али в свое время)?
Vadimatorikda Автор
29.07.2021 09:54Как я писал в статье, просто для расширения кругозора и строчки в перичене МК в резюме. Про ESP32. Очень не люблю, когда нет возможности все сделать на регистрах без закрытых библиотек. Это касается как домашних проектов, так и ответственных на работе. Если делать что-то, от чего не зависит жизнь-здоровье и поломка или перезагрузка чего не принесет большой проблемы, то почему бы и не использовать с закрытым кодом)
usa_habro_user
29.07.2021 21:44Сорри, поясните на счет "закрытого кода": я использую ESP32, обычно, на базе платформы Arduino (хотя есть и другие варианты), а там все, по моему, совершенно открыто, включая и сторонние библиотеки - они по умолчанию поставляются с открытым кодом (AFAIR, по иному и работать не будут, вроде).
Поймите меня правильно, я вовсе не "придираюсь" к вам и не "занудствую", просто пытался понять, что сподвигло на освоение достаточно "нестандартного" МК/SoC. В свое время ESP32 меня очень приятно удивил, предоставив кучу рабочей (притом, на production level) функциональности, доступной "прямо из коробки", без "плясок с бубном": тут тебе и BT/BLE, и WiFi, и WiFi Direct, и еще целая куча всего - просто бери и используй. Лично мне в домашних проектах интересно добиться задуманного минимальным путем, не "заморачиваясь" на очередное "изобретение велосипеда" (изобретенного уже несколько миллионов раз).
P.S. Когда-то, на одном из моих контрактов, весьма "не маленькая" компания разработала для компании, на которую я работал, BLE дивайс ("умный гаечный ключ"), притом, естественно, "профессионально" - микроконтроллер на своей PCB, bare metal firmware, свой BLE stack - в общем, все, как положено. Господи, сколько пришлось несчастному разработчику этого firmware трудиться, чтобы их изделие работало "гладко" с BLE стеком Win10! Реализация крохотной фичи занимала у него недели, но всегда что-то было не то, не работало все smooth. Смеха ради, я заменил их PCB (на "бракованном" smart wrench) на копеечную esp32 dev board, и написал код, делающий то-же, что и его, буквально за пару дней - все заработало супер-дупер прекрасно, все наши issues (с оригинальным firmware) исчезли в момент...Vadimatorikda Автор
30.07.2021 05:52+1В своих проектах стараюсь пройти все круги ада. Потому что потом на работе мне становится намного легче работать.
Этот чип я выбрал просто для ознакомления. Цели просто решить задачи не было.
В свое свободное время я стараюсь изучать как можно больше разных мало кому известных архитектур и решений в целом. Вдруг среди них найдётся наиболее подходящее решение под проект, который мы будем делать в следующий раз.
А теперь про esp32. У нее закрытый ble и wifi стек. Не очень хорошая документация на периферию в уровне регистров и специфичные средства разработки. Использовать данный SoC в продакшен я не позволю. Почему? Часть причин описал выше. Но есть еще.
Сроки поставки и надежность производителя не ясны.
Нет возможности в случае ошибки в библиотеках оперативно починить.
Не определено время гарантированной поддержки.
Крупные разработчики обычно гарантируют 5/7/10/15 лет поддержки своих микроконтроллеров. Некоторые уже реально более 20 лет поддерживают. А этот чип пока что остается на «поиграться».
usa_habro_user
30.07.2021 06:21Я с вами не соглашусь; аргументы, что вы привели, не очень убедительны (для меня, по крайней мере):
И разработчик, и производитель - вполне себе надежные и авторитетные компании (если вас не смущает по какой-то причине тот факт, что они из Китая).
Думаю, что вы в этом пункте ошибаетесь; с другой стороны, популярность чипа и активно ведущаяся открытая разработка - хорошая гарантия отсутствия критических ошибок.
Тут я точно сказать не могу, но можно связаться с представителями https://www.espressif.com/ и выяснить, как обстоит вопрос.
Мне кажется, "за вас" говорит обычная для профессиональных "микроконтроллерных" разработчиков неприязнь к "ардуинщикам" ;) Но esp32 вовсе не обязательно использовать, как advanced Arduino, они много чего поддерживают.
Vadimatorikda Автор
30.07.2021 07:33+1И разработчик, и производитель - вполне себе надежные и авторитетные компании (если вас не смущает по какой-то причине тот факт, что они из Китая).
Для меня порог 10 лет. После прохождения 10 лет я начинаю закладывать в устройства прошедшей порог фирмы микроконтроллеры. То, что она в Китае, не страшно. Опять же при условии, что есть надежные поставщики. То есть, тот же Элитан должен их поставлять.
Думаю, что вы в этом пункте ошибаетесь; с другой стороны, популярность чипа и активно ведущаяся открытая разработка - хорошая гарантия отсутствия критических ошибок.
Вы, неверное (могу ошибаться) не разрабатывали оборудование, которое требует сертификации или используется там, где может быть причинен вред здоровью или жизни человека. В таких проектах обязательным условием ставится наличие полного перечня документации на всю внутреннюю подноготную. В особо тяжелых случаях требуется даже проверять внутреннюю структуру чипов на соответствие заявленного. Именно тут появляется Миландр и остальные российские микроконтроллеры (которые обязуются гарантировать то, что продают и заявляют в документации).
Тут я точно сказать не могу, но можно связаться с представителями https://www.espressif.com/ и выяснить, как обстоит вопрос.
Тут обычно решается вопрос через поставщика. Дается "приватные" контакты и через них уже идут все уточнения. Не только в российских компаниях.
Мне кажется, "за вас" говорит обычная для профессиональных "микроконтроллерных" разработчиков неприязнь к "ардуинщикам" ;)
Буду откровенен. Неприязнь есть. НО. Рациональность важнее. Если проект выглядит идеально с Arduino внутри, то я ее поставлю. Пример: есть мелкосерийная партия ДВС-ов для мелких аппаратов. Внутри контроллер ДВС на открытом Arduino проекте. Оно не плохо так продается. То есть процесс интеграции выглядил просто как разводка платы под нужные габариты, смена пара ножек в коде, а далее уже все ок. Хотя у Arduino есть весомый плюс над ESP32. Он на AVR. А на AVR чипы есть исчерпывающая документация. Так что даже если что-то в библиотеке или проекте бы пошло не так, то можно залезть и посмотреть, почему. А в случае с ESP, если есть ошибка в модуле, на который нет исходников (например, на дергается нужный бит. Или флаг прерывания не сбрасывается при каких-то условиях), то ты единственное что можешь сделать, так это написать разработчикам с просьбой разобраться в произошедшем.
usa_habro_user
03.08.2021 07:16Для меня порог 10 лет.
Ну, это, Вы, батенька, по-моему уж чересчур! Для космоса/военки/медицины - возможно, но для большинства применений - overkill. За 10 лет семейство микроконтроллеров может родиться, пережить успех, и кануть в Лету...
Вы, неверное (могу ошибаться) не разрабатывали оборудование, которое требует сертификации или используется там, где может быть причинен вред здоровью или жизни человека.
Довелось писать фирмварь и фронтэнд для medical devices; да, там я, естественно, не выбирал платформу, и "плясал, от того, что дали". Но в не таких критичных application, по моему, вполне допустимо использовать "массовые" дешевые контроллеры. Чтобы не быть голословным, приведу небольшой пример: довелось мне как-то, лет 15 назад, сотрудничать с одной небольшой компанией, производящей ну очень sophisticated оборудование для астрономов (в данном случае, речь шла про обсерватории в Аресибо, печально известным по последним новостям). Компания разработала несколько high-tech "примочек", притом "компанейский" электронщик был на уровне домашнего любителя, и задизайнил все на... Basic Stamp (это то, что пришло чуть раньше Arduino - PIC в "юзер-френдли" обертке). И, что Вы думаете? Хотя, конечно, в силу ограниченности этого Basic Stamp-а мне пришлось вспомнить совсем уж старые "спектрумовские" времена, тем не менее, как-то, да наваял(и), и рулит этот крохотный "самоделочный" контроллер мощными сервами, и всяческими прецизионными дивайсами и сенсорами, уже более пятнадцати лет (намедни владелец фирмы звонил, приглашал по старой памяти на барбекю, и упомянул заодно, что все работает).
Моя "наивная мечта", с которой я постоянно пристаю к одному знакомому бизнесмену, занимающемуся ребрендингом и ритейлом, и имеющему отличные контакты в Китае - это продавать гаджеты "двойного назначения" в Штатах, базирующиеся на стандартных китайских ESP32 dev board и прочей совместимой периферии. Т.е. купив гаджет, скажем, за $30, пользователь мог бы легко его разобрать (если надоел), и продать "запчасти" на $20+, или использовать в своих проектах. При "мелкооптовом" производстве в Китае это вполне достижимо, я просчитывал (опять-таки, считая по американским retail ценам на parts, на Amazon и eBay). Например, вот такой вот проект.Vadimatorikda Автор
03.08.2021 07:33Для массового применения без последующих обновлений можно хоть 4-хбитки лепить... Я просто работаю там, где требуется долгая поддержка. В районе 10 лет. И там важно. Ну и речь про авиацию. Так что увы.
А вот на фрилансах я даже ESP8262 закладывал. Было норм. 1 раз выпустили и все)
Про переделку и продажу деталей. Чем они более широкого уровня, тем дороже и габаритнее. Так что врят ли. С другой стороны, сейчас материнки на те же телефоны и так продают как один компонент.
usa_habro_user
03.08.2021 07:57Ну и речь про авиацию.
Ну, если про авиацию - то тут все понятно. Но, by the way, боюсь, что "10 лет как минимум" с рассматриваемым в Вашей статье SoC никак не увязываются ;)
Так что вряд ли.
Вы поленились ткнуть в линк, ну, да Бог с ним! Идея в том, чтобы, продавая готовый продукт (гаджет: "магический шар", робота, name whatever you want), продавать и возможность повторного использования деталей. Грубо говоря, у вас есть возможность либо купить, по отдельности, esp32 dev board + LCD display + speaker + mp3 board + sensor + battery holder за $50 total по отдельности, или же купить все в сборе (но с возможностью легкого "разбора") за $30.
Vadimatorikda Автор
30.07.2021 06:00Теперь про то, что вы реализовали функционал намного быстрее, чем программиста, который писался сам. Тут есть один нюанс. Тот программист, который писал все это сам, если написал все правильно, то оно будет надёжнее, и поддерживать это будет проще. Такой подход я одобряю. Да, он дольше по времени. Да, он выходит дороже. Однако. Такое устройство можно будет поддерживать, на протяжении всей жизни проекта. Или пока не закончится поддержка чипа, на который был построен проект.
Опять же, напомню. Что данный чип, который вы так любите, неплохой. У него просто своя область применения. Он прекрасно себя зарекомендовал как средство для прототипирования. Также, как Arduino. Он прекрасно подходит для того, чтобы собрать хоть какой-то более-менее работающий прототип в короткие сроки. С этой задачей он справляется прекрасно. Но использовать его вместе с его экосистемой в реальных устройствах нельзя.
Однако, если нужно выпустить устройство, поддержка которого ограничена выпуском начальной прошивки, а дальнейшая судьба проекта не важна, или поддержка будет производиться очень на коротком сроке, при этом устройство не представляет опасности для жизни человека, тогда применения данного чипа, будет весьма оправдано.
usa_habro_user
30.07.2021 06:33Вы, видимо, неправильно мой пример поняли, ну, или я плохо объяснил. Там дело и состояло именно в том, что был выбран неподходящий контроллер, много "велосипедного" кода разработчику пришлось писать самому. Понятно, что "все мы человеки", и даже "изобретая велосипед", пусть и по всем спекам, можно допустить ошибки.
Собственно, для чего я сделал тогда свое демо: только для того, чтобы показать, что утверждения разработчика о "глючной Windows" и "некорректной имплементации стека BLE" не имеют под собой оснований. И ему (точнее, компании), "скрепя сердце" пришлось искать и фиксить баги в своем коде. Да, когда мы запросили фичу апдейта фирмвари OTA, они нам дали estimate в $200K и 6 months. Я на своем демо esp32 реализовал эту фичу за один день, включая и PC-app hosted part (т.е. решение под ключ).
Правда, могу откровенно доложить, все это было, в конечно итоге... до "оппы" - на самом деле, никому не было до этого никакого особо дела (поскольку бабки и время тратились не их, а огромной транснациональной корпорации). Вот так обстоят дела в "развитом капитализме" :D
Vadimatorikda Автор
30.07.2021 07:40Вы, видимо, неправильно мой пример поняли, ну, или я плохо объяснил. Там дело и состояло именно в том, что был выбран неподходящий контроллер, много "велосипедного" кода разработчику пришлось писать самому. Понятно, что "все мы человеки", и даже "изобретая велосипед", пусть и по всем спекам, можно допустить ошибки.
Да, я вас не так понял. Если чип был выбран неверно, то это уже другой диалог. Часто вижу картину, когда вместо специально спроектированного под задачу чипа ставят какой-нибудь stm32f415. Просто потому что на нем все делали. Иногда это прокатывает с небольшими издержками. Иногда все оканчивается плачевно.
Собственно, для чего я сделал тогда свое демо: только для того, чтобы показать, что утверждения разработчика о "глючной Windows" и "некорректной имплементации стека BLE" не имеют под собой оснований. И ему (точнее, компании), "скрепя сердце" пришлось искать и фиксить баги в своем коде.
Ошибки и глюки вполне могут быть. Все же проекты тяжелые. BLE стек вообще считается самым тяжелым вроде как из существующих. Даже тяжелее WiFi. Но ошибки обычно на твоей стороне) Так что да.
Да, когда мы запросили фичу апдейта фирмвари OTA, они нам дали estimate в $200K и 6 months.
А вот такое надо еще на этапе планирования проекта выяснять. Если есть что-то закрытое внутри от производителя, то все может пойти по п***е. Сталкивались с таким. Было неприятно. Пришлось чип менять. Зато "сэкономили" и "не потратили время" на написание своих драйверов. Зачем? Ведь у производителя есть готовое...
Правда, могу откровенно доложить, все это было, в конечно итоге... до "оппы" - на самом деле, никому не было до этого никакого особо дела (поскольку бабки и время тратились не их, а огромной транснациональной корпорации). Вот так обстоят дела в "развитом капитализме" :D
Это тема отдельной дискуссии...
smart_pic
30.07.2021 09:56Часто вижу картину, когда вместо специально спроектированного под задачу чипа ставят какой-нибудь stm32f415. Просто потому что на нем все делали.
Да , такое часто и густо.
usa_habro_user
03.08.2021 07:32А вот такое надо еще на этапе планирования проекта выяснять.
"Надо" - хорошее слово! :) Но, зачастую, все работает несколько иначе; в приведенном мной реальном случае (хоть это случилось до моего прихода в компанию, но всю историю я знаю досконально) было так:
молодой энергичный "эффективный менеджер" огромной транснациональной корпорации, переброшенный на проект и весьма далекий от IT вообще, не говоря уж про "железо" и технологии, консультируется у знакомого "шо почем", и тот говорит ему, что "BLE is modern & cool, trending stuff now"
заглянув в свой iPhone последней модели, он убеждается, что это правда: слова RfComm он найти не может, а вот BLE - пожалуйста!
он звонит в чуть менее огромную американскую корпорацию, производящую оборудование, и договаривается о том, чтобы "сделали BLE вместо RfComm", типа not a big deal...
в огромной американской корпорации на разработке дивайсов с RfComm (других до этого у них просто не было - "работает - не трогай!") сидит маленькая команда из электронщика и программиста; им ставят задачу "точно такой-же, но с перламутровыми пуговицами", и добавляют: "это не должно занять у вас много времени - проект-то небольшой, меньше "лимона" - так, что используйте старые наработки!"
и они стали "использовать старые наработки", ваяя BLE стек чуть-ли не по white papers со всем сопутствующим etc. & so on.
Vadimatorikda Автор
29.07.2021 09:56Ну и в домашних проектах я люблю "лезть в бутылку". И заниматься "байто*бством". Мне просто нравится. На работе же делаю все ровно на том и так, как это требует ТЗ, в котором указана степень ответственности проекта, срок поддержки и прочие важные параметры.
smart_pic
29.07.2021 13:35вот ссылочка на X-port . все уже вмонтировано в разъем https://www.lantronix.com/products/xport/
Vadimatorikda Автор
29.07.2021 14:17По комментарию выше уже нашел. Но пусть здесь будет для полноты картины.
Lucky007
29.07.2021 15:25+1Вообще, недорогих решений МК+PHY в одном корпусе очень мало. По PIC - ценник далеко не гуманный.
Сейчас с развитием IOT такие решения были бы востребованы.
Сам до этого применял связку stm32f107+RTL8201.
Сейчас присматриваюсь к KSZ8851+любой МК, и esp32+PHY.
Прошу поделиться, если есть недорогие решения для непотокового LAN.
smart_pic
29.07.2021 15:36использую для сложных проектов PIC32MX795F512L +LAN8720QFN24
для простых конверторов протоколов типа TCP-RS232, TCP-RS485, TCP_IR использую PIC18F67J60 и PIC18F97J60 со встроенным PHY. Вполне подходит для добавления управления по ТСР в тех девайсах, где раньше был RS232, RS485, IR.
получается очень компактно
lolikandr
29.07.2021 23:39+1Тестировал HTTP сервер на W7500P (выделил для http 6 сокетов [6 read и 6 send], обработка стейт-машины соектов в httpServer.c не модифицирована) - иногда по какой-то причине сокет закрывается дольше, чем появляется соединение с новым сокетом. В момент загрузки одной страницы в браузере - количество параллельно незакрытых сокетов достигало 4-ёх. Если одновременно открывается страница в дугом браузере, а ещё идёт обработка AJAX запросов - то не закрытых сокетов становится 6 и новые запросы от браузера падают в большие TCP таймауты до 1..2 сек. Пришлось собрать все js и css в два обобщённых js и css файла, хоть немного, но помогло.
Субъективно со скоростью WEB интерфейса всё хорошо (пока не выстреливают вот такие внезапные задержки, которые портят впечатление).Vadimatorikda Автор
30.07.2021 05:44А вы выводы после инициализации модифицировали? Там в errata есть как раз проблема с 700 мс ping-ом. Решается доработкой инициализации выводов.
EGregor_IV
30.07.2021 10:39+1В 2014 году использовали в своих приборах W7100. Это тоже самое, что W7500, но с 51-ым ядром. Глюков не было. Использовали в качестве многопортового полудуплексного шлюза с RS485 в LAN. Хотя были ньюансы в виде допрегистров для копирования данных между участками памяти. Эдакий аппаратный memcpy. Ну и еще какие-то штуки были, не помню уже. Но штука была простая и прошивалась через СОМ-порт.
Lucky007
В даташите по SysTick : "Clocked internally by the system clock or the system clock/2."
Vadimatorikda Автор
О, спасибо. Не нашел сам. В документации на W7500P вообще сказано, что даже без этого бита идет на systic CPU_CLK/8. Что, как выяснилось, неправда.
Vadimatorikda Автор
А можно ссылку на документ?
Lucky007
https://docs.wiznet.io/img/products/w7500/w7500x_ds_v110.pdf
Vadimatorikda Автор
А... Это в основном datasheet было... Я его мельком проглядел и далее только с reference manual работал. Буду внимательнее. Спасибо)