Этого не может быть потому, что этого не может быть никогда.
Давайте посчитаем. нужно принять 50 символов (50x8 = 400 бит). Скорость у Вас 115200 бит/сек. Делим первое на второе: 400 / 115200 = 3,47 мс. Так что, 3,5 мс, а никак не 4-9.
И никак по-другому. Вы не можете замедлить приём (например, своим медленным кодом), потому, что UART – ненадёжный протокол, связь идёт без подтверждений, и передатчик будет фигачить на той же скорости независимо от того, успевают его принимать или нет.
Не, мне это трудно понять. Опишите качественно, если не сложно, последовательность движений групп лап при перемещении боком.
enum State {WaitSync, RecvBytes, WaitStartRcv, …};
switch(State)
case WaitSync: if(B==Sync) State++; break;
case RecvBytes: …
case WaitStartRcv: …
отакота примерно ждем в прерывании. Без петель ожидания, разумеется.
Зачем?
“ахаха. проверили на CRC да и дело с концом.”
там два буфера аппаратный на 1 байт, программный как и ожидалось на 16, 115200 это на аппаратном, а какова фактическая надо бы измерить
ЗЫ нету у меня нано, но было бы интересно
это вы про время приема, а я про выполнение метода get() целиком. Во-первых прием начинается не всегда с старт-символа, во-вторых после приема вычисляется хеш
Не мудрствуйте лукаво. Аппаратура фигачит на указанной скорости. Если Вы начнёте “принимать медленнее” – она Вас ждать не будет и Вы ничего не примете. А уж сколько там у Вас буферов, это Вы на досуге внукам расскажите.
тут малость проперся (второй цикл в методе get()) вместо receiverByteTreshold должно быть byteTreshold, да и вообще у receiverByteTreshold немного неудачное название…
Вы простите, кто по специальности? Журналист? Ещё какой гуманитарий? Просто, в моём окружении принято считать, что фраза
означает именно “длительность чтения равна 4-9 мс”, а не что-то другое. Если Вы будете читать так долго, Вы ничего не прочитаете, т.к. читать надо со скоростью передачи и никак иначе.
Если же Вы имели в виду что-то другое, так это другое и надо говорить. Учитесь говорить понятным техническим языком. – Вас не понимают. Кстати, сейчас заметил, что я не первый, кто обратил на это внимание. Делайте выводы.
то-есть со скоростью большей скорости передачи читать нельзя?
Читать порт - нет, а буфер - хоть на 100500МГц.
а функция Serial буфер и читает и открою секрет и пишет туда жеж, в программный буфер
#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif
#if (SERIAL_TX_BUFFER_SIZE>256)
typedef uint16_t tx_buffer_index_t;
#else
typedef uint8_t tx_buffer_index_t;
#endif
#if (SERIAL_RX_BUFFER_SIZE>256)
typedef uint16_t rx_buffer_index_t;
#else
typedef uint8_t rx_buffer_index_t;
#endif
Нк, если начать пикироваться, то функции Serial в Wiring не существует.
Смотрите, у нас есть возможность лапу ставить в любую достижимую для нее точку в пространстве (сообщение 124 последний блок с кодом). Вы как бы в условном центре такого пространства круг на полу рисуете и лапа внутри этого круга может от края до края “царапать” поверхность, причем всегда проходя церез центр. Вы можете так царапать в любом направлении: поставили на окружность, царапнули до противоположной стороны (по диаметру получается), подняли и переставили в позицию с которой начали царапать. Вот если основание лапы не закреплено на поверхности, а кончик имеет достаточно фрикционного сцепления с поверхностью, то вместо царапанья у вас отталкивание от поверхности будет в противоположную сторону.
Для этого вы используете, условно назовем, дифференцирование по времени, и вся кинематика у вас должна быть масштабированной по времени. Например, берете долю секунды dt, потраченную на выполнения предыдущей итерации loop, и на текущей итерации домножаете все процессы на это dt. То есть например вам нужно из X1,Y1 переместиться в X2,Y2 - вы не просто сервам говорите что теперь вам в X2,Y2, а строете параметрическое уравнение прямой перемещения, параметр у вас - это время, и вы его в начале движения задаете равным нулю, и каждый луп прибавляете к нему дельту времени dt и координаты X,Y у вас получаются от X1,Y1 плавно стремятся к X2,Y2. Это чтобы за 1сек переместиться. Если вам надо быстрее или медленнее - вы не dt прибавляете, а dt / sec где sec это желаемое время выполнения перемещения в секундах
Я уверен в том что это всё реально, потому что у меня уже был заброшенный проект где все это работало. Просто из-за дерьмовых серв и хлипкой рамы из плекса я все забросил в долгий ящик
Пока из интересного понял, что байты в строки, а потом расшифровка это не круто.
…давно давно мне говорили, что одиночные байты это ерунда полная.
…а оказывается ценная мысль 
для этого существуют протоколы, а они пакетами оперируют
Но смысл протокола - уже знать по виду байту какую информацию он несёт. т.е грубо говоря действовать по байтно, или всё же ждать набор, а уж потоом…
почитай про mavlink к примеру
Интересный концепт, непонятный пока.
…У меня вообще нет речи о хождениях гексапода по заданным координатам поля - это жесть как трудно, без возможности отслеживания текущего положения.
Байты и биты - основа бытия 