Dir

Похоже ты не понимаешь, что ядро Cortex-M3, как и любого другого ARMа, разрабатывает не фирма-производитель, а ARM и продает/лицензирует любому производителю в виде лицензии на масштабируемую (scalable) топологию. Поэтому с отключенной периферией само ядро по технологии 0,13мкм будет жрать одинаково у любого производителя. Разница - только в периферии. Советую обратиться к первоисточнику вообще и, в частности, почитать о ядре Cortex-M3 http://arm.com/

Ну, вообще-то большое потребление старых Luminary было не от некачественной схемотехники, а от устаревшей технологии производства 0,25мкм. Учитывая, что новые чипы имеют напряжение питания ядра 1,2В, то технология должна быть 0,13мкм. Поэтому ваше предположение о большом потреблении вряд ли чем то обосновано. Понятно, что если запустить встроенный PHY, то потребление будет больше, чем у МК без PHY. Но внешний PHY тоже ведь не святым духом питается... Т.е. в сухом остатке имеем очень достойный современный МК. Один из лучших в своем классе Cortex-M3.

Что значить когда-нибуть? Уже! Полюбуйтесь на один из новых чипов и найдите слабое место ;) http://www.luminarymicro.com/products/lm3s9b95.html Не впопыхах, а по технологии 0,25мкм. И успели, между прочим. Первые выпустили Cortex-M3 на рынок. А то, что продались TI - так Luminary, скорее всего, и создавалась для того, чтобы выгодно продаться. Типичная венчурная фирма типа Cygnal. Не повезло инвесторам. Вряд ли вообще свои бабки отбили. А вот если бы не кризис, то могли бы неплохо заработать.

Само-собой, что на универсальный МК они не тянут. Хотя и АЦП (не только 12-битные SAR, но и 24-битные дельта-сигма есть) и ЦАПы и прецизионная опора там хороши! Исключительная точность, стабильность и линейность. Только опробовав их ADuC7128 и получив мертво стоящий (или перемигивающийся с соседом) младший бит при отсутствии необходимости в калибровке (внутренняя опора там точно 2,5В), понял какое гавно АЦП в т.н. универсальных МК. Учитывая еще и 32-битные таймеры, 6 каналов ШИМ, а в некоторых чипах еще и DDS и квадратурные дешифраторы + PLD на кристале и все-таки ARM7TDMI на 41МГц тактовой - неплохая штучка за 5...8$ :) Могу еще добавить, что флэш там 16-разрядная, поэтому из флэши быстрее работает THUMB-режим (без тактов ожидания на 41Мгц). Но все-таки до 128кб флэши, 8кб ОЗУ, стандартная для МК цифровая периферия, до 41Мгц тактовой, 32-битник - никакого AVRа (см. тему!) и близко по производительности не подпустит. И жрет немного 0,5мА/МГц.

У Analog Devices есть (ADuC7xxx). Правда они в основном под прецизионные аналоговые вещи заточены, но тем не менее ядро ARM7TDMI.

Не в нелинейности дело, а в погрешности коэффициента. Даже при идеальной статической характеристике АЦП и идеальном эталоне 1,2В при Vdda = 3,3В ваш АЦП покажет 1489. С погрешностью дискретизации +/-0,5. При полном отсутствии остальных погрешностей погрешность измерения, например, напряжения 3,3В уже будет 0,5*4095/1489 = +/-1,37, а не 0,5 как при честной опоре 3,3В. При реальных 2-3 единицах на 1,2В получаете после пересчета вполне реальную погрешность измерения 6...9 единиц вблизи конца шкалы. Cкажете, что измеренное значение эталона не 1489, а 1489,1 (после статистической обработки)? Так это еще доказать надо, что случайный процесс стационарный и вы имеете право на такие действия. А это весьма сложная метрологическая задача. К тому же в реальности процесс стационарен только в течение весьма малого интервала времени. Разница между источниками питания и источниками опорного напряжения в том и состоит, что для Vref жестко нормируется как абсолютная погрешность (номинал), так временной и температурный дрейф. Разница этих дрейфов для LDO и Vrеf - порядки. Дело в том, что выходной ток и точность выходного напряжения величины взаимно конфликтующие. Если выходной ток большой, то такой девайс сильно греется, его выходное напряжение дрейфует вследствии изменения температуры. Из-за закона Ома чем больше ток, тем больше падение напряжения на выходном сопротивлении и т.п. Увы, таковы законы физики. Плюс к этому уже упоминавшийся мною ранее нюанс: все ресеты, в т.ч. и BOD завязаны на Vdda, а не Vdd. И разница между Vdd и Vdda не может быть больше 0,3В. Т.е. единственный (как мне кажется) реальный выход сделать АЦП в малоногих чипах более-менее честным - это использовать шунтовую (типа TL431) опору 3В. Обычные (как правило более точные) опоры не годятся, т.к. гробят BOD. И как резюме. Я совсем не спорю с вами. Действительно, в малоногих STM32 существует некое подобие АЦП, которым можно воспользоваться для своих целей. Но то, что там есть трудно назвать классическим АЦП в устоявшемся смысле. В классике соединять ноги питания и Vref категорически не рекомендуется. По вышеизложенным соображениям. STM же из маркетинговых соображений (чтобы покупали ее более дорогие многовыводные чипы) СПЕЦИАЛЬНО воткнула палку в колеса, чтобы ее вытаскивание не обошлось дешевле, чем купить 100-ногий чип. Тем не менее это право фирмы так зарабатывать деньги. Но зачем же врать, что эта периферия называется классический АЦП, что она 12-разрядная и что имеет такое же быстродействие, как и в 100-ногих чипах?

