Буфер Wire 32 байта: почему длинные данные обрезаются

Бегущая строка на I2C-матрице едва не поссорила меня с заказчиком. Я отправлял на дисплей название трека — строку в 38 символов с пробелами — и на экране честно появлялись первые 32, дальше обрыв. Меньше половины секунды ушло бы на то, чтобы посчитать, но я неделями подозревал экран в кривой прошивке, перешивал его, менял шлейф и уже был готов списать всё на брак. Заказчик тем временем вежливо спрашивал в третьем письме, когда же название трека станет видно целиком. А потом распечатал строку в Serial прямо перед отправкой — там были все 38. Значит, резало не устройство, а что-то по дороге.

Резал, конечно, не дорога, а мой собственный Arduino. В библиотеке Wire AVR-ядро держит константу BUFFER_LENGTH, и она равна 32 байтам: всё, что вы скормили Wire.write сверх этой цифры, молча выбрасывается на пол. Ни сообщения в Serial, ни кода возврата — тишина. endTransmission отработает штатно и вернёт ноль, потому что с точки зрения шины всё прошло хорошо: она передала ровно столько, сколько накопил буфер. Это самая тихая грабля раздела: не крашится, не зависает, просто аккуратно съедает хвост.

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

Где живёт потолок физически: в заголовочном файле Wire.h AVR-ядра объявлена константа BUFFER_LENGTH со значением 32. Wire.write складывает ваши байты в этот буфер и возвращает количество реально принятых — но в типовом коде возврат никто не смотрит, и компилятор не ругается: значение-то используется, просто молча. Анатомию транзакции — beginTransmission, write, endTransmission — мы разбирали в уроке про begin и beginTransmission; буфер сидит именно между write и выходом на шину. На других ядрах цифра другая: у ESP32 константа называется I2C_BUFFER_LENGTH и равна 128 байтам, ARM-платы держат свои объёмы. Правило одно: не верьте «должно влезть» — откройте Wire.h своего ядра, найдите константу и пишите код от неё, а не от оптимизма.

Почему эту граблю так трудно поймать: усечение не оставляет следов в возвратах. endTransmission возвращает код результата обмена — ноль для успеха и единицу-четвёрку для проблем с адресом и арбитражем, — но про переполнение буфера в этих кодах ни слова; полный разбор кодов был в уроке про коды endTransmission. Мой бегущий экран неделю был «бракованным» именно поэтому: обе стороны считали обмен успешным, потому что с их стороны он и был успешным. Самая надёжная диагностика — печатать длину того, что отправили, и длину того, что дошло, в одной строке.

Способ первый — фрагментация. Режете блок на куски по 30 байт: два байта запаса уходят под служебные — смещение или признак продолжения, — и каждый кусок уезжает отдельной транзакцией. Скетч-демонстратор ниже делает это на глазах: сначала отправляет 40 байт наивно и печатает вердикт, потом раскладывает тот же блок чанками и собирает квитанции. Число 30 я записываю константой с комментарием «32 минус запас» — тогда перенос кода на ESP32 превращается в правку одной строки. Каждый кусок помечается смещением в первом байте: получатель кладёт данные куда сказано и всегда может пересобрать порядок, даже если чанки уехали с паузами и вразнобой.

Способ второй — протокол с подтверждением. Чанки сами по себе не спасают от потери целого куска: шина могла моргнуть посреди транзакции. Поэтому каждая посылка нумеруется, а получатель отвечает квитанцией — номер принятого куска и контрольная сумма; схема старая как мир и уже разобранная в уроке про контрольную сумму. Если получатель — вторая Arduino, квитанции удобнее всего возвращать по тому же I2C: механику мастера и слейва мы прогоняли в уроке про обмен двух плат. Квитанция стоит дёшево — байт номера и байт суммы, а ловит и потерянный, и продублированный кусок.

Способ третий — читать тоже кусками. Потолок двусторонний: requestFrom складывает ответ слейва в тот же буфер, и больше 32 байтов за один запрос вы не увидите. Двухходовка «указатель плюс чтение» из урока про чтение регистров остаётся той же, меняется только длина запроса. Мой логгер на EEPROM-чипе 24LC256 читался строго страницами: курсор двигался по 32 байта, между запросами — пауза, внутри страницы чип сам прибавляет адрес. И отдельное правило для датчиков: если вы пишете в регистр, помните, что байт номера регистра идёт первым в транзакции и тоже ест буфер — на данные остаётся 31. Классическая вылетная грабля: «я передаю 32 байта конфигурации» при записи в регистр — а доезжает 31, и теряется всегда последний.

Как выглядит получатель. На стороне слейва та же арифметика: обработчик onReceive срабатывает один раз на транзакцию и получает не больше 32 байтов, каких бы ожиданий вы ни питали. Первый байт — смещение, остальные — данные: копируете их в свой длинный буфер по адресу из заголовка и считаете принятые. Квитанцию удобно отдавать в обратную сторону через onRequest — мастер сам придёт за ней после каждого куска. Собирать блок по смещениям, а не по порядку прихода, — не паранойя: при длинных паузах между чанками мастер может переслать кусок заново, и тогда получатель просто затирает старое новым, не задавая вопросов. Вся эта бухгалтерия — десяток строк, зато блок и в 40, и в 400 байтов перестаёт зависеть от капризов одной транзакции.

Что здесь честно, а что нет. Настоящего усечения в движке нет — модель буфера написана внутри скетча, и цифры «дошло 32, пропало 8» посчитаны той же логикой, которой живёт AVR-ядро. Панель шины пустая: живой транзакционный обмен со слейвом показан в code-блоке и заработает на настоящих платах без правок. Зато сам рефлекс тренируется точно: разделить блок на куски, посчитать служебные байты и не верить молчанию шины. Модель считает так же, как AVR-ядро: приёмник наполняется до потолка, а лишнее даже не доходит до очереди отправки.

Привычка, которую я вынес из истории с бегущей строкой: в каждом проекте с I2C-обменом заводится константа CHANK с запасом и печатается счётчик отправленных против принятых байтов — одна строка в Serial, зато усечение видно в первую минуту, а не на третий день. И раз уж шина у вас теперь гоняет длинные блоки, проверьте, чем её дышит вся остальная система: правило «30 данных плюс запас» помогает и там, где полдюжины устройств живут на двух проводах. Проверьте себя на живой плате: отправьте соседней Arduino блок ровно в 32 байта и в 33 — в первом случае квитанция сойдётся, во втором молча потеряется последний байт, и вы своими глазами увидите эту граблю.