По завершению приёма символа копируете за 16 тактов данные из регистра данных USART в однобайтовый буфер ОЗУ. И дальше работаете с символом в однобайтном буфере ОЗУ 16х8 (для 8N1) тактов. Тем временем следующий символ считывается в регистр данных USART.
Если говорить о передаче данных в узком смысле, то современный UART в большей мере является протоколом передачи команд и в меньшей - протоколом передачи данных (в смысле, большого объёма однородных данных - видеопотока, скажем).
Да, есть ситуации, когда определённые команды временно не возможны к исполнению устройством. Воображаемый пример: нельзя выполнять команду раскручивания аэростатического подшипника, если в него не подано достаточное давление. Если мы по Tx подаём подряд команды "подать давление в пневматику" и "раскрутить подшипник", то было бы разумным получить по Rx в ответ на вторую команду код ошибки - почему команда "раскрутить подшипник" не может быть сейчас выполнена. Объявление неготовности устройства через CTS здесь кажется более чем неуместным.
Если мы говорим о передаче потока данных, то, положа руку на сердце, можете ли вы сказать, что сейчас есть устройства, которые могут не успеть как-то там переварить данные от потока 9600 бит/с так, что придётся его временно останавливать? Да и даже 12 Мбит/с. Я пытаюсь, но не могу придумать ни класс таких устройств, ни хотя бы какое-то уникальное устройство. Если вы назовёте пример, пусть даже и умозрительный, мне будет весьма любопытно его прочитать.
При этом исторически, назначение подобных выводов более чем понятно. Когда нужно было переливать, скажем, 115200 бит/с в 9600 бит/с и наоборот, тут без квитирования никак. Да, UART вырос из модемов. А для модемов подобный функционал - RTS/CTS - более чем полезен. Но это всё в прошлом.
Вот за это я и не очень люблю все эти дополнительные линии как в статьях, так и в практике:
Сначала долго разбираемся в их штатном функционале.
Затем внезапно понимаем, что штатный функционал глубоко историчен.
Начинаем использовать их как GPIO0 и GPIO1 для абсолютно произвольных назначений. Но только без IO - либо "I", либо "O".
А когда нам требуется GPIO2, понимаем, что GPIO2 взять неоткуда и этот функционал всё равно нужно реализовывать поверх символов UART-а.
Я осознаю, что желание стройности, унификации и единообразия - это определённый снобизм и что почти все стандарты изрезаны временем, временными наколеночными решениями, которые стали чем-то на редкость постоянным. Но. Веет от этих дополнительных линий RTS/CTS/DTR/DSR брючным ремнём, накинутым на валы взамен лопнувшей штатной ременной передачи :)
Всё, что приходит по Rx, теоретически, можно буферизировать и ковыряться с ним весь следующий символ. Какая разница, выявит CRC сбой за паузу между символами или выявит в течение следующего символа? Всё равно - перепосылать.
Так что у операций между символами должно быть дополнительное, внешнее обоснование.
у CH340N в корпусе SOP-8 есть только RTS (очевидно в SOIC-8/SOP-8 физически не засунуть сразу все RTS/CTS/DTR/DSR)
у PL2303GL в корпусе SOP-8 после раскидывания шести обязательных выводов D+/D-/Tx/Rx/Vin/GND на оставшиеся два свободных инженеры повесили выход LDO и Vddio
у MCP2221A несмотря на то, что выводов хватает, нет ни одного вывода из RTS/CTS/DTR/DSR
у CP2102N-A02-GQFN20 есть RTS/CTS, но нет DTR/DSR
И мне любопытно, в тех любительских радиостанциях, о которых вы говорите, наличие у моста выводов RTS/CTS/DTR/DSR является обязательным или опциональным? То есть возможно ли управлять данными радиостанциями при помощи исключительно команд, передающихся через Tx?
В любом случае, я осознаю, что в индустрии имеется оборудование, которое в силу исторических причин требует наличия данных выводов. Однако, по моему субъективному и претенциозному мнению, в новом, проектируемом оборудовании от использования данных линий стоит отказываться.
Соответственно, поддержка этих линий отладочными платами более чем интересна, хоть и немного выходит за рамки голого UART, вторгаясь уже в RS-232.
Тут ещё как знать, кто более голый: UART, у которого отсутствует формализованный стандарт (UART - это просто набор традиций) или RS-232, который содержит электрические параметры, размеры разъёмов и наименование выводов, но не содержит ни правил передачи, ни стандартных битрейтов, ни стандартных длин символов :)
Предположим, имеется классическая ATmega328P и требуется выжать из неё максимальную пропускную способность. Напрашивающимся решением является повысить битрейт на столько, на сколько это возможно. Битрейт в данных МК определяется делителем UBRR. Чтобы выжать из ATmega328P максимальный битрейт необходимо понизить делитель частоты UBRR как можно ниже. Но. При низких значениях UBRR его изменение будет весьма резко изменять битрейт. При UBRR равном двум, битрейт будет равен f/16. При UBRR равном трём, битрейт будет равен f/32. При UBRR равном четырём, битрейт будет равен f/48. Теперь представим, что символы приходят непрерывным потоком. При максимальном битрейте и символе 8N1 у ATmega328P будет 16 тактов между символами, чтобы обработать очередной символ. Если на обработку требуется, скажем, 20 тактов, то понижение битрейта понизит пропускную способность на 50%. А добавление ещё одного стоп-бита понизит её всего на 11%
Справедливым является вопрос: так ли уж надо обрабатывать очередной символ сразу же после его прихода? Не проще ли его скопировать в память, 16 тактов на это должно хватить, а затем обрабатывать столько, сколько идёт следующий символ? Да, проще - если данные между устройствами передаются длинными пакетами. Но если имеется подобие адресации (одно устройство передало один символ с адресом некоего регистра, второе - передаёт/возвращает данные из этого регистра) то в предельном случае такая конфигурация "отъедает" 33% пропускной способности (один символ - туда, один символ - ожидание/обработка, один символ - обратно). И тогда потеря 11% будет более предпочтительна.
На мой взгляд, субъективный и претенциозный, двойной стоп-бит - это архаика и экономия на спичках в ущерб единообразию.
Но я с интересом прочитаю любое другое объяснение применимости двойного стоп-бита, если оно будет обосновано весомыми аргументами.
Если расскажете про то, как можно было бы максимально корректно оттестировать этот аспект, то может быть (когда-нибудь) я дополню данную статью и таким исследованием. Платы у меня есть, микросхемы есть, почему бы и не? :)
Знакомые, вычитывавшие статью перед публикацией говорили, что чтение идёт очень непросто. Так что подобное не было неожиданностью для меня. Ваше удивление, в том числе, подтверждает, что в сфере РЧ/СВЧ синдром "проклятия знания" является бичом. Что уж там, я и сам написал первый вариант так, что один мой рецензент сказал "ничего не понятно и абсолютно не интересно". А мне казалось что-то вроде "ну пффф, 2 мВт, это, очевидно же, 3,01 дБм".
С другой стороны, хорошо, что комьюнити Хабра состоит из высококвалифицированных специалистов, которые могут затронуть в комментариях те аспекты, о которых по тем или иным причинам нет возможности упомянуть в статье. В частности, про фактическое сращивание подходов ВОЛС и СВЧ.
Если мы говорим о вносимых потерях, то децибелы показывают сколько мощности вышло из устройства в сравнении с мощностью, которая в него зашла. 0 дБ означает, что P2/P1 равно единице. То есть мощность проходит через устройство без потерь. Если мы соединяем два устройства, на которых мощность не теряется в одно устройство, то такое устройство тоже будет пропускать мощность полностью.
Другое дело, если вопрос звучит так: "сколько будет 0 дБм + 0 дБм" и под плюсом мы понимаем арифметическое сложение мощностей. В линейных величинах такой вопрос сформулируется как "сколько будет 1 мВт + 1 мВт". Очевидно, будет 2 мВт. Если же перевести 2 мВт в децибел-милливатты - это будет 3,01 дБм. Парадокс? :) Не совсем. Как было написано в конце первого раздела статьи - суммирование величин, выраженных в логарифмической форме столь же неприятно, как и подсчёт сложных процентов от величин, выраженных в линейной форме.
Как вопрос на экзамене или на собеседовании, ваш вопрос вполне неплох :)
А еще S-параметры являются комплексными числами. Но в первом приближении, по моему глубоко субъективному и тенденциозному мнению, ни о том ни о другом факте лучше не упоминать. Иначе читатель, впервые читающий об S-параметрах и децибелах закончит чтение статьи именно на этом месте.
Кстати, лютый оффтоп: а как в хаброредакторе камента сделать тескту нижний регистр?
Не знаю. Я пишу статьи в LibreOffice Writer, а затем копирую по отдельным абзацам в редактор Хабра. Там и типографский символ "минус", и неразрывные пробелы между величиной и её обозначением удобнее вставлять. И на корректуру отдавать сподручнее.
О 16 тактах на бит. При 16 тактах на байт добавление/убавление второго стоп-бита погоды не сделает ни в каком случае.
По завершению приёма символа копируете за 16 тактов данные из регистра данных USART в однобайтовый буфер ОЗУ. И дальше работаете с символом в однобайтном буфере ОЗУ 16х8 (для 8N1) тактов. Тем временем следующий символ считывается в регистр данных USART.
Любопытный кейс. Спасибо!
Забуферизировать надо только один символ.
Если говорить о передаче данных в узком смысле, то современный UART в большей мере является протоколом передачи команд и в меньшей - протоколом передачи данных (в смысле, большого объёма однородных данных - видеопотока, скажем).
Да, есть ситуации, когда определённые команды временно не возможны к исполнению устройством. Воображаемый пример: нельзя выполнять команду раскручивания аэростатического подшипника, если в него не подано достаточное давление. Если мы по Tx подаём подряд команды "подать давление в пневматику" и "раскрутить подшипник", то было бы разумным получить по Rx в ответ на вторую команду код ошибки - почему команда "раскрутить подшипник" не может быть сейчас выполнена. Объявление неготовности устройства через CTS здесь кажется более чем неуместным.
Если мы говорим о передаче потока данных, то, положа руку на сердце, можете ли вы сказать, что сейчас есть устройства, которые могут не успеть как-то там переварить данные от потока 9600 бит/с так, что придётся его временно останавливать? Да и даже 12 Мбит/с. Я пытаюсь, но не могу придумать ни класс таких устройств, ни хотя бы какое-то уникальное устройство. Если вы назовёте пример, пусть даже и умозрительный, мне будет весьма любопытно его прочитать.
При этом исторически, назначение подобных выводов более чем понятно. Когда нужно было переливать, скажем, 115200 бит/с в 9600 бит/с и наоборот, тут без квитирования никак. Да, UART вырос из модемов. А для модемов подобный функционал - RTS/CTS - более чем полезен. Но это всё в прошлом.
Вот за это я и не очень люблю все эти дополнительные линии как в статьях, так и в практике:
Сначала долго разбираемся в их штатном функционале.
Затем внезапно понимаем, что штатный функционал глубоко историчен.
Начинаем использовать их как GPIO0 и GPIO1 для абсолютно произвольных назначений. Но только без IO - либо "I", либо "O".
А когда нам требуется GPIO2, понимаем, что GPIO2 взять неоткуда и этот функционал всё равно нужно реализовывать поверх символов UART-а.
Я осознаю, что желание стройности, унификации и единообразия - это определённый снобизм и что почти все стандарты изрезаны временем, временными наколеночными решениями, которые стали чем-то на редкость постоянным. Но. Веет от этих дополнительных линий RTS/CTS/DTR/DSR брючным ремнём, накинутым на валы взамен лопнувшей штатной ременной передачи :)
Приятно слышать!
Спасибо, что читаете. Про сброс отпишусь чуть позднее.
Всё, что приходит по Rx, теоретически, можно буферизировать и ковыряться с ним весь следующий символ. Какая разница, выявит CRC сбой за паузу между символами или выявит в течение следующего символа? Всё равно - перепосылать.
Так что у операций между символами должно быть дополнительное, внешнее обоснование.
Хотел бы отметить. Среди рассматриваемых мостов:
у CH340N в корпусе SOP-8 есть только RTS (очевидно в SOIC-8/SOP-8 физически не засунуть сразу все RTS/CTS/DTR/DSR)
у PL2303GL в корпусе SOP-8 после раскидывания шести обязательных выводов D+/D-/Tx/Rx/Vin/GND на оставшиеся два свободных инженеры повесили выход LDO и Vddio
у MCP2221A несмотря на то, что выводов хватает, нет ни одного вывода из RTS/CTS/DTR/DSR
у CP2102N-A02-GQFN20 есть RTS/CTS, но нет DTR/DSR
И мне любопытно, в тех любительских радиостанциях, о которых вы говорите, наличие у моста выводов RTS/CTS/DTR/DSR является обязательным или опциональным? То есть возможно ли управлять данными радиостанциями при помощи исключительно команд, передающихся через Tx?
В любом случае, я осознаю, что в индустрии имеется оборудование, которое в силу исторических причин требует наличия данных выводов. Однако, по моему субъективному и претенциозному мнению, в новом, проектируемом оборудовании от использования данных линий стоит отказываться.
Тут ещё как знать, кто более голый: UART, у которого отсутствует формализованный стандарт (UART - это просто набор традиций) или RS-232, который содержит электрические параметры, размеры разъёмов и наименование выводов, но не содержит ни правил передачи, ни стандартных битрейтов, ни стандартных длин символов :)
Предположим, имеется классическая ATmega328P и требуется выжать из неё максимальную пропускную способность. Напрашивающимся решением является повысить битрейт на столько, на сколько это возможно. Битрейт в данных МК определяется делителем UBRR. Чтобы выжать из ATmega328P максимальный битрейт необходимо понизить делитель частоты UBRR как можно ниже. Но. При низких значениях UBRR его изменение будет весьма резко изменять битрейт.
При UBRR равном двум, битрейт будет равен f/16.
При UBRR равном трём, битрейт будет равен f/32.
При UBRR равном четырём, битрейт будет равен f/48.
Теперь представим, что символы приходят непрерывным потоком. При максимальном битрейте и символе 8N1 у ATmega328P будет 16 тактов между символами, чтобы обработать очередной символ. Если на обработку требуется, скажем, 20 тактов, то понижение битрейта понизит пропускную способность на 50%. А добавление ещё одного стоп-бита понизит её всего на 11%
Справедливым является вопрос: так ли уж надо обрабатывать очередной символ сразу же после его прихода? Не проще ли его скопировать в память, 16 тактов на это должно хватить, а затем обрабатывать столько, сколько идёт следующий символ? Да, проще - если данные между устройствами передаются длинными пакетами. Но если имеется подобие адресации (одно устройство передало один символ с адресом некоего регистра, второе - передаёт/возвращает данные из этого регистра) то в предельном случае такая конфигурация "отъедает" 33% пропускной способности (один символ - туда, один символ - ожидание/обработка, один символ - обратно). И тогда потеря 11% будет более предпочтительна.
На мой взгляд, субъективный и претенциозный, двойной стоп-бит - это архаика и экономия на спичках в ущерб единообразию.
Но я с интересом прочитаю любое другое объяснение применимости двойного стоп-бита, если оно будет обосновано весомыми аргументами.
Если расскажете про то, как можно было бы максимально корректно оттестировать этот аспект, то может быть (когда-нибудь) я дополню данную статью и таким исследованием. Платы у меня есть, микросхемы есть, почему бы и не? :)
Вы верно поняли отсылку :)
Знакомые, вычитывавшие статью перед публикацией говорили, что чтение идёт очень непросто. Так что подобное не было неожиданностью для меня. Ваше удивление, в том числе, подтверждает, что в сфере РЧ/СВЧ синдром "проклятия знания" является бичом. Что уж там, я и сам написал первый вариант так, что один мой рецензент сказал "ничего не понятно и абсолютно не интересно". А мне казалось что-то вроде "ну пффф, 2 мВт, это, очевидно же, 3,01 дБм".
С другой стороны, хорошо, что комьюнити Хабра состоит из высококвалифицированных специалистов, которые могут затронуть в комментариях те аспекты, о которых по тем или иным причинам нет возможности упомянуть в статье. В частности, про фактическое сращивание подходов ВОЛС и СВЧ.
Ниже отписался.
И, это самое, вы из одной лаборатории? :)
Статье и так влепили один минус по пункту "ничего не понял после прочтения", а вы тут говорите про 20log10(V1/V2), dBi и QAM-16 :)
В общем случае данный вопрос не имеет короткого и простого ответа и будет освещаться в следующей статье цикла.
0дБ и будет.
Если мы говорим о вносимых потерях, то децибелы показывают сколько мощности вышло из устройства в сравнении с мощностью, которая в него зашла. 0 дБ означает, что P2/P1 равно единице. То есть мощность проходит через устройство без потерь. Если мы соединяем два устройства, на которых мощность не теряется в одно устройство, то такое устройство тоже будет пропускать мощность полностью.
Другое дело, если вопрос звучит так: "сколько будет 0 дБм + 0 дБм" и под плюсом мы понимаем арифметическое сложение мощностей. В линейных величинах такой вопрос сформулируется как "сколько будет 1 мВт + 1 мВт". Очевидно, будет 2 мВт. Если же перевести 2 мВт в децибел-милливатты - это будет 3,01 дБм. Парадокс? :) Не совсем. Как было написано в конце первого раздела статьи - суммирование величин, выраженных в логарифмической форме столь же неприятно, как и подсчёт сложных процентов от величин, выраженных в линейной форме.
Как вопрос на экзамене или на собеседовании, ваш вопрос вполне неплох :)
А еще S-параметры являются комплексными числами. Но в первом приближении, по моему глубоко субъективному и тенденциозному мнению, ни о том ни о другом факте лучше не упоминать. Иначе читатель, впервые читающий об S-параметрах и децибелах закончит чтение статьи именно на этом месте.
)))))
Не знаю. Я пишу статьи в LibreOffice Writer, а затем копирую по отдельным абзацам в редактор Хабра. Там и типографский символ "минус", и неразрывные пробелы между величиной и её обозначением удобнее вставлять. И на корректуру отдавать сподручнее.
В обсуждаемой статье даже мм... ресничек нет. В этом-то вся проблема - даже они отсутствуют! :)