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

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

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

Поздравляю. В свое время тоже попал в такую сетуевину, слегка охренел. Тем более что начинать приходилось с поддержки достаточно сложного проекта а не спримеров. Жесть. Осваивал постольку поскольку, постепенно, через сношения с переферией кристалл, иногда в неприглядных позах. )

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

Я бы начал с чтения errata, очень полезный документ!
Внимательно про всю используемую периферию, а про PLL в первую очередь.
А так.. ничего страшного.

Ясненько Веселуха намечается!


Дык а где взять исходники посложнее мигания светодиодами?
С LPC2000 я в своё время быстро разобрался, начав с книжки, а затем читая даташит и исходники. Здесь первый этап отсутствует как класс

На сайте атмел например
http://atmel.com/dyn/products/tools.asp?family_id=605
можно также на at91.com полазать.
По этому форуму посмотрите, здесь тоже много всякого по этим армам.

Где-то здесь была ссылка на русскоязычную инфу по этим камням. Там кое что есть.

Могу и я конечно скинуть исходники, но боюсь они станут для Вас кошмаром. Кстати светодиодом моргнуть на этом кристалле уже достаточная проблема для новичка. ))

Не понимаю нафиг тебе переходить.
Я вот обратно с SAM7 перехожу на LPC
Более современные модели лишены LPC многих
своих недостатков и на данный момент эта ветьвь
гораздо привлекательнее.
На gaw.ru есть руское описание переферии сам7.

Я ж говорю - не по своей воле. Заказчик хочет так


А вот за это СПАСИБО!!! Отличное описание, на мой первый взгляд.



Да вроде ничего проблемного в примерах (от IAR) я не вижу. А надо бы срочно перейти от примеров к аналого-цифровому преобразованию, I2C, SPI, CAN, да чтобы всё это добро от прерываний крутилось, не занимая ценного процессорного времени

http://projects.org.ua/project/arm/AT91SAM7S256_HOWTO.html
http://forum.ixbt.com/topic.cgi?id=48:5248-6

Берем файл описания регистров из компилятора, тупо копируем в исходник, удаляем все кроме имен регистров, далее берем первый регистр, читаем его описание в даташите, думаем чем его надо проинициализировать в нашей конструкции. И так со всеми регистрами. Когда список закончится - имеем целостное представление о всей периферии. Осваивал так LPC, потом SAM7, потом ADuC. Весь процесс занимает день-два.
Создать самому на основании чтения даташита. На начальном этапе гораздо эффективнее чем копаться в чужом коде. Во всяком случае для меня.

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

Примеры c сайта Atmel значительно ускорят освоение. Чуть-чуть их подрихтовать под себя и костяк драйверов готов.

Примеров там до черта, со всей переферией, с сайта атмела в один прекрасный момент пропали.

ftp://ftp.efo.ru/pub/atmel/MCU/ARM_32bit/...e_patch_driver/

Ну народ пошел.. Атмель намного приятнее, перефирия удобней. А переходить между этими двумя кристаллами - вообще-то дело дня максимум. LPC - АЦТОЙ !!!

обоснуй

чего обосновывать ? DMA на перефирию нету, тока жрет немерянно, половина ног блин - не дай бог куда-нить не туда подтянешь - будет либо крутиться в буте, либо JTAG отрубится либо еще чего, USB движок вообще пьяные индийцы писали, пулл-апов встроенных отключаемых нет, шины I2C open drain only (атмелю никто не помешал верхние транзисторы оставить), ОЗУ мало, возможности зашить чип через USB - нет, защита от копирования слаба настолько, что даже говорить неохота, документация отвратная... короче МУРА
Из преимуществ - только MAM - и тот только немного позволяет компенсировать тормознутость перефирии а усе
PS возражать мне не надо - нравится с ним трахаться - трахайтесь. Мне тоже приходится.

Внятно о минусах - только плохая (вроде уже у "новых" поправили) защита, отсутствие встроенных подтяжек у 21-й серии и отсутствие загрузки кода (первый раз) по USB. Я бы добавил 16550 UART со всеми глюками (никак не исправлены и, похоже, это принципиально;( ). Остальное, ИМХО, от предвзятости и "неумения их готовить". Ещё ты забыл пару плюсов LPC - 32-бит таймеры с внятными приспособами, FastIO (DMA - нафиг). Загрузчик через USB от yuri_t есть http://www.tnkernel.com/usb_fw_upgrader.html (интересно, почему Юрий Тёмкин решил поддержать не Атмел? - уже здесь обсуждалось). Альтернативы 23-й серии по факту у Atmel вааще нет (с подтяжками/растяжками и с опендрейн ногами филипs решил "пойти навстречу пожеланиям трудящихся", проложил приятные 2K NVRAM).
У меня на одном таймере LPC2138, запущенном с тиком 100 нс и никогда не выключающемся, реализованы системный таймер, интервальный таймер и DPC (deferred procedure calls). При этом пока не нашёл, нафига мне второй, а в 2378-м их вааще аж 4... SPI + 2 SSP..., ещё не пробовал встроенный контроллер SD/MMC...
Конечно, есть моменты, где свои преимущества у Atmel, но рьяно хаить LPC не стОит.

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 не нашёл...