74HC595 через аппаратный SPI: в 100 раз быстрее shiftOut

Куб 4x4x4 на восьми 74HC595, который я обламывался собрать в уроке про shiftOut: один слой горит, остальные погашены, кадр надо переобновлять тысячу раз в секунду, иначе глаз ловит стробы. Бюджет кадра — миллисекунда. shiftOut выкатывал восемь байтов примерно за восемьсот микросекунд: восемьдесят процентов бюджета уходило на дёрганье ногами, и loop() едва дышал. Переезд на аппаратный SPI занял вечер и отнял те самые восемьсот микросекунд: тот же кадр стал стоить шестнадцать. Дальше — новая проводка, честный замер micros(), каскад и грабли переезда.

Схема при этом не меняется ни на резистор: шкала из огней как в уроке про бегущие огни, только вместо восьми пинов платы — чип. Меняются два провода и вся механика вывода: shiftOut — программа, ногами имитирующая шину; SPI.transfer — вызов аппаратного блока, который делает то же самое в сотню раз быстрее и освобождает процессор на время передачи.

Аппаратная периферия диктует пины, и тут ничего не выбрать. DATA (SER чипа) садится на MOSI — D11, где и жила в shiftOut-версии. CLOCK (SRCLK) переезжает с D12 на SCK — D13: такт теперь даёт железо, а не программа. LATCH (RCLK) — на D10, он же SS: классическое место выбора чипа на шине. Протокол кадра прежний по смыслу: в покое HIGH, на время передачи LOW, в конце короткий HIGH — этим фронтом защёлка выкидывает готовый байт на выходы Q0-Q7. MISO у чипа нет — 595 умеет только слушать, поэтому D12 остаётся свободной. Служебные ножки не трогались: MR к 5 В, OE к GND, керамика 0,1 мкФ у питания каждого корпуса. На Nano и Mega аппаратные пины те же — семейство ATmega держит расклад, так что скетч переезжает между платами без правок.

Каждый кадр — одна транзакция: beginTransaction выставляет восемь мегагерц и MSBFIRST, transfer кладёт байт на шину за пару микросекунд, endTransaction отдаёт настройки. Скорость здесь не для гордости: чип принимает биты хоть на килогерце, но каждую сэкономленную сотню микросекунд loop() тратит на кнопки и датчики, а не на ожидание.

Мой замер на живой Uno печатает 1900-2100 мкс на тысячу байтов — около двух микросекунд на байт, из которых большая часть — накладные расходы вызова, а не такт. shiftOut на том же стенде брал порядка сотни: «в сотню раз» — не маркетинг, а арифметика двух замеров. В чужих замерах по сети гуляют числа от полутора десятков до двух сотен с лишним раз: зависит от того, с чем сравнивали — с голым digitalWrite-битбангом или с вылизанным кодом. Замеряйте сами: micros() вокруг тысячи вызовов — и у вас своя честная цифра вместо чужой.

Контрольный замер для скептиков делается тем же скелетом: тот же цикл, тот же байт, но вместо transfer — shiftOut(D11, D12, MSBFIRST, 0b10110010). На моей Uno тысяча вызовов уложилась в сотню с лишним миллисекунд против двух — цифры с разницей в два порядка на одной и той же плате в один и тот же вечер. Отсюда и практический вывод, который я вынес из куба: быстрый кадр бережёт не только проценты загрузки, но и опрос кнопок с чтением датчиков, который больше не ждёт в очереди. Массив кадров в скетче выше — приёмы из урока про массивы и журналы: кадры живут отдельно от логики вывода.

Каскад переезда не заметил. Два transfer подряд — и байты едут тем же поездом, что в shiftOut-версии: первые восемь тактов проталкивают первый байт сквозь ближний чип во второй, вторые — садятся в ближний. Порядок прежний: дальнему чипу — первый байт, защёлка одна на оба корпуса, кадр встаёт на оба шкафа одновременно. Разница только в масштабе: два transfer стоят четыре микросекунды, и восемь чипов куба обновляются за шестнадцать — против восьмисот у shiftOut. Именно эта разница превращает мультиплексирование на тысяче кадров в секунду из недостижимой мечты в обычный цикл.

Третий, четвёртый, восьмой чип едут тем же составом без новых пинов: QH* каждого — в SER следующего, такт и защёлка общие. Практический потолок на макетке ставит не протокол, а провод: к восьмому корпусу такт доезжает с уже заметным звоном, и если дальние чипы ловят лишние фронты — снижайте частоту, а не перепаивайте. И следите за питанием: восемь корпусов — восемь керамик по 0,1 мкФ, экономия на одной из них однажды проявится как самопроизвольная перезагрузка всей шины.

Порядок битов теперь живёт в SPISettings: MSBFIRST — старший бит уезжает первым и садится на Q7, картинка совпадает с интуицией. Огни побежали задом наперёд — паяльник не нужен: меняйте константу в настройках или зеркальте байт сдвигами из урока про битовые операции. Отдельный козырь, о котором редко пишут: на одной шине с регистрами живут и другие чипы — каждому свой CS, а такт и MOSI общие. Так я однажды подвесил к шине с 595 модуль SD-карты: правило одно — менять частоту через beginTransaction перед каждым чипом, регистрам хватает и одного мегагерца, а карта просит восемь.

Справедливости ради: shiftOut не мусор. На статичной индикации — пара чипов, мигающих раз в секунду, — сотня микросекунд на байт ничего не стоит, а пины остаются свободными; я до сих пор гоняю так комнатный индикатор. Мой водораздел простой: статика — shiftOut, всё, что мультиплексируется, анимируется или делит шину с быстрым соседом, — SPI. Бонус от переезда заметен и на кнопках: кадр перестал глушить опрос, и нажатия ловятся на каждом проходе loop(), как в уроке про кнопку, — раньше на длинных каскадах я терял касания во время выкатки.

Бонус помельче, но тоже приятный: короткий кадр почти не мешает прерываниям. transfer перекрывает обработчик максимум на пару микросекунд, тогда как стомикросекундный shiftOut на фронте с энкодера ронял каждый десятый щелчок. Если у вас в проекте есть attachInterrupt и каскад регистров одновременно — это не сценарий «или-или», просто переведите выкатку на SPI и они перестанут воевать.