Мне всё хочется понять, как можно строить асинхронный bit-bang драйвер
а как эти две фразы связаны?
Я представляю себе асинхронный bit-bang драйвер так, что ты от дерева клоков отдаёшь на тактирующий выход сигнал с нужной частотой, а дальше уже по его положительному фронту делаешь свою логику, как это бы работало на плисине в моём понимании. Как такое сделать на интерфейсе `embedded-hal`(async), мне не особо понятно. Возможно, мне надо посмотреть на embassy и понять, что всё нужно делать наоборот
неа, так не будет работать в общем случае
А как будет? Ну и если не в общем случае, а в частном, то что может помешать? Мк, который не умеет отдавать клок? Железка, которая не ожидает стабильного клока, потому что использует его только для IO? Или ограничения МК, который всё же не ПЛИС/СБИС и программируется уровнем выше?
Тем что тебе надо того кто это будет исполнять
Но ведь в кейсе условного bare metal мы можем считать, что весь проц в нашем распоряжении. Или даже здесь есть задержка на генерацию интеррапта по фронту клокового сигнала. Если так, то разве железка к этой задержке не толерантна? Иначе и синхронный вариант бы работать не мог. Вообще не знаю, как в I2C, но в tm1637 клок используется только во время IO, на остальное время он должен быть фиксирован. Поэтому изначальная схема и впрямь некорретная в этом случае. И вообще непонятно, о какой асихронности может идти речь в случае прямой записи на дисплей без буферизации, там тупо ждать нечего.
и да и нет, плюс там всё достаточно плавающее
Обсуждают сегодня