У меня такя проблемма, на ноги мк идёт два синала, clock для синхронизации и data. Данные достоверны когда сигнал clock принимает лог.0 так вот если оборвать, сигнал, а потом запустить, то данные уже идут не синхронизировано и искажаются. Как это можно иправить, честно только столкнулся с этим, и даже не знаю куда капнуть, и что почитать, про эти синхро сигналы?

Так если это микроконтроллер, то можно организовать проверку на "пропажу" синхросигнала и соответственно как то источник "оповещать" о том что пакет данных испорчен. или если это система не критичная к потере данных от кадра к кадру, то просто этот пакет игнорировать можно, ждать прихода следующего.

Синхронизацию фреймов в синхронных интерфейсах обычно реализуют двумя способами:
- отдельный сигнал (наиболее часто встречающееся решение),
- временнАя синхронизация (нормированная пауза в передаче).
Поскольку у вас как я понял нет отдельного сигнала фреймовой синхронизации, то вам остается только второй способ. При возникновении паузы в сигнале тактирования свыше установленной, приемник должен сбрасывать свою логику и при возобновлении передачи считать, что начался новый фрейм.

2yagger
нельзя терять не одного бита, там суть такая
2rezident
у меня две линии, синхро-сигнал и данные

в начале и вконце данных идут нули синхронизации, старт байт - данные - стоп байт, и опять нули синхронизации.
пример 00000 START DATA STOP 00000
Как это работает я если честно плохо пока себе представляю, разработка не моя я только доробатываю. Моя задача убрать глюки при остановке сигналов. Так я порылся в нете, нашел что похожий протокол применяеться в клавиатурах, и в декодерах магнитной дорожки, но я ничего не нашел на эту тему на русском, а в английском не особо силён.
Вот нашел пример, с какого то, декодера. почитал даташит, там ничего не написанно про такую проблемму.

Появилась идея взять другой источник синхросигнала, как нибудь наложить его на синхро сигнал с этого устройства, и если он остановится, то одельный сигнал будет продолжать его работу, а вот что делать если остановиться data не знаю.

Ваша логика синхронизации работать не будет, и вот почему, 5 бит нулей, в начале байта могут восприниматься как часть данных,
вот если бы вначале было 10бит нулей, тогда это точно начало байта, потому что в данных не может быть 10 бит.
Другой способ, это работать с клоком. Т.е. длина одного бита данных например 2 такта, а длина бита синхронизации 1 такт.
Тогда если в начале сделать последовательность 010101, причем длиной в 1 такт каждый бит синхронизации, то даже при сбое клока, перепад
данных на каждый такт можно вопринимать как синхронизацию. Затем пауза два такта. И все, после данные. Тогда при сбое синхронизации
ловим перепад данных на каждый такт клока, хотя бы один раз и паузу в два такта и все мы входим в байт данных.

А Preset разве не тот самый искомый сигнал фреймовой синхронизации?

У меня то этого сигнала нет, этот рисунок из даташита, декодера. Ну а даже если бы был, не улавливаю толк от него, всё равно же он не поможет во время остановки.
2vvvv
Моя ошибка, не уточнил, там этих нулей по 17 шт. просто не стал всё тут писать.
А можно как либо это провернуть, не меняя протокола, т.е. оставить эти 17 нулей синхронизации?

А можна так сделать ?
Нажмите для просмотра прикрепленного файла

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

2А можна так сделать ?
Можно... но мне хочется не менять протокол вообще.
2vvvv
Спасибо, я конечно извиняюсь за новязчивость, но если честно я плохо понял всё что вы написали. я как и писал пока плохо представляю суть этого протокола, и по идеи не понимаю почему остановка так влиет на данные, особенно если останавливается и тот и другой сигнал. А потом вознобнавляется, какую роль играют эти нули я тоже кроме того что они нужны для синхронизации не понимаю. Если вас не затруднит можете расписать более подробней (с технической стороны) почему возникает эта проблемма и что делается по выше описанному вами алгориму для предотварщения этой проблеммы.
А ещё забыл добавить что
DATA это не один байт а 50
т.е
нули - старт байт - 50 байт данных - стоп байт - 17 бит нулей.
Каждый байт это 4 бита и контороль чётности т.е всего 5 бит