Вы же сами сказали, что калибруете по опоре ~1,2В. Т.е используете при ее измерении ~10 разрядов АЦП, а не 12. Вот вам и цена отсутствия честного входа Vref - снижение эффективной разрядности до 10бит. Плюс к этому необходимость немедленного пересчета каждого измерения (умножение на коэффициент равный отношению Vdda/Vref) пока основное питание не уплыло + периодическое измерение Vref и вычисление поправочного коэффициента. Не бог весть какие затраты для Кортекса, однако существенное ограничение функциональности при использовании ПДП. Такое впечатление, что специально все задумано, чтобы для требовательных к точности и производительности применений использовали 100-ногие МК.

Понятно. Т.е. о старых девайсах, которые по технологии 0,25 мкм. Только неплохо бы уточнить, что эти МК появились на год раньше, чем все остальные Кортексы, в т.ч. и STM32. А новые Luminary (вернее уже TI) очень даже достойные МК с частотами 80...100МГц, кардинально уменьшенным потреблением и весьма впечатляющей периферией. Развиваются ребята. Совершенствуют техпроцесс и архитектуру. Впрочем как и все.

Вы о чем??? Да по сравнению с Luminary все остальные нервно курят в сторонке :disco: http://www.luminarymicro.com/products/lm3s9b95.html

Заявленная точность относительно чего? Vпитания? :( Хотелось бы на Vref внешнюю точную опору посадить, но обычную нельзя, т.к. все ресеты завязаны именно на аналоговое питание, а не цифровое. Поэтому BOD при провале цифрового питания не будет срабатывать. Выкручиваюсь тем, что при Vdd=3,3В, на Vdda ставлю шунтовую опору 3,0В. (такая разница дозволена). Про опоры 2,048 или 2,5В вообще речи не идет. С ЦАПом вообще полная фигня. Коллега точный функциональный генератор хотел сделать малогабаритный. Но как ни крутил с 64-выводным МК, но только на производительности ядра и адаптивной подстройкой уровня ЦАП в зависимости от внешней опоры и выкрутил. Про ПДП речь, естественно, уже не шла. В конце концов плюнул на малогабаритность и заменил чип на 100-выводной. И сразу повеселел, но горький осадок остался... Крик души: и весь этот геморрой только из-за того, что какому-то верхнему мудаку, принимающему в STM стратегические решения, захотелось выпендриться и "сэкономить" 1 пин??? На всей линейке продуктов??? Моя такого не понимает... :(

Основной там косяк - это совмещение выводов Vref и Vdda в малоногих (64 и менее) чипах. На это жалуются все, кто применяет ЦАП и АЦП, но тем не менее STM твердо стоит на своем и ничего даже в будущем менять не собирается :(

Скорость она тоже разная бывает. C Full-speed USB максимальный предел скорости измерений АЦП и передачи его в PC - порядка 0,3... 0,5Msps Т.е. даже скорострельность встроенного 1Msps АЦП до конца не используется. Часто нужна скорость съема информации до 2 ... 4Msps. Вот это и есть ниша SAM3U, недоступная девайсам с full-speed USB. Можно, конечно, из FPGA-пушек этих воробьев пострелять, но можно и из 3,5$ рогатки ;)

Не только кард-ридер, а вообще любое устройство, где требуется высокоскоростной USB-порт. Недаром скорость SPI 48Мб/с. Это чтобы поддерживать SPI скоростные АЦП, ЦАПы, датафлэш и т.п. А это высокоскоростные системы сбора данных и системы управления. Попали в самую точку, ИМХО. Ethernet МАСи сейчас клеапают все, кому не лень. Никто бы и не заметил очередного Ethernet-проца.

Неважно как это реализовано внутри, важно что снаружи ;) А снаружи 96МГц тактовая, USB на 480 Мбит, master SPI на 48МГц, и высокоскоростной порт обмена c флэш-картами (на тактовой 48МГц). А это уж совсем не до боли знакомо. И цена от 3,5$/10К... В общем, долго Атмель молчал по поводу Cortex-ов, но разродился действительно уникальными в своем классе девайсами.

Ну так забей первые 64 байта чем то ненужным. Например: __eeprom __root char eNull[64] @0; Все задокументировано в коде. А зачем редактировали линкер может забыться со временем. Да и быстрее, ИМХО.

А хоть какой-то генератор там есть? Т.е. для программирования нужно, чтобы что-то тикало. Если же вообще глухо, т.е. фьюзами установлен отсутствующий внешний генератор (или резонатор, которого нет), то на вход XTAL1 нужно подать сигнал внешнего генератора. Это можно сделать и с помощью AVReAl. Как это сделать рассказывет сам автор (ключ -о) http://www.ln.com.ua/~real/avreal/ http://www.ln.com.ua/~real/avreal/description.html

Если под "кристаллами" понимаются разные архитектуры (ARM, MSP430, AVR...), то не знаю, не пробовал.Хотя почему бы и нет, если IDE одно. А если разные чипы (например ATtiny24, ATmega64...), то постоянно так работаю. Создаю Workspace для всего девайса, а внутри проекты для разных модулей. Единственно, что имена проектов должны отличаться, т.к. каталоги для проектов в Workspace одни и те же. Т.е. файлы main.c нужно переименовать. Например, по имени проекта.

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

Ну, я воспринял это просто как пример. Типа автору стало лень считать HEX-содержание своего кода.... и понесся обосновывать :) А вот сейчас в спокойной обстановке дома решил исследовать что же на самом деле происходит и ... чешу затылок. Мне никак не удается при любых уровнях оптимизации и вообще без нее добиться того, чтобы компилятор по разному оттранслировал процедуру инициализации WDT. Т.е. вот такой код независимо от того стоит перед ним #pragma optimize=none или нет, написаны команды инициализации в виде команд препроцессору или в виде чисел (закоментарено) все равно транслируются одинаково. void test_WDT(void) { __watchdog_reset(); WDTCSR=(1<<WDCE)|(1<<WDE)|(1<<WDP0); WDTCSR=(1<<WDE)|(1<<WDP0); // WDTCSR=0x19; // WDTCSR=0x09; } ассемблерный код 7 __watchdog_reset(); \ 00000000 95A8 WDR 8 WDTCSR=(1<<WDCE)|(1<<WDE)|(1<<WDP0); \ 00000002 E109 LDI R16, 25 \ 00000004 93000060 STS 96, R16 9 WDTCSR=(1<<WDE)|(1<<WDP0); \ 00000008 E009 LDI R16, 9 \ 0000000A 93000060 STS 96, R16 Наверное поэтому никогда раньше не задумывался над этим вопросом, хотя по привычке всегда использовал #pragma optimize=none Может быть с оптимизацией таки можно заставить компилятор генерировать вызовы функций посредине двух WDTCSR = ..., но надо таки постараться не по детски :) PS. Компилятор последний, 5.20, для примера взята mega48

