Вопрос по формату кадра UART в ATmega-х, Может быть одновременно и Bit8 и P Опции

[Дон Амброзио]

Тут с одним поспорили. Он говорит, что по даташифту в кадре UART не может быть более 9 бит. Я же говорю, что может быть 10 (имеется ввиду информационных бит, а не служебных). А он говорит, что нельзя использовать в кадре сразу и Bit8 и бит чётности - P. А я говорю, что можно. Кто прав?

ST + Bit0 + Bit1 + Bit2 + Bit3 + Bit4 + Bit5 + Bit6 + Bit7 + Bit8 + P + SP1 + SP2

[SasaVitebsk]

По-моему, это всё с х51 пошло. Именно там 9 бит пошёл как информационный, для упрощения. Аппаратная чётность там была только для аккумулятора. То есть при таком подходе этот бит можно было заюзать под чётность. Но, соответственно можно было и заюзать как самостоятельный бит. Ну и некоторые повелись в связи с простотой картины. Хотя, при размере фрейма 512 байт, к примеру, избыточность такого подхода составит 512 бит, что соответствует 64 байтам. Что явно превышает избыточность любого протокола с байт стафингом.

Я один раз, уже на AVR применял такой подход, так как до этого применял параллельный 9 битный интерфейс (один бит - указатель комманды). А потом, с целью экономии ног перешёл к последовательному интерфейсу. А бит остался. Следующий переход - SPI+байт потери -> вообще перенёс всё в один МК.

Всё таки считаю лучше применять стандартные решения.

[zltigo]

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

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Всё таки считаю лучше применять стандартные решения.

Лучше то, что лучше в конкретных условиях. Для связки с мелкой CPLD байтстафинг явно менее предподчтителен. Для связки вспомогательного контроллера с основным в пределах одной платы тоже следует подумать, причем и для случая SPI в том числе. Ну за SLIP, меня агитировать не надо - я и сам кого угодно сагитирую, если нужно будет, что даже на этом форуме не раз проделывал . Ну HDLC с его битстафингом это тоже близкое и родное для любого разработчика коммуникационного оборудования.

[svs39]

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Лучше то, что лучше в конкретных условиях. Для связки с мелкой CPLD байтстафинг явно менее предподчтителен. Для связки вспомогательного контроллера с основным в пределах одной платы тоже следует подумать, причем и для случая SPI в том числе. Ну за SLIP, меня агитировать не надо - я и сам кого угодно сагитирую, если нужно будет, что даже на этом форуме не раз проделывал . Ну HDLC с его битстафингом это тоже близкое и родное для любого разработчика коммуникационного оборудования.

1) помогите-чем хорош SLIP?
2) HDLC- синхронный поток- достал в свое время (сделали в 1985г на серии 580 - до сих пор работает)

[zltigo]

1) помогите-чем хорош SLIP?

Классический пример байтстафинга, позволяющий в потоке (бинарном) байтов зарезервировать уникальный байт в качестве разделителя фреймов. Дальше естественно просто и надежно выделяются и востанавливаются фреймы в потоке. Есть более навороченные вариации на тему SLIP, позволяюшие еще минимизировать количество вставляемых байтов.

[svs39]

Классический пример байтстафинга, позволяющий в потоке (бинарном) байтов зарезервировать уникальный байт в качестве разделителя фреймов. Дальше естественно просто и надежно выделяются и востанавливаются фреймы в потоке. Есть более навороченные вариации на тему SLIP, позволяюшие еще минимизировать количество вставляемых байтов.

почему не использовать более простой байтстафинг - удваивать в данных уникальный байт?

Именно так.

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

Например, если передаётся большой пакет (например 1024 байта) с CRC32. А контроллер мелкий и он долго считает CRC. В этом случае обнаружение покоцанного байта позволяет избежать долгой и мучительной процедуры вычисления CRC32 для такого большого пакета... Но повторяю, это для "мелких" контроллеров с малым быстродействием

бит четности в байте совместо с байтом "продольной" суммы использовался при матричной кодозащите, например, в протколах обмена ВМО(Всимирной Метеорологической Озганизации) в 1960-1980гг.