74HC595 для 8266 через его SPI
Добавлено: 07 авг 2026, 06:17
На версии 9.7.1
Продолжим тематику изучения «мусорных»* контроллеров на примере 8266 с расширителем портов 595.
* — по мнению разработчиков FLProg
Не требует тормозной библиотеки.
Из интересного, пожалуй, есть тут в аппаратном SPI буфер данных, а именно 16 слов по 32 бита = 64 байта.
И, как вы уже все поняли, это значит, что можно, заполнив этот буфер, отправить одной транзакцией данные сразу на все 64 каскада, исключая лишние операции процессора.
Доступ через регистры.
Нечто подобное я делал на 328-й через USART, но там был двойной байтовый буфер, что мало, но и его хватило значительно, чтобы превзойти аппаратный SPI свой.
Можно задать:
— любую частоту тактирования (округлится до ближайшей);
— каскадов 1–64;
— пин защёлки на выбор;
— смену направления битов;
— непрерывную отправку в каждом цикле.
64 каскада — это не предел, а выбрал, чтобы заполнить весь буфер.
Сравнивать будем с блоком-кандидатом на типичные 100500 контроллеров.
Как показала практика, если сделать блок, заточенный под конкретный МК, то тот же 328-й может быть в более чем 5 раз быстрее, чем блок кандидатов.
Здесь результаты поскромнее, и, более того, их занижает ещё библиотека FLProg от чистового варианта.
Тестирование:
Возьмём частоту 4 МГц, 1 каскад, диспетчер отключен.
И это нечистовая скорость лупа, а вместе с измерительным пином, который забирает примерно 7 мкс от общего замера.
декодер видит 5 которую отправили а тут декодер невидит потомучто защёлка у них через единицу движется
но там тоже 5 по моси
возьмём 4 каскада тут уже через буфер видим одну транзакцию
декодер показывает правильную рашифровку и движения байтов тут типичная древняя SPI по байтовая отправка
с кучей трат на время между ними
Продолжим тематику изучения «мусорных»* контроллеров на примере 8266 с расширителем портов 595.
* — по мнению разработчиков FLProg
Не требует тормозной библиотеки.
Из интересного, пожалуй, есть тут в аппаратном SPI буфер данных, а именно 16 слов по 32 бита = 64 байта.
И, как вы уже все поняли, это значит, что можно, заполнив этот буфер, отправить одной транзакцией данные сразу на все 64 каскада, исключая лишние операции процессора.
Доступ через регистры.
Нечто подобное я делал на 328-й через USART, но там был двойной байтовый буфер, что мало, но и его хватило значительно, чтобы превзойти аппаратный SPI свой.
Можно задать:
— любую частоту тактирования (округлится до ближайшей);
— каскадов 1–64;
— пин защёлки на выбор;
— смену направления битов;
— непрерывную отправку в каждом цикле.
64 каскада — это не предел, а выбрал, чтобы заполнить весь буфер.
Сравнивать будем с блоком-кандидатом на типичные 100500 контроллеров.
Как показала практика, если сделать блок, заточенный под конкретный МК, то тот же 328-й может быть в более чем 5 раз быстрее, чем блок кандидатов.
Здесь результаты поскромнее, и, более того, их занижает ещё библиотека FLProg от чистового варианта.
Тестирование:
Возьмём частоту 4 МГц, 1 каскад, диспетчер отключен.
И это нечистовая скорость лупа, а вместе с измерительным пином, который забирает примерно 7 мкс от общего замера.
декодер видит 5 которую отправили а тут декодер невидит потомучто защёлка у них через единицу движется
но там тоже 5 по моси
возьмём 4 каскада тут уже через буфер видим одну транзакцию
декодер показывает правильную рашифровку и движения байтов тут типичная древняя SPI по байтовая отправка
с кучей трат на время между ними