Результаты поиска

Вы не на этом пишите? https://threejs.org/ Хотелось бы прилепить к UBIA в WebBluetooth или записать в смарт-часы что-то примерно аналогичное... А то выводить просто графики не очень прикольно, а в случае со смарт-часами и паять ничего не требуется...

Она системная, а не пользовательская. Нагружена система, а не типа CPU не успевает... MQTT имеет много переключений контекста и прочих семафоров. Система и занята этим обслуживанием и ей не до ваших других задач. Иначе от куда намеряли 250 ms на запрос-ответ? Что там процу с многими ядрами на...

Нету такого ограничения. Оно искусственное, наведенное от ST. У TLSR8266 CPU вообще тормоз. Работает с кеша в RAM, в который программа поступает с SPI Flash. Т.е. примерно на порядок медленнее чем STM32F103. Но без проблем прокачивает более 400 килобайт в USB-CDC. При этом у него USB не...

Таков ужас архитектуры аппаратуры устройств от ST. Всё обрезано до предела - типа жалели каждый кубический нанометр из песка :)

Я про это и говорю - у STM своя фича. Всё равно на нем работают через HAL, а быстрее он не могет. По этому наверно и ограничили. Да и у младших нету 2к буферов, если всё писать по классике... И про скорость самого CPU тоже всё давно расписано - cortex для полного USB2.0 надо более сотни MHz.

Причину можно лехко описать – пока выполняется великий и неспостижимый деоптимизированный на байты машинно писанный калбак от AdHoc host уже начнет тормозить, т.к. ему нужон ответ в fifo usb поинта… И так-же всем известно, что работа даже с GPIO через HAL ST тормоз в более чем в 10 раз от...

Если следовать рекомендациям креативного клоуна про его калбаски и HAL от ST, то USB у STM32 вообще превращается в UART c 9600 бод как максимум.

В итоге throughput USB1.1 стремится к 800 кило/сек, а не как при использовании AdHoc - 1..2 кило в сек :) А из-за тормозов самого MCU трафик падает к 400 кило/сек. Особенно падает при HAL STM32.

Нормально передавать до 2048 байт (32 блока). Больше уже не столь выгодно... далее на скорость сильно не влияет в USB1.1, который только и есть у STM32... FIFO у чипов на мамке всё равно больше - за 4 кило.

У STM "своя драйвера" и ничего об этом не знает... В итого часто ограничено трафиком в 64*1000 байт...

Так-же сам драйвер от MS гонит сразу 256 байт (4 блока) и по подтверждениям угадывает - могет ли ваше устройство это сожрать.

Т.е. при получении 64 байт драйвер ожидает что будет ещё блок и ему необходимо передать или нулевой завершающий блок или блок с данными отличными от 64 байт. В итоге блок на уровне выше ограничен размером fifo у USB чипа, но передается пачками по 64 байта. Прям как в BT4.2 при указании MTU более...

64 - это самое неоптимальное. При передаче/приеме блока в 64 байта передается 2 блока - один в 64 байта, второй в 0 байт, который указывает что прошлый блок в 64 байта является законченной передачей. Если передали 63 байта, то этого не происходит. Вроде это фича от MS при CDC. В других классах...

Ух ты... Для AdHoc уже оказывается нужно своё железо. Приплыли...

Как минимальными ресурсами сделать доступным устройство c современной OpenWRT в местной интрасети по имени для Windows? Т.е. нужен демон NetBios и LLMRN. Я давно писал такой для IPv4, но пока не ведаю что там надо для IPv6 и как его проще уведомлять в СИ о смене IP в интрасети. Ещё надотъ...

Креативный клоун обещал описать сферу применения AdHoc. Но, как оказалось, что в современном мире её просто нет, кроме как игры в эту игру. :P

По настоянию креативного клоуна следующим этапом будем дописывать SSD побайтно, чтобы он побыстрее перешел в режим read-only :) И c USB мы тоже не будем оптимизировать блок на размер передачи и на USB2.0 получим великий трансфер в AdHoc до 1000 байт в сек...

Ждем элементарного примера сравнения скорости передачи и получения простого текстового файла через AdHoc и сжатого пусть gzip. Так само собой давно происходит в простом HTTP. Когда это продемонстрируете, тогда и пишите что у ваш протокол является скоростным :) А до этого ваша комкание в 8 бит...

Вам уже давно указали, что по безграмотности вы пишите какую-то абстракцию не применимую на практике. Не учитывая даже минимальную теорию, а гоня отсебятину про какие-то "байты". Обычно это называют игрой или забавой. Забавляйтесь дальше сами, пока не осмыслите указанное.

И уж лучше вы нам расскажите, как современный проц будет вычитывать байт по своей шине в сотне бит :) Если не смыслите в технике, то плодите свой overhead дальше... Он у вас на каждом этапе и минимальной команде кода AdHoc. Выкиньте фразу про скорость из своего AdHoc и добавьте - самый тормозной...