-
- Контроллер обычно (про конкретный пик -- х.з.) умеет принимать
только байты, иногда слова. Регистр сдвига обычно отличается от
регистра доступного на чтение процессору (так делается буферизация,
чтоб в прерывании хоть что-то успел). Потом в каком пике, их сотни.
Там где USART -- оно вообще не SPI. - fk0(11.11.2020 12:21)
- Это понятно, просто хотел уточнить, если не заполнен буфер SPI
полностью, то фиг до него доберешься. MCU - PIC16F1947 - Make_Pic(11.11.2020 13:02)
- Упс! ;) Мой любимый PIC. Довольно ресурсненький для 16-й серии. Да! Вполне программно SPI можно замутить! Кстати, уж не какая-нить обрезанная по протоколу китайчатина подключается к процу? Любят они (в последние времена) мутить , со своим видением т.с, .. версии I2C, SPI в ряде чипов. - SERHIO(12.11.2020 22:48)
- Это понятно, просто хотел уточнить, если не заполнен буфер SPI
полностью, то фиг до него доберешься. MCU - PIC16F1947 - Make_Pic(11.11.2020 13:02)
- Есть некая микросхема, которая выплевывает последовательно данные
по 4 бита, сопровождая очень короткими синхроимпульсами - Make_Pic(11.11.2020 12:12)
- Может, есть возможность ему заранее 4 импульса задвинуть? А дальше
он сам. - SciFi(11.11.2020 13:08)
- есть такой вариант - Make_Pic(11.11.2020 21:16)
- внешний регистр сдвига решит эту задачу либо программно
контроллером. - m16(11.11.2020 12:18)
- да видимо так - Make_Pic(11.11.2020 13:00)
- Может, есть возможность ему заранее 4 импульса задвинуть? А дальше
он сам. - SciFi(11.11.2020 13:08)
- Контроллер обычно (про конкретный пик -- х.з.) умеет принимать
только байты, иногда слова. Регистр сдвига обычно отличается от
регистра доступного на чтение процессору (так делается буферизация,
чтоб в прерывании хоть что-то успел). Потом в каком пике, их сотни.
Там где USART -- оно вообще не SPI. - fk0(11.11.2020 12:21)