Подробно. Вы принимаете данные все хорошо, вдруг у Вас пропадает клок. Выставляете флаг аварии "пропал клок" и ждете появления клока.
С этого момента никакого приема данных не будет до появления клока как минимум. Ждем. Появился клок, по клоку начинаем
снимать данные с линии данных, допустим она тоже лежит. Считываем данные с "мертвой линии", но мы этого пока не знаем.
Итак считаем клоки пока линия данных в "0". Досчитали до 17. А линия данных лежит по прежнему. 18,19,20. и т.д.
После 17 такта клока понимаем, что линия данных нерабочая. Выставляем другой флаг "авария на линии данных" и ждем чтобы она
начала шевелиться, опа линия зашевелилась, т.е. перешла из 0 в 1, не торопимся принимать данные, ждем новой паузы в 17 тактов,
пришла наконец пауза в 17 тактов и после нее переход из 0 в 1, а затем ровно через два такта(длина старт строба) переход обратно из 1 в 0,
все теперь пойдут точно данные, снимаем флаги аварий и принимаем данные. Приняли байт данных, записали в память. Ждем паузу в 17 тактов,
затем строб в два такта, следующий байт записали в память и так далее.
Далее, все нормально принимаем, бац пауза не 17, а 14 тактов или 16, и после нее сразу строб, можно посчитать это нормальной ситуацией и
принять 8 бит данных. Так и делаем, принимаем 8 бит данные, после чего ждем паузу. Если пауза нормальная, все в порядке продолжаем прием.
Бац после принятия данных пауза короткая, бракуем принятый байт и на ожидание нормальной паузы.
Теперь, чтобы все это понять, нужно взять карандашик и порисовать. Сразу все станет понятно.

PS: Пока писал увидел про 50 байт и контроль четности. Тут не контроль четности нужен, а нечто типа NRZ, потому что у Вас может быть 50 байт
нулей, и четность каждых 4 бит тоже будет ноль. Ну и кто это придумал? Обязательно должен быть перепад уровня. Нельзя гнать массив нулей
такой длины в линии и контроль делать тоже нулем. Меняйте протокол или делайте паузу не 17 нулей, а чтобы она была длиннее всего массива
из 50 байт со всеми четностями. Иначе никакой синхронизации не получится.

Спасибо буду сидеть рисовать))
А что касается после P.S.
Все нули и все еденици в блоке данных исключены, там всегда идут конкретные данные.
Да вот ещё, а это будет рабоать, если возобнавятся одновременно и линиия клок и дата?

Абсолютно неважно, кто там и как возобновится, сработает в любом случае. Вопрос только в том, что "конкретные данные", могут содержать 2 байта нулей. И все синхронизация накрылась, потому что 16 бит нулей плюс 4 бита четности, которые тоже равны нулю, дают 20 бит нулей, вот и все, Ваше устройство вполне может воспринять это как 17 бит синхронизации. Поэтому нужно либо перекодировать "конкретные данные" таким образом,
чтобы никогда не было больше одного нулевого байта( а это затруднительно), второй вариант это изменить контроль четности и правило его формирования,т.е. чтобы он например был равен 1 всегда, когда все четыре бита равны нулю, и наконец просто удлинить паузу до такой длины,
чтобы она точно была длиннее любой возможной комбинации нулей в реальных данных.

ну там не получиться два байта нулей, т.к. как даже число 0 кодируется как 00001 еденица 10000, двойка 01000 ну и так далее.
Ок, огромное спасибо, завртра буду сидеть разбираться!

вы случаем не ридер карт с магнитной полосой (банковских) делаете?

нет, просто протокол похожий, сейчас в нём ковыряюсь, так как почти одно и тоже, только нет линии Кард Пресент, и LRC в конце, ну и блок чуть побольше, такой ещё в клавиатурах используется, но этот ближе по описанию подходит.