ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
6 июля
171510 Топик полностью
Vit (07.11.2009 21:25, просмотров: 248) ответил Evgeny_CD на Когда проект будет доделан, я расскажу, почему именно ATxmega была выбрана. Если кратко, все, что Вы изложили - ето набор штампов.
Я факты изложил и выводы из личного опыта. А Вы тезисами размахиваете. 1. Мне пофигу ядро кроме случаев, когда может НЕ ХВАТИТЬ производительности. Если АБСОЛЮТНОГО быстродействия не хватает, то вот тогда пойдут в ход конкретные цифры. Для UART-ов, даже 8-и штук 60 MIPS у LPC выше крыши и ОЗУ хватает на буферы с метками времени (тем более метка грузится за ОДНО копирование). Обычный AVR (опять же обычно) тратит на вход в обработчик каких-то 17 тактов. Но как только поднимаем тактовую выше 8 МГц, то тут же заканчивается быстродействие "обычной" медленной SRAM. Т.е. для того, чтобы при повышении тактовой не обо#$%тьсябез внутреннего ОЗУ кони из Atmel родили помесь ужа и ежа - какой-то там контроллер шины, пусть даже и кастрированнный до 4-х бит, это хоть что-то, ну и дешевле лишней сотни кБ встроенной SRAM. Да 8-и-битник и поток 8 бит хорошо коррелируют - никаких выравниваний не нужно и прочей пурги. Но если статус линии и прочее (те же упомянутые метки времени, например) укладывать вместе с данными в буфер (sw FIFO, кольцевой буфер), то уже прелесть 8-и-битника теряется.Короче, чихать я хотел на ядро, если оно мне не мешает;) 2. Большое ОЗУ для указанных целей ставить в серийное изделие, ИМХО, бреднецелесообразно. Обойти же отсутствие такого большого ОЗУ при отладке вполне реально наличием существенного размера буфера во встроенном ОЗУ и быстром канале на сброс в комп (тот же USB) - анализировать мусорник по-хорошему нужно там, где есть средства анализа, а не на коленках их подобие прикручивать. Оперирование же 8-и-битником объёмом ОЗУ более родных 64 кБ это всегда извраткак минимум некомфортно. 3. Если речь о чужих внешних устройствах, то найти такое, которое требует небуферизированного UART-а, нужно очень постараться. Потому аргумент бредовыйне принимается. Сами мосты себя ведут адекватно, если, конечно же, не найдётся шибко криворукого аффтарапрограммиста. 4. IAR под AVR это, ИМХО, лучший продукт IAR. Но AVR это AT90, ATmega, ATtiny, ATmega256x и теперь ещё и Xmega. И всё это похожие, но разные ядра. У мну IAR для AVR был куплен ещё 2.25A и то, что с тех пор индусов у них только прибавилось, можно судить хотя бы по качеству работы с теми же ATmega2560 - больше года оно не умело работать под MK2 после появления в списке 2560, не говоря об остальных "мелочах". По опыту делаю соответствующие выводы о вероятных реалиях работы с xmega. Хорошо, если Вам повезёт. Насчёт ARM - ничего сказать не могу, потому как пользуюсь кайлом, хоть и пробовал, конечно же, IAR. 5. Ну и пусть стОит. Сама задача с 8-ю UART-ами видна аж Вам. Не думаю, что ST или NXP сложно было положить 16 UART-ов на один борт- думаю, что оно просто нафиг надонецелесообразно для 99.9% реальных задач. Возможно я ошибаюсь и это штампнекая солидарность с ведущими производителями. 6. Данных в I2C на 8 МБ, да даже на 1 МБ, - нафига? Короче, опять экзотика. Нафига столько ОЗУ - Ваши вопросы, но вот то, что такой объём скорее всего не нужен, это я первое говорю, в второе - опять же - 8-и-битником ворочать такие объёмы это просто расходовать его быстродействие впустую (это ж сколько команд одно копирование выполняется... просто греем воздух и гоним порожняк) - см. п.2.