FlProg

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

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

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

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

seri0shka писал(а): 19 янв 2019, 21:17необходимость передачи 32 или 64 бит

seri0shka писал(а): 19 янв 2019, 21:17Время передачи не более 50 миллисекунд

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

Sancho писал(а): 19 янв 2019, 21:32Прерывания остались?

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

Sancho писал(а): 19 янв 2019, 21:32Либо писать свой

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

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

Sancho писал(а): 19 янв 2019, 21:32Прерывания остались?

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

Е

seri0shka писал(а): 19 янв 2019, 21:17так как пины кварца задействованы по другому назначению.

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

Ingwar писал(а): 19 янв 2019, 22:36Е

seri0shka писал(а): 19 янв 2019, 21:17так как пины кварца задействованы по другому назначению.

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

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

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

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

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

nalnik писал(а): 19 янв 2019, 22:55Он даже не написал на каком "камушке" он это делает.

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

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

Ingwar писал(а): 19 янв 2019, 22:36Перейти на более многоногий сопряжено с затратами?

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

seri0shka писал(а): 20 янв 2019, 00:55Как мне её на готовые платы впихнуть?

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

Ingwar писал(а): 20 янв 2019, 01:08А как без всестороннего теста заказывать/делать много плат?...

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

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

Ingwar писал(а): 20 янв 2019, 01:08как без всестороннего теста заказывать/делать много плат?

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

seri0shka писал(а): 20 янв 2019, 11:48

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

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

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

Sancho писал(а): 20 янв 2019, 12:12я так не писал!

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

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

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

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

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

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

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

Fuji1604 писал(а): 20 янв 2019, 22:51Сейчас делаю термостат для газового котла

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

seri0shka писал(а): 21 янв 2019, 01:43А вот приём я не сделаю даже по статье.

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