Доброе время суток!
Кто сталкивался в LPC210x с необходимостью управления битами паритета Mark и Space, для эмуляции 9-битного варианта передачи данных?
Пробовал делать путем ручного переключения этих битов и вылазит такая картина. В пошаговом режиме байты пересылаются нормально (отслеживаю по осцилу). Как только переходит в сплошной поток - то ли LPC не успевает переключаться, то ли еще что-то, но Mark и Space не изменяются.

Хоть я и противник программных решений, но ИМХО, тут лучше сделать UART самому. Или вставлять паузы между символами "потока".

Но ведь не хочется огород городить. В обычном COM порте работает такая штука. Даже в MSP есть. А тут вот такой "Кузьмич".

Мне эта тема тоже интересна. Филипс как всегда "прорвался" и сделал офигенный супер - пуппер чип с UART по какому-то там стандарту, в результате чего сделал недоступными функции независимого управления девятым битом. Как результат, этот чип, похоже, нельзя использовать для реализации шины MDB, а как хотелось бы. Очень интересно, если из этого что-нибудь получится. Я делал подобные вещи на более простом UART на микроконтроллерах P16F628 Microchip. Правда, это не имеет отношения к ARM.

Кстати, насчёт сделать UART самому - если хотите изобретать велосипед, готовьтесь быть аутсайдером Этот форум не для Вас.

По моему, Вы много на себя берете...
Для нормального программиста на МК - UART есть всегда. Вне зависимости от того, есть соответствующий аппаратный модуль или нет. Есть кварцевый генератор или используется встроенный, либо некалиброванный внешний. Программная реализация, нередко, занимает меньше места и работает надежнее, чем обслуживание встроенного UART-а. На тех же PIC-х я делал программый UART для всей линейки: PIC10-PIC12-PIC16, с автоподстройкой под текущую частоту генератора и c автоопределением скорости обмена от 4800 до 115200...
P.S. Если Вы никогда этого не делали и не знаете как (или делали один раз), то я бы на Вашем месте воздержался от оценок и советов на этом форуме.

Я это делал на том же PIC16F628. Мне нужно было 2 порта. Второй порт я сэмулировал, используя второй таймер и внешнее перывание. По старт биту срабатывает внешнее прерывание, затем в обработчике запускается второй таймер, дальше защёлкивание битов идёт уже по таймеру. Второй таймер очень удобен, если хотите, чтобы вообще что-то получилось. Помучался долго и сумел реализовать скорость 115200 при частоте кварца 18.432 MHz, причем задача стояла, чтобы это работало именно в прерываниях.
В своё время я писал аппаратные реализации драйверов загрузки с магнитной лентой, причем с необходимостью синхронного вывода графики на некий экран.
У меня есть собственные реализации алгоритма шифрования AES-128, который при чтении с COM порта расшифровывает поток "на лету".
Тему я хорошо знаю, поэтому не советую заниматься этой ботвой, если только вообще нечем заняться.

Один раз, хм... А сколько раз нужно на швабру наступать, если не один?

aerolog, не мучайтесь с этим UARTом, @Ark прав, используйте CAPTURE регистры. Здесь готовое решение: http://www.nxp.com/acrobat_download/applic...s/AN10689_1.pdf

Я Вам еще раз предлагаю воздержаться от оценок и советов, поскольку тему реализации программного UART-а
Вы не знаете (без обид). В экстремальном случае все делается и на 4МГц и даже без использования таймеров...
Но это крайний случай... Я просто Вам ответственно могу заявить - для нормального программера не бывает такой ситуации - нет UART-а. UART есть всегда! По определению.

Дело скорее всего в том, что там имеется FIFO, в которое попадают данные, но не бит управления четностью. Когда вы отлаживаете пошагово, байт успевает передаться и влияние FIFO незаметно. Надо отключить FIFO.

Споры - дело дурное. Каждый в любом случае останется при своём мнении. Очень интересно, получится ли управлять девятым битом. Сейчас мне заняться этим просто некогда, но если что-то выйдет, поделюсь. Соответственно, надеюсь, что тут будет опубликован результат, если у кого что получится.

P.S. А может, любезный @Ark найдёт решение? Спец же по портам Будем ему благодарны

