И что? Только для вашего проекта "контора" берет CCS и прочие "накладные"?

Где нет совместимого ряда?! У AVR совместимые линейки AtMega48/88/168/328 (32 ногий) AtMega8535/164/324/644/.... (44 ногий)AtMega165/325/645/128/2561/.... (64 ногий) AtMega3250/6450/1280/2560/.... (100 ногий).

ЗЫ. Тут недавно пипиcьками мерялись сравнивали старшие камни AVR с младшими ARM. Вот только те кто сравнивали благополучно забыли, что старшие камни это пин-то-пин расширение младших моделей. И их основная задача не с ARM соревноваться, а позволить развить уже существующие работающие проекты.

ЗЫЫ. Мало того, 100-ногий корпус имеет очень похожее на 64-ногий расположение лап, что позволяет предусматривать на плате два посадочных места под оба корпуса "один внутри другого".

Сообщение отредактировал ArtemKAD - Jun 27 2009, 19:42

Точнее, не позволить перевести проект на классово чуждую базу


Кстати, да. Мне вот интересно было бы попробовать заменить в одном проекте AT91SAM7X256 на AT32UC3A1256 для сравнения, не ведь не совместимы. А плату делать только ради проверки не хочется.

xds100 стоит копеики, софт можно закончить за эволушн таим 120 днеи. как запаснои вариант могу арендовать комп с лиценсионным ccs, знаю контору где 24/7 программа не пользуется и такои диил не противоречит лицензию.


или я плохо выразился или Вы не то поняли, гуд было бы если вместо атмега можно было припаять арм/ авр32 .

Сообщение отредактировал proba - Jun 27 2009, 20:07

Ойойой - а не слабо продемонстрировать такое решение? Особенно учитывая что оба корпуса одинаковы в размере, но отличаются шагом лап?

MLF64 (9х9) на TQFP100 (14х14) ?


Сильно разные камни. В частности у АРМ/АВР32 слишком много разных Vdd.


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

Moderator:
Вы похоже перепутали тему, здесь об опыте перехода на другую платформу, а не об опыте "цепляния до последнено" c рассказами от "'экономике" и "надежности" и гипотетических "граблях".

Грабли не такие уж и гипотетические. Если почитать ветку по АРМ-ам, то там можно неоднократно найти их описания. В той ветке ведь пишут далеко не начинающие любители и тем не менее шишки набивают...

Ой, не надо! 90% наступающих на грабли не удосуживаются даже почитать мануал. Еще 9% читают, но не дают себе труд понять прочитанное.
И так во всех ветках.

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

Не понял , может я не так объяснил. Если существует РАБОТАЮЩИЙ проект (на AVR) в который надо добавить некоторые дополнительные функции, то экономически оправданней и надежнее (в первую очередь надежнее (предсказуемей) КОД, а во вторую - полностью оттестированная готовая плата) взять более крупный камень того-же семейства чем переходить на другое малознакомое. Или тут может быть иное мнение?! Или будешь утверждать, что портирование всего проекта с AVR на ARM это так-же просто и безглючно как добавление процентов 20-40 кода под ту-же платформу (то-же изделие)?!

Сообщение отредактировал ArtemKAD - Jun 28 2009, 21:32

40% кода НОВОГО кода, если это не 40 байт , а десятки-сотня килобайт уже точно как минимум на грани безразличности к ранее используемой платформе. А в случае, когда основная сложная перриферия внешняя это безразличие наступает много раньше. Приходилось с радостью портировать даже с 8bit ASM на АРМ 'С' за считаные дни,только дабы не заниматься сопровождением и дописыванием, пусть даже 40 байт а не то, что 40 процентов кода.

Совсем рядом находится пост "AVR --> ARM". Там можно порассуждать на общие вопросы. Все они имеют место быть.
Здесь я привёл результаты готового переноса для интересующихся. Специфика была такой, что проект перенесён один в один. Я потратил на это некоторое личное время. В дальнейшем, в таком виде, это использовано скорее всего не будет. Я видоизменю его - добавлю ряд функций, из-за чего это всё и затевалось. Такие возможности (перенос один в один) встречаются нечасто. Именно по этому, я и привёл результаты.

Было бы интересно узнать результаты других подобных переносов. Например того же Rst7. На сколько я понял, у него тоже было что-то подобное, но он "зажал" результаты.

Былобы супер интересно посмотреть на перенос aaarrr "AT91SAM7X256 на AT32UC3A1256".

Всё это не для того, чтобы чем-то там меряться. И даже не для чистого любопытства. Мы же все работаем в конкретной области, где килограмм весит 1000 грамм, и хочется иметь цифровые выражения, на реальных, а не тестовых проектах. Кроме того, можно поделится общими ощущениями перехода. Комфортом работы и прочим. Информация на Сахаре интересна, но очень обезличена.

Повторюсь. Я считаю, что в дальнейшем, переход с камня на камень, будет осуществлятся всё чаще. Семейственость будет поддерживаться всё меньше. На мой взгляд - это объективный процесс.


Именно это я и подчёркиваю.
Для проекта объём которого Вы видете, полный перенос занял менее 2-ух месяцев.
Это при том:
a) что я был не знаком с новым камнем
б) что я не делал перенос ранее
в) что пришлось выполнить полное тестирование (достаточно большой объём)

Думаю, что добавление 20-30% кода под ту же платформу добавило бы значительно больше проблем.

Это как с жигулей пересаживаешся на феррари
Лично по мне ,порадовало большее соотношение РАМ,
а вот периферия не очень сбалансирована,такое ощущение ,как будто с 8 битников перетащили
С VIC контроллером тоже слишком лихо закручен сюжет ,думаю избыточно крут для малых моделей LPC.
А насчет производительности и всего такого ,мне достаточно было глянуть на АСМ команды АРМ ядра ,и я
задал себе один вопрос - почему я раньше не читал таких умных книжек
Короче вывод - ARM рвет AVR ,как тузик грелку

Больше 2-х месяцев?!
Кроме того, не стоит забывать, что "менее 2-ух месяцев" это только перенос. А 20-40% кода все равно придется писать. И через 2 месяца вы все еще в начале пути.
Кроме того, нужна новая плата (новая схема, новые комплектующие, новая разводка). И кто это все делает?

Что-то меня терзают смутные сомнения в практической реализации подобного, если длина кода "не 40 байт", "считанные дни" не измеряются неделями или результат "авось будет работать". Разве-что речь о простых или типовых проектах...