Тогда вообще ничего не понятно. Почему, как указывалось в http://electronix.ru/forum/index.php?showt...st&p=583723 "Код WDTCSR |= (1 << WDCE) | (1 << WDE); Компилятор действительно генерит код не укладывающийся в 4 такта... Я решал проблему, описываемую автором темы, записью нужного числа непосредственно в регистр, типа того: Код WDTCSR |= 0x01; При этом (как ни странно) код получается нормальный, даже с полной оптимизацией, и число попадает в регистр без лишних тедлодвижений..." Ведь после препроцессора компилятору попадает один и тот же код! Понятно, что препроцессор в стандарт не входит, но ведь получается, что "с точки зрения стандарта" компилятор вполне может разбить константное выражение и использовать его часть для своих оптимизационных ухищрений.

Есть там глава про сторонние эффекты и volatile-переменные. Нужно, конечно, рыться и внимательно читать, но, по памяти, стандарт прямо запрещает оптимизацию ДАЖЕ по времени, если в этом принимают участие volatile-переменные. А тут работу препроцессора взял на себя компилятор и оптимизировал как хотел... Компилятор НЕ ИМЕЛ ПРАВА на такие вольности.

Вот именно, что все это очень странно. Насколько меня учили, порты в МК - это volatile-переменные, поэтому компилятор при оптимизации должен позаботиться о всех сторонних эффектах, если он претендует на совместимость со стандартом "С". Т.е. явное игнорирование разработчиками компилятора стандарта. Попросту говоря, баг. Или не так?

Ладно, пусть будет так ;) А вот 96К ОЗУ, как в LM3S9B95, NXP в серии LPC17xx в ближайшем будущем не планирует.

Итак, смотрим Digi-Key: http://search.digikey.com/scripts/DkSearch...ame=638-1047-ND За 1 шт - 3$ Сравниваем с двумя предыдущими ссылками (вашей и моей) и что видим? Полное равенство цен! Что и требовалось доказать.

Да без проблем ;) Вы лучше дешевый индастриал-диапазона помогите мне отыскать с RMII И что б вся автоматика (в том числе перепутывание ног) была на борту. PS. А насчет техполитики STM согласен. Чего стоит только ликвидания ноги +VREF в малоногих чипах :(