Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
21 апреля

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Микроконтроллеры

1152258 Топик полностью

ir0407 (07.12.2021 09:55, просмотров: 395) ответил Argon на Спасибо, да, похоже на то что нужно. Многабукаф ->

Вариант от Максим. -> https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5947.html

Ответить

- Там про SSI, не SSP. Наверное что-то другое, и слова stuffing нет в тексте. - Argon(07.12.2021 10:02)
  - Зато простенько, со вкусом и с исходниками, которые под свои хотелки завсегда ~~паламать~~ подправить можно.:) - ir0407(07.12.2021 10:35)
    - Да я уже на байт-стаффинг нацелился, уж очень не хочется учитывать паузы при приеме. - Argon(07.12.2021 11:05)
      - Паузы при приеме в протоколах типа "запрос-ответ" получаются естественным путем, мастер вынужден ждать ответа, особенно в каналах с общей средой, типа RS-485. Байт-стаффинг может быть интересен, когда есть отдельные каналы для передачи и передаваемая информация, в основном, формируется не в стиле запрос-ответ. - AlexBi(07.12.2021 12:12)
        
        Я, может, сгущаю краски, но один из моих девайсов теоретически может взять паузу на середине своей передачи или приема. Так что некоторые паузы не будут "естественными". - Argon(07.12.2021 12:21)
        
        Заложите эту паузу в свой протокол, т.е. пусть в протоколе будет пауза больше чем может быть из-за особенностей девайса. А если такие события редкие, то паузу можно не увеличивать, а такие событие обрабатывать как дефекты связи. Все равно пауза при приеме приведет к потере данных и это надо как-то обрабатывать. - AlexBi(07.12.2021 16:02)
        
        Предполагаю, что пауза не приведет к потере данных, а приведет к лагу внутри пакета. Точные диапазоны этих пауз не знаю, допустим порядка 300-500 мс, если в протокол закладывать такой порядок, то это будет как-то совсем печально. Лучше уж я попытаюсь вот эти относительно редкие события купировать "на лету" с помощью паузоустойчивого протокола. Argon(95 знак., 07.12.2021 18:02)
        
        Пауза при передаче приведет к лагу, пауза при приеме приведет к потере принятого у приемника. Или должен быть какой-то механизм, останавливающий передатчик, пока приемник занят чем-то своим. Но такого не планируется, как я понимаю, поэтому потери неизбежны и к этому надо быть готовым. AlexBi(405 знак., 07.12.2021 19:29)
        
        Неа, пауза при приеме не должна привести к потере принятого у приемника (одноплатник с ОС Android), ибо если я верно понимаю, то данные таки примутся драйвером, который является частью ядра Linux. В то время как сборщик мусора работает в среде dalvik (аналог Java runtime) и тормозит мое приложение, которое и обрабатывает прием-передачу. Argon(652 знак., 07.12.2021 20:38)
        
        А когда одноплатник будет передатчиком и будет сливать большой объем данных (100К и более), то приемником можем наловить нерегулярных пауз по той же самой причине с более чем нулевой вероятностью. И лучше бы эти паузы победить логикой самого протокола. Байт-стаффинг, по-моему то самое. - Argon(07.12.2021 20:54)
        
        Если там такой умный драйвер, то и при передаче пауз не будет, т.к. скорее всего передача делается так: в буфере готовится что надо передать, потом активируется драйвер, который передает весь буфер подряд, без пауз. AlexBi(386 знак., 07.12.2021 22:07)
        
        Я бы все же ввел какой-либо критерий по длительности паузы в передаче, как признак "битого" пакета данных. Для надежности. - rezident(07.12.2021 21:43)