aerolog, попробуйте, как говорит Сергей, отключить фифо и перед записью в THR выставлять требуемые значения битов Parity Select регистра LCR со включенным Parity Enable. Возможно перед этим нужно дожидаться, чтобы освободился буфер передатчика (установился бит THRE или TEMT (какой конкретно нужнопроверять).

Зачем же Вы плохое советуете?

Имеется в виду установить Trigger level 0 (1 character or 0x01). Неоднократо обсуждалось.

Это скажется на передаче?

Насчёт отключения FIFO. Вот вопрос: что будет, если в фифо несколько байт на передачу, а вы измените настройку Parity? Повлияет ли это на последующую передачу байта из FIFO, или это повлияет на данные, которые вы толкнёте в FIFO после этого? Мне кажется, скорее первое, чем второе.

Нет.

Если верить тому, что написано в ДШ на этот камень, его UART совместим по регистрам со стандартом 16550. В PC такой же UART стоит на COM-портах (точнее, стоял). Известная вещь. Берем описание и читаем...

Перед выбором режима управления четностью рекомендуется очистить очередь приемника и передатчика - установкой 1-го и 2-го бита соответственно в регистре управления буферизацией...
Кстати, управлять напрямую значением девятого бита нельзя, можно лишь выбрать один из режимов - контроль четности, контроль нечетности, нет контроля. Если в последнем случае задать 2 стоп бита, то девятый бит всегда будет 1...

Итого: если хотите самостоятельно управлять девятым битом, придется FIFO отключить совсем. Перед передачей каждого байта выбирать режим четность/нечетность таким образом, чтобы девятый бит принимал нужное значение... Короче - геморрой. Проще сделать программно...

Стоп... а как же вот это?:



Разве это не задание значения бита напрямую? Зачем 2 стоп-бита?

Найдите родной документ по УАРТУ. Будет он я думю Синопсисовским (можно и не найти) или АРМовским или может быть даже МЕНТОРовским(сомневаюсь). А совместимость с 16х50 вещь для корок относительная. У того же Синопсисиса хоть и заявлена но имеется пара-тройка мерзких деталей.

По моим данным (из описания 16550) значения битов 5-3 задают следующие режимы:

XX0 - нет контроля четности
001 - контроль четности
011 - контроль нечетности

отстальные значения зарезервированы.

По Вашей информации получается:

101 - девятый бит =1
111 - девятый бит =0

Противоречия нет. Есть возможность - задавате 9-й бит напрямую. Только я не уверен, что можно переключать режимы "на ходу". Скорее нет. Ведь для приема используется то же формат, что для передачи, и от него зависит ошибка четности и тест стоп-бита в конце.

P.S. Режим "2 стоп-бита без контроля четности" аналогичен 9-битному режиму с одним стоп-битом и с постоянным значением девятого бита 1.

А каким образом используется девятый бит? Сигнал команда/данные?

Выбросте это 'описание' и возьмите даташит. Эти режимы поддерживают не только 550 и клоны но и прадедушка 8250 с самого рождения.

Дергать ножками самое глупое решение из всех возможных вне зависимости от решаемой задачи. Нельзя пользоваться FIFO так на зло National Semiconductor не будем пользоваться и аппаратным сдвиговым регистром ....

Не аналогичен, ибо еще есть прием.

На самом деле при передаче там должно все получиться установкой для Fifo передачи trigger level 1. Тогда перед записью байта на передачу нужно установить либо Mark, либо Space parity.
Гораздо больший геморрой будет при разборе приема, помню, делал это на ПК. Если нужен полудуплекс, то это еще возможно, если дуплекс - то практически невероятно.

Честно говоря я совершенно не понял, откуда взялся процитированный вами кусок текста. Я же вроде бы достаточно подробно расписал - бит управления четностью не буферизуется в FIFO, поэтому FIFO надо выключить.

А разве этот параметр не для приема? На передачу можно или включить все FIFO, или выключить.

Это не по моей информации. Это по данным документации на конкретный чип, о котором здесь идёт речь, UM10161 rev 3.

Да пользуйтесь хоть ШИМ-мом. Лишь бы результат был. Технические решения не бывают "глупыми" или "умными".
Бывают простыми и сложными, эффективными и не эффективными, дорогими и дешевыми, и т.д. А Ваше личное отношение к ним - это Ваше личное дело...


Физические сигналы на линии будут аналогичны. Этого достаточно. Можете взять два UART-а в этих двух, формально различных, режимах и соединить между собой. Оба будут нормально работать и на прием и передачу.

Этого НЕ достаточно, ибо в этом режиме на приеме бит parity не обрабатываетя вообще.



Использование тех, которые начинаются c "не", а также дорогие и сложные и называюмся одним словом ГЛУПЫЕ (есть еще несколько синонимов, но этт помягче).

Любезный @Ark, возможно Вы и правы. только Ваш UART на 4-х мегагерцах должен тупо ждать стартового бита, а мой, хоть и на 18-и, но работает в фоне наверное в более сложных, по сравнению с Вашей, системах (не одной, заметьте!), переносим в другие проекты и является законченным универсальным решением. Может я, по Вашим словам, и не разбираюсь в этой теме, но читаю документацию и нахожу там то, чего Вы почему-то не видите (или читаете не то).

Если делать как попало, то легко ошибиться, кроме того, переносимость таких решений практически нулевая. Это имеет смысл только в очень больших партиях, где реально такое решение окупит труд программиста. В данном случае, если нет дуплекса, то можно посылать побайтно через имеющийся уарт, предварительно выставляя четность вручную. на приём придётся анализировать бит Parity Error и вычислять, какой же был 9 бит на самом деле.

Да, это я тормознул. Я имел ввиду - можно не писать Fifo на полную глубину, а записывать только по 1 байту, тогда после каждого прерывания Fifo будет пустым, и предварительно установив паритет можно, записав в Fifo только 1 символ добиться его передачи именно с нужным значением в 9-м бите.

Этого достаточно, так как бит четности всегда установлен 1. И как он формально обрабатывается - как 9-й
бит или один из стоп-битов - принципиального значения не имеет.

Воздержусь от дальнейшего спора на эту тему. У супермодераторов, конечно, есть право считать только свои решения УМНЫМИ.

Опять глупость

Ну и что? Когда можно и нужно использовать универсальные решения - я их использую, как и Вы. Есть встроенный UART и всем нас устраивает - замечательно! Используем его. А если его нет, что Вы будете делать? Или кварц нежелательно ставить в устройство из-за условий эксплуатации? Откажетесь от проекта? Я, в отличие от Вас, свободен в выборе технических решений, как универсальных, так и узкоспециализированных. В этом вся разница...



Видимо, взаимная...

Я, конечно, извиняюсь перед всеми за оффтоп (это не тема обсуждения), но кто сказал, что я не свободен в выборе технических решений? Делать глупые вещи (придётся согласиться с супермодератором) - это такая свобода что ли? Да это хрень полная. Ну давайте писать Windows на ассемблере, дрыгать ногами чипов, вместо того, чтобы зайти в интернет, и увидеть, что в продаже уже появился новый чип в 5 раз дешевле и с количеством портов в 3 раза больше. Я считаю себя свободным, потому что вместо того, чтобы заниматься ботвой, смотрю, что вокруг. Я уже предлагал ссылку выше на готовое решение. Не нравится, давайте сначала разберёмся хотя бы с тем, что есть на борту. Почитаем даташит.

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

Большое спасибо за такое бурное обсуждение.
Пробовал отключать ФИФО и ставить размер 1 - все равно при RealTime выполнении если я в начале установил Бит Mark - то он потом не сбрасывается, хотя явным видом вызывается сброс тех самых битов управления.
Интересная ситуация наблюдается когда разрешается проверка четности, порт пердачи уходит в 1, и зависает??? До сих пор не могу найти адекватного ответа.

Вот такие результаты проверки всех предложений.
Какие будут еще варианты?

А софтовое решение никто не рубает на корню, просто хотелось использовать внутренние свойства.

А 9-й бит действительно используется при работе с MDB протоколом, там необходимо с единицей в 9-м бите посылать адрес, а с нулем идут данные.

aerolog, к сожалению у меня сейчас осцильник подох, сам проверить не могу.

Нужно делать так:

Передача:

1. Программируем порт на 8 бит и т.д.
2. Цикл:
- в LCR выставляем бит 3 (разрешение 9-го бита) и комбинацию битов 4,5 Forcedstick parity, которая должна соответствовать последующему байту.
- записываем последующий байт в THR
- ждём, когда в регистре LSR бит 6 станет 1
3. переход на пункт 2, если данные не кончились.

Приём:
1. Программируем FIFO trigger level = 1, контроль четности Forced "0" stick parity.
2. Принимаем байт (жём бит 0 в LSR). Если видим ошибку "Parity error", то это означает, что 9-й принятый бит равен 1, иначе 0.
3. переход на 2, если нужны ещё данные.

Забыл добавить: при отладке НЕЛЬЗЯ наблюдать регистры UART в отладчике (т.к. отладчик будет считывать регистры UART сам, чтобы отобразить на экране, и при продолжении выполнения программы результат будет совсем другой). Это означает, что их нужно исключить регистры UART с вкладки Watch и не отображать на вкладку UART0 (или UART1) отладчика. Возможно, что-то не работает именно из-за этого?

Жаль IgorMarx, но такой вариант тоже не прокатыает.
Может это проц глюкнутый?

А можете сделать небольшой тестовый проект и показать, как Вы делаете?