C LPC не работал, но у SAMa тоже тараканов хватает - из самых заметных - прибацанный I2C, глюки в ШИМе, последний (ноябрьский) финт с ватчдогом. Вобщем, оптимизм поводу тотальной АРМизации поубавился, где возможно использую Меги.

Совет мигрирующим - начинать чтение даташита с эрраты.
Избавит от излишнего оптимизма

Давно пора уже привыкнуть, что DASM любит катать бочки во все стороны и причем, как правило, не по делу . Не берите в голову.


Характерная особенность 550 UART, что в нем глюков нет все исправлены за десятиления

Это точно - не баги, а фичи
...Если долго гладить против шерсти, то шерсть уляжется, и будешь гладить по шерсти...(С)

А почему множественное число? Если серьезно, то из наблюдаемых мной достаточно многочисленных попыток "наехать" на '550' в конце концов "проблемы" сводились к невозможности узнать количество cвободного места в TxFIFO в призвольный момент времени. Откуда это "фича" идет - прнятно - от совместимости с '50', который FIFO не имел. Обходится легко, как в Embedded железках, так и на любом PC c тем-же '550' на борту. Собствено отсутствие особой проблемы подчеркивается и тем, что продвинутых '550' выпускается достаточно много - увеличивают размеры FIFO, скорости под мегабит, аппаратный RTS/CTS, автодетект скоростей... Но остального не меняют.
Еще имеете "проблемы"?

Отсутствие FIFO для LSR - нельзя доверять всему содержимому FIFO приёма при, например, FE, т.е. нужно обходить ситуации, когда под конец длинного пакета в линии уже может появиться мусор - самый простой способ, ИМХО, - вырубать это FIFO. Также маразм с TEMT - бит есть, но прерывания не вызывает, а при чтении LSR могут сбрасываться прочитанные биты, т.е. в полудуплексе как-то поллить ещё можно, а в дуплексе (да и в полудуплексе для управления 485-м) конец передачи только таймером выгребать. Я, правда, делал ещё вариант с извратом - там где захотелось проверить флаг, взводил программно запрос прерывания (пришлось на всякий случай для блокированного доступа к VIC в User Mode описывать эту процедурку через SWI-функцию) - ну и тем самым LSR читался только в одном месте. Ну и сам прикол с Interrupt Pending принёс достаточно сексу при отладке полного дуплекса, а в примерах и практически всех поучительно/развлекательных материалах по этому поводу такая чушь...

Дядьки, скажите плиз, сколько Пхилипс кушает на 50 Мгц например ? Разногласия у нас с товарищем.

На практике знание, что в пришедшем фрейме один байтик с Frame Error ни к чему другому, как к перерередаче всего фрейма привести не может . Знание того, что ошибка конкретна была в "третьем байте с краю" вполне бесполезно.
Наличие LSR в FIFO имеет некоторый смысл при передаче одиночных (не сгрупиррованных) самодостаточных байтов.
В нормальных линиях ошибок просто НЕТ - личный многолетний опыт с логированием ошибок. Для жутких условий - все аппаратные контроли UART вообще нафиг а сэкономленые parity bit-ы использовать для нормального CRC.

Ну написано так, что можно подумать, что биты то сбрасываются когда захотят, то не сбрасываются когда надо . На самом деле сбрасываются при чтении те самые биты ошибок...
Любой вариант из двух возможных имеет свои достоинства и недостатки. Если хочется не сбрасываемых, то просто хранится копия LSR, что в большинстве случаев более разумно, чем тратить время на доступ к медленной периферии для "посмотреть" и "сбросить". Я лично предпочитаю сбрасываемые чтением флаги и при необходимости хранение их в памяти.

Конец передачи - прерывание по THRE + для тупых 485 применений последующий опрос TEMT.
Хоть в дуплексе, хоть нет.

Макрос вместо команды прямого чтения LSR и все будет читаться и сохранять флаги "в одном месте".

"поучительно/развлекательных" материалы лучше вообще читать надо только мельком. Чушь там совершенно обычное дело вне зависимости от фирмы и авторства . Думать, пробовать, привлекать собственный опыт и еще раз думать.

