Перейти к содержанию
    

Избыточное кодирование

Есть возможность передавать данные в одну сторону по цифровому каналу связи, есть возможность увеличить объем данных для восстановления возможных ошибок передачи. Какие алгоритмы можно применить?

 

Передаётся прошивка объёмом ~100Кб. Нужна устойчивость к потере до ~50% передаваемых данных. Объем передаваемых данных можно увеличить в 2-3 раза. Передача байтовый поток, либо блоками по ~64-бит с контрольной суммой каждый. У меня хватает фантазии только на передачу блоков в псевдослучайном порядке каждый по три раза.

 

Канал связи например USART или CAN.

Изменено пользователем amaora

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А я бы смотрел на задачу чуть иначе: сколько у вас памяти свободной для приёма прошивки И какой интервал времени вы готовы на это отвести?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Есть возможность передавать данные в одну сторону по цифровому каналу связи, есть возможность увеличить объем данных для восстановления возможных ошибок передачи. Какие алгоритмы можно применить?

CAN - это разве "в одну сторону"? Или что вы под этим имеете в виду?

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

Канал связи например USART или CAN.

Не очень понятно зачем какой-то "псевдослучайный порядок"?.. :wacko2:  Порядок чего? И зачем?

И зачем вообще для USART такая избыточность? Почему у вас в нём происходят такие страшные потери (50%!) ??

Да и для CAN - тем более.

PS: имхо - обычной CRC32 на всю прошивку вполне достаточно. Ну или хеш какой-нить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Нужна устойчивость к потере до ~50% передаваемых данных.

Вместо примитивных контрольных сумм передавать коды, восстанавливающие ошибки. Гуглите, изучайте.

Потеря 50% данных - откуда такой критерий: канал связи просчитывался?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Протокол с подтверждения хочется избежать, может быть много приёмников одновременно, массовая рассылка. Памяти RAM под всю прошивку нет.

 

1 minute ago, jcxz said:

PS: имхо - обычной CRC32 на всю прошивку вполне достаточно. Ну или хеш какой-нить.

 Это есть, надо немного надёжнее, особенно при передаче по UART, избежать окирпичивания из-за битых блоков/байтов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, V_G said:

Потеря 50% данных - откуда такой критерий: канал связи просчитывался?

По времени передачи, могу позволить длиться этому процессу в 2-3 раза дольше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что за USART такой с 50% потерями??? Если такое происходит, надо разбираться со схемотехникой и исправлять. А не костыли ваять.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а классику нельзя реализовать?
Сперва грузить новую прошивку в flash, перезапуск, загрузчик проверяет: если данные в этой области достоверны, то грузит с неё, иначе - идёт на прошлую прошивку и в ней работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, jcxz said:

Что за USART такой с 50% потерями??? Если такое происходит, надо разбираться со схемотехникой и исправлять. А не костыли ваять.

ТАКОЕ может случиться разве что в радиоканале. Ну, еще на CD :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Только что, k155la3 сказал:

разве что в радиоканале

и то, не всегда. У меня и не такое жило в радиоканале))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это есть, надо немного надёжнее, особенно при передаче по UART, избежать окирпичивания из-за битых блоков/байтов.

А как это "окирпичивание' может произойти? Боитесь что CRC32 случайно сойдётся?  :biggrin:

Ну тогда используйте Hash256, он точно никогда не совпадёт на мусоре.

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

ТАКОЕ может случиться разве что в радиоканале. Ну, еще на CD :)

Причём тут радиоканал, если ТС пишет про UART и CAN?  Перечитайте исходный пост.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, aleksandr-zh said:

Сперва грузить новую прошивку в flash, перезапуск, загрузчик проверяет: если данные в этой области достоверны, то грузит с неё, иначе - идёт на прошлую прошивку и в ней работает.

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

 

1 minute ago, jcxz said:

А как это "окирпичивание' может произойти? Боитесь что CRC32 случайно сойдётся?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, jcxz said:

. . . Причём тут радиоканал, если ТС пишет про UART и CAN?  Перечитайте исходный пост.

>>  Передача байтовый поток, либо блоками по ~64-бит с контрольной суммой каждый.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...