хм, решается походу, ну так, чисто теоретический интерес. Переходим на передачу вместо байтов допустим 10(0000) байтовых пакетов. Тоесть на не 8битовые байты, тогда будет оверхед в виде одного бита в пакете, но и придется передавать большие пакеты пустые

Комментарии: 19

  1. Maxim

    У тебя снова всплывает проблема синхронизации начала передачи этого пакета

    • Anonim

      не всплывает, в данном случае пакет уже будет структурой из этих 10битных "подпакетов-байтов"

      • Maxim

        Как ты защищаешься от того, что контроллер начнет твои 10-байтовые "символы" с середины интерпретировать?

        • Dmitry

          base64 лучше, чем base128 — оно более-менее однозначно читается и для текстовой среды, коим, по логике является юарт, идейно подходит плюс имеется маркер = того, что это base64 единственное, что нет CRC. но это уже перестраховка

          • Petr

            Кроме бейз64 есть ещё бейз37 и прочие извращения

            • Dmitry

              ну так можно вообще в хексе гнать

              • Petr

                См. Нмеа0183

        • Anonim

          хм, и правда, протокол вышестоящего уровня не поможет. ну тогда оверхед для кодировки в 1 бит на байт

          • Dmitry

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

            • Maxim

              Тут больше вопрос в том, что если данные идут тугой струей - то очень маловероятно, что они идут по UART :D

              • Anonim

                либо вероятнстный меджик. Хотя все равно все вероятностное, даже tcp

                • Maxim

                  Для этого есть более приспособленные интерфейсы типа SPI, где начало транзакции явно сигнализируется

                  • Anonim

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

                    • Maxim

                      Ну с таким подходом даже криптография вероятностная, вдруг ты случайно правильный хеш угадаешь Я имел в виду вероятность в разрезе входных данных, а не в разрезе помех Плохи те протоколы, где есть ломающие входные данные Ломающие помехи - бывают, да

              • Dmitry

                а если они на компьютер гонятся? тут или вариация юарта, или эзернет, или реализовывать свой юсб девайс

                • Anonim

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

                  • Maxim

                    Так там как раз ломающие входные данные. Для конфигурирования девайсов м.б. норм, но не универсальные

                    • Anonim

                      ну ломающая только сигнатура, я предлагаю [меджик][длина][crc][данные] чтоб такое сломать в данных должен попасться второй валидный пакет с меджик и валидной длиной и crc

                • Maxim

                  Ну, тут самое адекватное - реализовать USB, мимикрирующий под UART. Проебывать фрагменты он не будет, а драйверов все еще не надо

Не нашли ответ?

Вам также может быть интересно