P.S.
Я отнюдь не идеализирую '550' - встречал и много-много лучше, но он вполне удачен и сбалансирован, что и обеспечило ему долгую жизнь.

Но встраивать в новый 32-битный процессор убогий 8-битный(!) уарт разработки 30-летней давности - несколько, гм, странновато.

Только не надо пиписками мериться. Хоть раз сигнал после HART-модема видел? Это не MODBUS RTU. Там как раз мусор в конце пакета ВСЕГДА, а скорость по линии аж 1200 бод - перезапрос это по минимуму 400 мс. Как-то из-за корявого кремния терять неохота. Предыдущее замечание о крутой ненужности пакета, если FE - также - твоё мнение.


Так когда, через какое время опрашивать этот TEMT? нахрена мне его ждать на низких соростях, например? иначе нахрена мне для UARTа ещё и таймер заряжать? Я, по правде, обычно заряжаю, но на то есть другие причины. Думаю, что это можно было бы выправить в кремни или на худой конец ввести бит - совместимо/несовсем совместимо с 550 и сделать по человечески. Почему-то у Атмеля есть в AVR, AT91, у TI в MSP430, а эти ради крутосовместимости сделали 2 шага назад



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

Ну насчет 30 лет - '550' максимум 20.
Запихнули - и работает. I2C тоже такой-те 1:1 c времен 51. Собственно вполне сбалансированное решение - старинному интерфейсу - классическое решение, ну а силы на CAN-USB-MAC-SPI....
Для отладочной консоли он более чем пригоден.








А куда его битый? На хлеб намазывать или что еще

Сразу и опрашивать до получения удовлетворения.

На низких - ждет задача под это дело заточенная

Ну вот - решение - таймер, причем не только по этой причине .
Иногда можно и банальный пустой байт посылать вместо таймера. Собственно если "проблема" решается обычно несколькими строчками кода - написал и забыл, то это не проблема У меня обычно проблем больше, ибо контроллер со всеми его "проблемами" это самый маленький чип из используемых. В тех других проблем и необходимости их обхода на порядки больше

Ещё раз - битый только последний байт. О пакете говоришь ты. Не надо путать святое с праведным. Ещё раз - мусор после пакета из линии HART ВСЕГДА!!! Что мне ВСЕ пакеты нафиг??? Тебе лишь бы отстоять


Есть же чем заняться. Как опрашивать, когда занят другим, мне объяснять ненужно. Просто элементарная недоделка (я бы сказал ошибка) в кремнии вынуждает её окучивать - дайте прерывание по TEMT и будет мне счастье - ан нет - песню заводят - типа "всю Одессу устраивает, а тебя нет" - бери весь опыт за столько лет и вперёд...


А почему это какой-то UART меня должен на ОС сподвигнуть? Я вааще нафиг не понимаю, почему переключение передачи должно выноситься из драйвера в задачу. Я это в DPC засовываю. И у меня для этого свой маленький шедулер на уровне BSP. Но я бы для суперзадачи переключения передачи и DPC не использовал, если бы крутые перцы из филипса дали мне прерывание.


Вопрос же не в решении, а в том, что лишние телодвижения из-за кривости (не окончательной кремния. А насчёт пустого байта - иногда пользую, но не везде, сами понимаете, это хорошо. С LPC решил с этой практикой завязать - девайсы с MODBUS RTU - оно обязывает)


Если не секрет, какой кремний так радует?

Мне вообще-то все равно .

Счастье никогда не бывает полным .

ОС должна быть вне зависимости от UART и отсутствия в нем желаемых фич

Абсолютно любой описание которого превышает 500 страниц .

Учту Только что посмотрел объём user Guide LPC2364/66/68/78 - 612 страниц))
Мануалы XSсale вааще смотреть не пойду! Пока пива в холодильнике только на LPC 8-D

Тааак А можно с этого момента поподробнее??? Эррату читал, вроде ничего фатального про i2c не нашёл...

Сообщение отредактировал serj_obninsk - Apr 10 2007, 13:56