rPman, ага, прямо не пишут. но легко определить по размеру кэша. если 128 МБ и больше - то с большой вероятностью SMR. если больше 1.5 ТБ 2.5" - SMR. Терабайтники на грани, могли засунуть два блина. Но здесь 7мм, а значит один блин и тоже SMR
А может вы и правы, я ориентировался, что современные диски хорошо разруливают фрагментированное чтение с помощью очереди запросов - и диск их обрабатывает в хитром порядке, минимизируя движение головки. Но в данном случае диск внешний и этот механизм может не работать. Дополнительно Windows периодически делает дефрагментацию диска в ночное время, но опять же, при эксплуатации диска во "внешнем" режиме это не катит
rPman, фрагментация тоже вносит свою лепту, но я всё же считаю, что основной эффект в тормоза при работе диска в данном случае даёт именно SMR и длительность процедуры записи.
lonely_rocker, включите Wireshark с USBPcap, смотрите что на самом деле гуляет по шине при исполнении вашей программы. В идеале найдите программу, которая общается с этой камерой и запишите трафик. Там будет видно, на какой EP что отправлять. Ещё можно посмотреть перечень эндпоинтов и их тип, по крайней мере для Windows были утилиты для этого. Перебирать значения это как-то непродуктивно
korobka026, разработать скрипт для tampermonkey. если вы не умеете программировать, можно на фриланс бирже заявку оставить и оплатить работу программиста. готового решения вы вряд ли найдете, если сайт не мегапопулярный
Treeesk, решайте проблему с другой стороны, если recv вернул 0, значит, клиент закрыл сокет и данных больше не предвидится, его остаётся только закрыть, нет смысла это игнорировать и ждать дальше данных
- замеряете сколько тиков тратит в нуле
- замеряете сколько тиков тратит в единице (например, тем же самым своим кодом, только предварительно активировав на GPIO входе инверсию сигнала)
- делаете замеры одного и другого N раз для усреднения
- складываете вместе и вычисляет частоту
увы, чем больше частота, тем данный подход будет менее точен. поэтому Frequency Counter
именно его и пытался реализовать
то есть ждем 1, потом 0, и ждем как раз пока снова 1 не станет
ага, но считаете вы только пока оно в нуле. таймер не тикает, пока клок в единице
не совсем понял только почему изза согласования уровней в 0 он может проводить больше времени(
потому что допустим у вас ардуинка имеет 5 воль уровни, у RPico уровни 3.3в, и когда линию колбасит от 5в до 0в туда-сюда, пика считает логической единицей всё, что больше 1.5в (примерно), если близко к синусоидальному графику на выходе, то время "ниже 1.5в" будет меньше, чем "выше 1.5в", вот и проблема с замерами
вы хотите потренироваться в программировании PIO? если вам именно частоту посчитать нужно, в Raspberry Pico есть отличный аппаратный модуль счётчика частоты (см даташит, Frequency Counter). заводите ваш сигнал как CLOCK GPIN, настраиваете счётчик и получаете охренительную точность в 62.5 Гц при замере в 32мс
