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

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

Извеняюсь может не в тему. Вот здесь проект http://www.microsyl.com/moodlight/moodlight.html в котором одно мастер-устройство управляет яркостью яркостью RGB-светодиодов, подключенных к слейв-устройствам. Используется какой-то простой протакол, но мне всеравно не совсем понятно, как формируется начало кадра и как каждое слейв-устройство выделяет свой адрес. Насколько я понял вот кусок кода отвечающий за это:
void SerialRx(void)
{
static int Pointer;
ushort Byte;

Pointer++;

if (UCR & (1<<RXB8))
{
Pointer = 0;
Byte = UDR;
}

if (Pointer == ((Address * 3) - 2)) Red = UDR;
else if (Pointer == ((Address * 3) - 1)) Green = UDR;
else if (Pointer == ((Address * 3) - 0)) Blue = UDR;
else Byte = UDR;
}

По идее автор темы сам может её закрыть. Или я кое-что подзабыл? Посмотрите внимательно есть ли ы Вас такая возможность.
Будете настаивать - закрою, но по-моему продолжение пошло.

насколько я ничего не понимаю,это как раз использован режим UARTа MPCM.Взведен 9 бит
if (UCR & (1<<RXB8)) -пришел маркер начала фрейма.А вот дальше не совсем понятно-ху есть Address?
В коде намеков не просматривается,где-то он должен фигурировать в другом месте,поищите.
Понятно только,что посылки кратны 3.

Мне кажется, здесь всё достаточно прозрачно. Каждый слейв имеет свой собственный адрес, который находится в переменной Address. По приходу байта с взведённым RXB8=1, все слейвы сбрасывают указатель Pointer в 0. Начиная со следующего байта слейвы увеличивают указатель и сравнивают номер байта со своим утроенным адресом (плюс 0, плюс 1 и плюс 2). При совпадении принятый байт попадает в соответствующую переменную (Red, Green, Blue). Вот и весь протокол.

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

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

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

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

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

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

Золотые слова.

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

Выше я объяснял как кажущееся кое-кому извращением ( за которое инженера "нужно гнать поганой метлой из разработчиков") использование бита чётности в качестве обычного бита данных оказалось наиболее оптимальным решением для описанной мной конкретной задачи.

Я не имел ввиду конкетно Ваш пример. Я брал общий случай. Контроль чётности не применяю обычно. Но был случай, когда в битовом потоке применял код Хеминга. Естественно, необходимо учитывать специфику...



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

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

Кстати, да.
По большому счету, наличие контроля четности имеет смысл, если это поддерживается протоколом, когда получатель может оборвать передающую сторону. А это бывает, по моей статистике, в 3% протоколов.
Если нет, да еще блоки данных большие, то при использовании более сложной CRC контроль четности каждого байта не нужен.

Именно так.

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


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

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

Сообщение отредактировал Дон Амброзио - Mar 21 2008, 07:47

Трудно возразить - если поддерживается, то нужно, а если не поддерживается, то не нужно

Или оборвать, или просто проигнорировать. И SLIP и CRC это конечно хорошо, и еще лучше (навороченей) есть и вообще нет и не будет предела совершеству. Но как минималистичный вариант поток байтов со старым, добрым, поддерживаемым аппаратно битом четности и c уникальным 9bit разделителем фреймов совершенно нормален и не является наказуемым извращением.

Большие блоки данных - "большим устройствам" - копили, обрабатывали и послали и не дай бог пропадет труд. Для мелочевки это обычно не характерно - чаще сыпет хоть и много, но мелких. Если что случилось - проще заново спросить (или сам повторит), чем переспрашивать а чего-там было до того как...

Точно так! После х51 перешли на AVR, и для приемственности со старыми устройствами используем 9-й бит в том виде, как почти так описАл zltigo.

+1. Полностью согласен.

А Вы посмотрите, как общаются между собой Люди. Как Вы определяете, что собеседник закончил фразу и настала очередь Вам отвечать? Собеседник выдержал паузу? Или он сказал - "Конец цитаты"? Или ему вообще нечего сказать?

Нет - не надо все "валить" на 51 . Там просто подстраивались под необходимость с одной стороны его иметь, а с другой стороны сделать экстремально просто аппаратно. Например, "ручное" управление битом четности вполне естественно реализовано и на классических 8250 работающих начиная с 8080 и до всех нынешних PCшек.