Каковы недостатки битового SPI/I2C во встраиваемых приложениях

Bit-banging влечет за собой накладные расходы на программное обеспечение, потребляющие циклы ЦП, которые в противном случае вы могли бы использовать для других целей. Это может оказать заметное влияние на реакцию системы на другие события, а в системе жесткого реального времени может существенно повлиять на способность системы соблюдать сроки в реальном времени.

Если битовый интерфейс не должен оказывать вредного влияния на производительность в реальном времени, тогда ему должен быть присвоен низкий приоритет, чтобы он сам не был детерминированным с точки зрения пропускной способности данных и задержки.

Передача с наибольшей эффективностью ЦП достигается за счет использования аппаратного интерфейса и передачи DMA, чтобы свести к минимуму программные накладные расходы. Bit-banging — это противоположная крайность.

Я бы не сказал, что это было ужасно; если в вашем приложении вы можете добиться отзывчивости и ограничений в реальном времени, а использование бит-бэнга, возможно, снижает стоимость необходимой части или позволяет использовать, например, существующее оборудование, то это может быть вполне оправдано.

Bit Banging является переносимым, см., например, код I2C в драйверах ядра Linux. Вы можете быстро запустить его, и он просто работает. Аппаратные решения, как правило, не являются таковыми, и для их запуска и запуска требуется некоторое время, и они ограничены аппаратной реализацией. Не все spi и, в частности, i2c соответствуют стандарту, который может быть реализован в общем аппаратном решении. Вы всегда должны иметь возможность вернуться к ударам по битам.

Bit bang потребляет больше ресурсов процессора, что делает его нежелательным с этой стороны. Это более портативно или может быть в зависимости от того, как оно написано, поэтому желательно на этом фронте. Аппаратный SPI/I2C противоположен им, снимает часть накладных расходов процессора, не является переносимым, не всегда достаточно гибким для работы со всеми периферийными устройствами.

Как профессионал, вам должно быть комфортно с обоими, как и с любым другим встроенным компромиссом, который вы делаете в своем дизайне.

Я не знаю, насколько это ужасно, но если у вас уже есть периферийные устройства SPI или I2C, безусловно, есть аргумент «не изобретать велосипед» против бит-бэнга, особенно когда вы может быть ошибка в вашем коде - например, вы можете сэмплировать не на том краю часов SPI, и в зависимости от задействованных допусков и того, какое оборудование вы тестируете, вы можете не заметить этого, пока вы уже не начнете производство. В статье Википедии также отмечается, что вы используете дополнительную вычислительную мощность и, вероятно, собираетесь чтобы ввести джиттер в любые сигналы, которые вы производите.

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

Ужасным его как таковым не назовешь. Но да, когда мы реализуем протокол с использованием битового взрыва, очень вероятно, что контроллер пропустит другую более важную задачу, потому что протокол может потреблять больше процессорного времени, чем то, что потребляет выделенное оборудование. ТАК, этого следует избегать в среде реального времени или, скажем, в среде, критической ко времени. обычно имеет больше джиттера или сбоев, особенно если контроллер также выполняет другие задачи во время связи. Если вообще неизбежно использование битовых ударов, то, по крайней мере, попробуйте использовать их с прерываниями вместо опроса.

Битовый взрыв не совсем возможен в системе не в реальном времени. И если вы поместите его в непрерываемое ядро, то вам действительно нужно убедиться, что вы перехватываете только определенное количество битов, прежде чем перепланировать пользовательские процессы.

Учтите следующее: у вас есть таймер планирования, работающий с интервалом в 1/1000 с. Когда он запускается, вы проверяете, хочет ли какой-либо процесс отправить данные через битбандовый интерфейс, и обрабатываете этот запрос. Запрос требует, чтобы вы перебили байт со скоростью 9600 бод (например). Теперь у вас есть проблема: битбанг байта занимает 0,8 мс. Вы не можете себе этого позволить, потому что, когда запускается прерывание по расписанию, оно должно выполнить свою работу и загрузить следующий процесс, который требуется для запуска, а затем выйти. Обычно это занимает гораздо меньше времени, чем 1 мс, и эта 1 мс в основном тратится на выполнение пользовательского процесса до следующего прерывания. Но если вы начнете использовать битбанг, вы в основном потратите эти мс, ничего не делая.

Одним из решений этой проблемы может быть использование периферийного устройства таймера только для битовых ударов. Это дало бы довольно автономный и управляемый прерываниями код битбанга, который вообще не должен бездействовать, но это только за счет использования выделенного таймера. Если вы можете позволить себе специальный аппаратный таймер, то битбанг, вероятно, будет работать отлично. Но в целом очень сложно сделать надежный битбанг на высоких скоростях в многозадачной среде.