STM Урок 129. LAN8742A. LWIP. NETCONN. HTTP. WebSocket. Часть 4



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

Вспомним нашу табличку с описанием байтов протокола.

Если нам нужно передать данные до 125 байт, то младшие семь бит второго байта (а правильнее байта 1) будут содержать длину нашего фрейма, если нам надо передать фрейм длиной от 126 до 65535 байт, то тогда младшие семь бит байта 1 будут иметь значение 126. Тогда следующие два байта (2 и 3) будут содержать длину фрейма (причём старший бит будет бит 2, а бит 3 — это младший бит длины фрейма). Но, а если вдруг нам будет нужно передать фрейм длиной от 65536 до практически бесконечности (длина ограничивается размерностью 64-битного числа), то мы значение семи младших бит байта 1 объявляем 127, тогда следующие уже не 2, а восемь байт и будут содержать длину нашего фрейма. А дальше всё, как и было. После поля длины фрейма у нас пойдут наши данные, если, конечно, не объявлена маска. А если объявлена маска, то пойдёт маска 4 байта, а дальше уже пойдут байты, обработанные этой самой маской.

Вернёмся в наш бесконечный цикл и узнаем, а не превысила ли длина нашего будущего сообщения значение 125, и если она не превысила данное значение, то мы тогда в байт 1 заносим значение длины, не обращая внимание на бит маски, так как у нас её не будет, а затем уже, начиная с байта 2, положим в наш буфер список задач (уже по-настоящему). Потом, используя функцию сортировки, отсортируем наш массив с задачами и их свойствами и передадим весь наш фрейм клиенту. Мы здесь не проверяем тип фрейма, запрошенного клиентом, потому что если будет тип 2, то мы точно знаем, что он у нас больше 125 и в это тело условия он не попадёт

 

 

Далее добавим условие, которое сработает, если длина наших данных будет от 125 до 65536. В таком случае мы заносим в байт 1 значение 126, укладываем длину фрейма в байты 2 и 3, если тип фрейма у нас 1 (текстовые данные), то уже начиная с байта 4 мы укладываем список задач, потом их сортируя, и отправляем наш фрейм клиенту. Мы помним, что если у нас фрейм бинарный, то наши байты там уже лежат

 

Теперь мы отправили клиенту все данные.

Вроде бы здесь всё.

Теперь идём в index.html, где в функции обработки кнопки для старта текстовой информации startstring добавим ещё событие объекта, которое сработает в тот момент, когда придут данные

 

Попробуем пока, как будет работать передача списка задач (так как у нас ещё в index.html ничего ещё не сделано для кнопки под графиком).

Сохраним страницу, перегенерируем fsdata.c, обновим дерево проекта, пересоберём код и прошьём контроллер, после чего обновим страницу в браузере и снова нажмём на нашу верхнюю кнопку START

Мы видим, что у нас всё работает.

Посмотрим также процесс в анализаторе трафика

Мы видим, что пакеты приходят регулярно и клиент у нас их не запрашивает, он лишь подтверждает приём пакетов TCP.

 

 

Осталось нам только увидеть, как приходят данные бинарного типа и отобразить их в графике.

Остановим цикл с помощью кнопки STOP, закроем наше соединение с помощью кнопки Disconnect и идём опять в наш index.html работать уже с графиком. Сначала в функции-обработчике окончания загрузки документа инициализируем наш график аналогично тому, как мы делали в прошлом уроке

 

Добавим функцию-обработчик нажатия на вторую кнопку START

 

В данной функции мы опять назначаем тип бинарных данных в arraybuffer, превращаем кнопку START в STOP, кнопку START для текстового поля убираем, а также добавляем обработчик открытия сокета, в котором мы создаём объект типизированного 16-разрядного массива, где мы в качестве аргумента передаём пришедшие данные, а затем присваиваем наш массив полю данных графика. По окончанию не забываем обновить график. И также мы посылаем для запуска цикла серверу двоечку.

Также добавим функцию кнопки STOP для графика

 

Здесь мы уже передаём четвёрку и также возвращаем наши кнопки START обоим полям.

Проверим наш код в работе. Обновим fsdata, дерево проекта, соберём код, прошьём контроллер, перезагрузим страницу и понажимаем на наши кнопки, особенно нам интересен график (нажмите на картинку для увеличения изображения)

Мы видим, что всё у нас прекрасно работает.

Также посмотрим трафик в Wireshark

Здесь мы также видим, что пакеты идут в основном только от сервера. От клиента мы видим одни лишь подтверждения. Их бы тоже почти не было, если бы мы могли себе позволить буфер побольше.

Попробуем также убавить задержку в функции до 100 милисекунд. Мы видим, что в этом случае также всё успевает передаваться. Вы можете поэкспериментировать у себя с меньшими задержками. Напишите в комментариях, кому какую удалось установить задержку без потери работоспособности сокета.

Итак, сегодня мы научились очень многому.

Во-первых, мы освоили передачу данных с сервер в браузер клиента посредством технологии WebSocket, что позволило нам также обойтись без перезагрузки всей страницы, а также мы теперь можем передавать потоки данных без запроса клиента.

Во-вторых, мы научились использовать внешнюю память для хранения массивов, что позволило нам сэкономить внушительный объём памяти.

Всем спасибо за внимание!

 

 

Предыдущая часть Программирование МК STM32 Следующий урок

 

Исходный код

 

 

Отладочную плату можно приобрести здесь 32F746G-DISCOVERY

 

 

Смотреть ВИДЕОУРОК (нажмите на картинку)

 

STM LAN8742A. LWIP. NETCONN. HTTP. WebSocket

3 комментария на “STM Урок 129. LAN8742A. LWIP. NETCONN. HTTP. WebSocket. Часть 4
  1. файл 'makefsdata.cmd' правильнее сейчас такой (из-за новых версий 'CubeMX'):
    makefsdata.exe -11
    ren fsdata.c fsdata_custom.c

  2. sunilvigneshnehru:

    Hi,
    I am trying this NETCONN_WEBSOCKET in NUCLEO-F746ZG. I am able to load the index page in static IP. but when i press connect button receive an message «соединение закрыто некорректно код: 1006»

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*