[jcxz 184]

4 минуты назад, amaora сказал:

Можно, было подобное, теперь нет достаточно flash памяти на две копии.

2 копии и не надо: прошили целиком прошивку, потом проверили целиком. Если проверка не прошла - не активировали (остались в загрузчике или кто там у вас грузит прошивку).

4 минуты назад, amaora сказал:

Протокол без обратной связи, без запроса повторной пересылки, один байт потеряется/побъется и да, CRC32 не сойдется.

Ну если без "обратной связи", то просто по несколько повторов одного блока. И сравнить между собой эти повторы и только потом шить.

На один-то блок памяти хватит?  

[amaora 20]

11 minutes ago, k155la3 said:

пользуйте код Хемминга. Если памяти достаточно - восстановление через таблицу.

Как применить это к большому блоку данных ~100Кб? Допустим есть возможность увеличить размер передаваемых данных на 50% (~150Кб), как потом восстановить исходные данные из уцелевших кусков которые суммарно имеют длину ~100Кб но разбросаны произвольным образом? Восстановление отдельных разрядов внутри короткого слова это не то, что нужно.

[jcxz 184]

2 минуты назад, k155la3 сказал:

ну, вот этот тезис наводит на мысли. 64 байта как буфер RF-трансивера. 

ТС чётко написал:

3 часа назад, amaora сказал:

USART или CAN

2 минуты назад, k155la3 сказал:

ТС же кодируется что у него в качестве среды передачи. То-ли физпара с помехами то-ли еще что.

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

3 минуты назад, amaora сказал:

как потом восстановить исходные данные из уцелевших кусков которые суммарно имеют длину ~100Кб но разбросаны произвольным образом?

Да похоже реально речь про голубиную стаю или что-то подобное экзотическое....   Или ТС нечем заняться.

Ума не приложу зачем такой лес городить для обыкновенного UART???  

[aleksandr-zh 4]

загрузчик при перепрошивке не трогать: он отвечает только за сам факт приёма данных и сохранения в flash.
Если прошилось нормально - он запускает новую прошивку, если нет - снова ждём прошивку.
А вы её передаёте три раза, с паузой, достаточной для перезапуска МК и проверки достоверности принятой прошивки.
И передаёте раза три. Я бы на этом и остановился...

[k155la3 26]

2 minutes ago, amaora said:

. . .  Восстановление отдельных разрядов внутри короткого слова это не то, что нужно.

Это самое простое. Все зависит от характера "выпадания" достоверной информации. Есть другие коды-алгоритмы, где каждый элемент информации "размазан" на временном участке или томуподобное, такая себе "голограмма". Все зависит от ресурса RAM. А его, я так понял нет.

Используйте блоки минимального размера, снижайте скорость передачи инф. Хот все это без "обратной связи" как-то проблематично. Ну, передалась вся прошивка 100к, за исключением 1 бита. Как передающая сторона узнает, в каком блоке (например из 64 байт) это произошло и сделает повтор ?

[amaora 20]

2 minutes ago, k155la3 said:

Это самое простое. Все зависит от характера "выпадания" достоверной информации.

Разобьём передаваемый поток байт на блоки, по 4-16 байт. Синхронизацию и проверку целостности блоков оставим на более низкие уровни. Будем считать, после передачи на принимающей стороне находятся корректные блоки в корректном порядке, известно какие блоки отсутствуют. Выпадать может любой блок, или несколько в произвольных местах. Какие алгоритмы можно применить?

[kovigor 5]

XModem, повторюсь. В нем пакеты нумеруются и потерять пакет не так-то просто.

А вообще, по UART в норме ничего (почти) не бьется. Если у вас бьется, то что-то с аппаратной частью не так.

Кстати, у вас линия насколько длинная ?

[k155la3 26]

4 minutes ago, amaora said:

Разобьём передаваемый поток байт на блоки, по 4-16 байт. Синхронизацию и проверку целостности блоков оставим на более низкие уровни. Будем считать, после передачи на принимающей стороне находятся корректные блоки в корректном порядке, известно какие блоки отсутствуют. Выпадать может любой блок, или несколько в произвольных местах. Какие алгоритмы можно применить?

посмотрите классику, X-модем, Z-модем. Небольшие кадры передаются "окнами", без подтверждения в окне.  По итогу- запрос повтора.

Но есть проблема

ТС>> Есть возможность передавать данные в одну сторону по цифровому каналу связи,

Сперва нужно знать х-ки канала и помех, а также то, где находятся передающая сторона и принимающая. (повтор) Как "передающий" узнает, что вся инф. принята и далее передавать ничего не надо

 

[amaora 20]

1 minute ago, kovigor said:

А вообще, по UART в норме ничего (почти) не бьется. Если у вас бьется, то что-то с аппаратной частью не так.

Кстати, у вас линия насколько длинная ?

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

 

7 minutes ago, k155la3 said:

посмотрите классику, X-модем, Z-модем.

Где-то применял их раньше, но это не то, что нужно сейчас. Похоже остаётся повторять блоки несколько раз как самое простое. Можно ещё подумать в каком порядке лучше их повторять.

[kovigor 5]

Все уже продумано. Ну или используйте обычные телефонные модемы, там как раз UART и данные можно передавать хоть через всю страну ...

[aleksandr-zh 4]

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

Но это так, к слову об извратах ))

Изменено 1 мая, 2022 пользователем aleksandr-zh

[kovigor 5]

К сожалению, сотни килобайт так не передашь ...

[k155la3 26]

31 minutes ago, amaora said:

. . . Можно ещё подумать в каком порядке лучше их повторять.

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

Уж если поминался "к примеру" USART/CAN, то возможно забодать проблему (также "к примеру") можно другим методом модуляции/кодирования самого нижнего (физического) уровня и проблема сойдет на ноль. К примеру, вы используете телеграфный канал, с множественной пере-передачей и пытаетесь "пропихнуть" через него U(S)ART. При этом для для манчестерского кодирования вероятность "добраться живым" до пункта назначения гораздо больше.

А порядок передачи ... Повтор делать в случайном порядке. Если не в случайном - нужно знать статистику потери информации по времени-длительности-частоте.

[amaora 20]

23 minutes ago, k155la3 said:

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

Слишком узкое решение под определённые условия тоже "не очень". Ну возмем более мягкую модель, пусть сбоем будет называться пропажа блока длиной 1-500 байт неразрывным куском, с вероятностью 0.003, один раз за всю передачу. Длина пропавшего блока и его смещение от начала имеют равномерное распределение.

 

Тогда достаточно, держать повторные блоки на расстоянии более 500 байт от оригинальных.

 

Можно дополнить задачу следующим условием. Необходимо минимизировать время (среднее/максимальное) получения принимающей стороной полного пакета данных с учётом ожидания недостающих повторных блоков в случае наличия сбоя.

 

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

[k155la3 26]

43 minutes ago, amaora said:

Слишком узкое решение . . .

Да, это имелось ввиду.

Если делать просто "повторы" - то так. Если использовать избыточность - можно эти 500 "потерянных" байт (бит) "размазать" по всему временнОму интервалу передачи всей информации (в том чиселе и корректирующие участки). Тогда выпадение любого 500-байтного участка приведет к единичной ошибке в каждом блоке, которая может быть скорректирована. Но потребуется RAM. Корректирующие коды (используются в технологии CD).