Однопроводный интерфейс.

[seri0shka]

Есть необходимость передачи 32 или 64 бит информации с одного контроллера на другой. Изначально планировалось передавать по UART (TX на передающем контроллере, RX на принимающем). Но в процессе отладки уже готовых устройств внезапно оказалось, что при работе приёмного контроллера от внутреннего генератора информация принимается с большими погрешностями или не принимается совсем. Поставить кварц- не вариант, так как пины кварца задействованы по другому назначению. Также не подходит вариант с применением аппаратных решений. То есть по сути нога передающего должна быть соединена с приёмным без посредников.
Какие ещё варианты однопроводных интерфейсов есть? Желательно без жёсткой привязке к частоте и без большой вычислительной нагрузки. Время передачи не более 50 миллисекунд.

[Sancho]

[ref]seri0shka[/ref], Я не спец по протоколам/интерфейсам, но стабильность тактирования одна из задач при передачи/приёме инфы при передаче по "одному проводу/радиоканалу"...
Как вариант, попробовать oneware?

Отправлено спустя 1 минуту 14 секунд:
Либо писать свой, либо найти ещё ногу, свободную.

Отправлено спустя 2 минуты 30 секунд:

необходимость передачи 32 или 64 бит

Время передачи не более 50 миллисекунд

Т.е. около 1кгц. Прерывания остались?

[seri0shka]

Прерывания остались?

Не задействованы

Либо писать свой

Думал об этом. Тем более, что oneware чрезмерно усложнён даже для тех задач, для которых уже применяется.
Возможно ли измерить подряд длительность 64 импульсов, по результатам сформировать 64 булевых переменных? Разумеется, должны быть ещё сигналы начала и окончания посылки. Длительность импульсов 0 и 1 может отличаться в несколько раз для исключения ошибок.

Отправлено спустя 24 минуты 17 секунд:

Прерывания остались?

Забыл сказать: пины задействованы все, кроме RX.

[Ingwar]

Е

так как пины кварца задействованы по другому назначению.

Логично предположить, что используется чистый камушек. Перейти на более многоногий сопряжено с затратами?

[nalnik]

Е

так как пины кварца задействованы по другому назначению.

Логично предположить, что используется чистый камушек. Перейти на более многоногий сопряжено с затратами?

Он даже не написал на каком "камушке" он это делает.

[seri0shka]

Атмега8, как самая дешёвая и доступная. Хотя ничего не изменилось бы, если б была 168 или 328.

[Sancho]

[ref]seri0shka[/ref], Я не такой практик, как кажусь, но на встроенном гене не получается принять на 19200? Подключите тестер - он принимает? и наоборот - зашлите.

[seri0shka]

Пока не могу провести испытания, известно только , что с атмеги с внутренним тактированием в компьютер шлёт абракадабру, каждый раз по-разному. А прошить по RX-TX вообще невозможно, что мне очень не нравится, потому как я собирался через ISP только один раз загрузчик прошить, а далее по RX-TX, и платы под это разведены. UART допускает отклонение 1...2% (ЕМНИП), а внутренний генератор даёт до 5%.

[Ingwar]

Он даже не написал на каком "камушке" он это делает.

Вот все и выяснилось). Берем 644 и усе).

[seri0shka]

А почему не 2560?
Как мне её на готовые платы впихнуть?

[Ingwar]

Перейти на более многоногий сопряжено с затратами?

Вроде сразу предположил.

Как мне её на готовые платы впихнуть?

А как без всестороннего теста заказывать/делать много плат?...

[Sancho]

А как без всестороннего теста заказывать/делать много плат?...

Серёга, в отношении Вас Очень интересный вопрос....
Учитывая .....

[seri0shka]

Более многоногий контроллер- это не наш метод )
Меня воротит от устройств, которые используют минимум своих возможностей. Это как использовать плазменный телевизор в качестве цифровой фоторамки, например.
Ну и цена и доступность имеют значение.

как без всестороннего теста заказывать/делать много плат?

Всесторонний тест был проведён, всё было испытано в жёстких условиях, внесены необходимые изменения. Затем заказана новая версия плат с учётом полученного опыта. От кварца отказался с целью упрощения. Не ожидал такой разницы при внешнем тактировании и внутреннем. Скорей всего даже часть плат будут работать нормально, но о надёжности не может быть и речи. Зачем мне устройство, зависящее от температуры воздуха и магнитных бурь на Солнце?
В данном случае речь идёт даже не о конкретном частном случае с моими устройствами. Я могу выкрутиться, пойдя на некоторые компромиссы.
Странно просто, что нет простого надёжного однопроводного интерфейса для связи двух контроллеров (или двухпроводного, если в две стороны, хотя даже в таком случае можно обойтись одним проводом с некоторыми нюансами). Даже простая глупая WS2812 (WS2811) позволяет принять по одному проводу 768 бит информации без всяких кварцев (умный светодиод, если кто не понял).
Если такого интерфейса нет, его стоит разработать, завтра он может пригодиться каждому из вас.

[Sancho]

Sancho писал(а): ↑Сегодня [01:36]
как без всестороннего теста заказывать/делать много плат?

Всесторонний тест был проведён, всё было испытано в жёстких условиях, внесены необходимые изменения.

я так не писал!

[seri0shka]

я так не писал!

Технические накладки.

Многоногий контроллер сюда не особо хочет лезть.

Отправлено спустя 3 часа 38 минут 29 секунд:
P. S.
Сейчас мне достаточно трёх байт.
Для быстрого решения проблемы использую один из двух вариантов:
1. Отправляю не 3 байта сразу, а 3 раза по байту, это должно уменьшить вероятность ошибок при несовпадении частот передатчика и приёмника.
2. Использую программный блок отправки в UART, который делал для тини13, там временные параметры можно подобрать для надёжного приёма.
Но вопрос о надёжном однопроводном интерфейсе, не привязанном к точной частоте, остаётся открытым.

[kulibinsvv]

[ref]seri0shka[/ref], а понижать скорость передачи UART пробовали?

[seri0shka]

Пока глобальных испытаний в данном варианте не проводил (ещё не распаял) . Но сам принцип интерфейса UART построен так, что ошибки зависят не от скорости, а от процента расхождения частот. Кроме того, даже если испытания пройдут успешно, возможно, отклонение частоты находится на самом крае допустимого, и ошибки начнутся при изменении частоты ещё на долю процента вследствии изменения температуры уже на эксплуатируемом устройстве, это намного хуже. Раздобыть бы где кварцы на 16МГц+5% и на 16МГц-5% для проверки.
Кроме того, плата приёмного контроллера не очень подходит для многократной прошивки при экспериментах, планировалось прошивать один раз.

[Fuji1604]

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

Отправлено спустя 20 минут 32 секунды:
Вот https://m.habr.com/ru/post/251539/ хорошо расписан принцип передачи данных

[seri0shka]

Сейчас делаю термостат для газового котла

На ардуино? Будете кодить манчестерский код?
Только вчера впервые нашёл упоминание о нём, почитал описание и ничего не понял. В приведённой статье действительно всё понятно. Передачу организовать проще простого. А вот приём я не сделаю даже по статье.

[Fuji1604]

А вот приём я не сделаю даже по статье.

Вот https://github.com/jpraus/arduino-opent ... ateway.ino с приемом и передачей