Переход Philips->Atmel Опции

[serj_obninsk]

Здравствуйте, господа. Изложу вкратце суть проблемы. Программил я потихоньку на МК LPC210x, и теперь волею судьбы (а точнее, нынешнего работодателя ), перехожу на Atmel AT91SAM7S. Первое впечатление - куда я попал?!!! Вроде опыт работы с процом ARM-архитектуры имеется, а всё равно с ходу ничего не понятно. Такими же остались только команды и архитектура регистров общего назначения. Ну да с этим понятно, это и есть архитектура.

Теперь о грустном. ВСЯ периферия другая

Мой вопрос: подскажите, с чего начать осваивать атмелы, где взять примеры кода, есть ли книжка наподобие "Микроконтроллеры LPC2000" Тревора Мартина.

[sensor_ua]

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

[zltigo]

Отсутствие FIFO для LSR - нельзя доверять всему содержимому FIFO приёма при, например, FE,

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

а при чтении LSR могут сбрасываться прочитанные биты,

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

т.е. в полудуплексе как-то поллить ещё можно, а в дуплексе (да и в полудуплексе для управления 485-м) конец передачи только таймером выгребать.

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

ну и тем самым LSR читался только в одном месте.

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

практически всех поучительно/развлекательных материалах по этому поводу такая чушь...

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

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

[Сергей Борщ]

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

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