dimay192

Сто пудов раздельные ноги для ядра и для периферии! Имеет смысл сделать внутренний стабилизаторы питания, как это сделано на imx233 (на БлекФинах вроде так же). Тогда питание всего контроллера осуществляется от одного напряжения. Понятно, что уменьшить до одной ноги VDD нереально - все зависит от суммарного потребления микросхемы и насколько скоростные интерфейсы задействованы, они тоже к этому делу капризны. Наиболее критичным здесь оказывается заземление (дребезг земли)! У QFN есть центральный вывод, который как раз для этого и используют - отдельных ног VSS уже не требуется! Довести количество ног питания до разумного минимума, думаю, можно! Кто мешает использовать RGMII (10 ног вроде) или вообще использовать готовый 10/100/1000BASE-T выход (а). LCD Controller'а (=28 пинов) в младших моделях вообще не использовать (не все задачи требуют графику). От SD-шки смысла избавляться, наверно, нет... В общем, набор периферии младшим моделей более похож на периферию контроллера, чем полнофункциональной процессорной системы. Более того, имеет смысл использовать мультиплексоры периферии, как на STM32, что хочешь, то выводишь (в определенных пределах). Это приведет к незначительному удорожанию чипа с одной стороны и к его больше гибкости для конечного потребителя с другой. че то с сообщениями ерунда какая-то - то не отправляются, то по две штуки уходят...

Если кому и придется реализовывать эту идею, то уж точно не мне и не Вам. А те кто это могут сделать, могут и нужную раскладку по ногам и интерфейсам просчитать, так, чтобы всех удовлетворяла, от мал до велика! А чем плохо 100 ног? Это не так и много! Взять средней загруженности контроллер (64-100 ног) и повторить его набор интерфейсов.

Мне представляется это в виде линейки продуктов! Грубо говоря, от QFN64 c процессором на 500-700Мгц, небольшим объемом памяти (32M DDR/64M FLASH) и периферии (10/100/1000 ethernet, uart, spi, usb, ну и другие последовательные интерфейсы), но такие уже способны запускать полноценную ОСь; до FBGA 256(484) (2x1.5G процы,1G DDR/1G FLASH, правда не уверен, что такой объем можно вместить в один корпус) с более широкой периферией. Модели попроще просты в распайке, ПП под них дешевы, работать можно с коленок! Старшие модели в BGA уже для более серьезных поделок! Согласен, что для старших моделей выгода от встроенной памяти уже не так очевидна! Но ведь и контроллеры бывают не на одну сотню ног в BGA (те же STM32F205(207) в корпусе UFBGA176). Раз их делают, значит они кому-то нужны! Возможно младшие модели по набору периферии должны походить на BlackFinы, например BF504F. Да, и кстати народ не от сладкой жизни запускает на них uLinux - больше не на чем из дешевого и простого! Проц достаточно мощный (400-700Мгц), флеши только-только хватает, чтобы залить образ, правда MMU нет! Вот что-то вроде этого, только Cortex-A8 с флешей и оперой на борту, много флеши и оперы. А ссылку можно? Я ссылки коллекционирую, чтобы можно было ими потом воспользоваться, т.к. не уверен, что обсуждаемая здесь концепция скоро появится на рынке. А пока придется жить и работать по-старинке! Дешево! Сердито! Стоит внимания! Но, согласитесь, - это все-таки законченный девайс, который не расчитан для того, чтобы его встраивали куда-то! Можно и его использовать, если вас не смущает борода из проводов внутри вашего девайса для вывода нужных интерфейсов. Да и где гарантия, что его и через 2 года производить будут?

Все верно! За 300$ можно взять и планшетник и ноут! но это массовые продукты, производимые миллионами! А встраиваемые системы - продукт, хоть и не штучный, а тираж его как правило сотни - тысячи штук! производителю таких систем не выгодно продавать товар с небольшой наценкой! Если у Вас есть инфа о дешевых встраиваемых системах (менее 100$, в России, штучно, а не в партии 1000 шт), выкладывайте ссылке здесь! Буду только рад ошибаться в своих суждениях по поводу цен! Честное слово! Поясните плиз, не понял! В чем проблема то! это не то чтобы локальная память (это не кэш), это всего лишь DDR и флеш, упакованые в один корпус с процессором! С точки зрения процессора никаких изменений не происходит - к ним он по-прежему обращается как к внешней памяти! Об этом я упомянул в своей тераде! Вот тут верно! хотя с другой стороны речь идет о мобильном процессоре и мобильной ддр-ке! при не сильно большом объеме должно сканать! Речь не об одно кристалле, а как минимум о трех разных, на разных техроцессах. Это же MCP! кристаллы разной функциональности и разных техроцессов объединяются в одном корпусе. Уж флеш и ддр точно по разным процессам делаются, а их объединяют без проблем!

Честно говоря, не понимаю, почему до сих пор нет подобных сборок! Ведь это крайне удобно - мощь полноценной процессорной системы под управлением Linux/Android/Qnx в одном корпусе LQFP/QFN или, кому угодно, BGA! Более того, больше нет жирной шины памяти! Освободившиеся пины можно либо задействовать для дополнительной периферии либо корпус меньше делать! Технология Multi-Chip Package уже давно существуют. Но она объединяет DDR и флеш в одном флаконе. Почему бы не добавить мощный проц к этой связке! Конечно, тут возникает вопрос типа того, что у каждого потребителя свои запросы на процессорные системы: свой набор периферии, объем памяти и т.д. Но ведь производитель может разработать линейку продуктов. Основной рецепт популярности контроллеров - их низкая цена и исключительная простота использования (в наше время почти каждый может разработать и заказать ПП под LQFP/QFN корпуса, даже дома вытравить). С процессорными системами дела обстоят гораздо хуже. (1) ПП - минимум 6-ти слойка (корпуса BGA) по пятому классу точности, которые получаются дорогими и мало кто в России их производит, в основном Китай. Анализ трассировки на перекрестные помехи и задержки, связанный с жесткими рамками стандарта mDDR/DDR3. Неизбежные ошибки! Переделка!... Я уже не говорю о высоком профессионализме людей, которые этим должны заниматься и занебесных ценах на ПО для разработке (представим на минутку, что у нас у всех лицензионное ПО дома и в офисе - хотя у меня на работе это действительно так) (2) Пайка BGA корпусов без рентген контроля - дело рискованной и не каждому под силу. (3) Разработка BSP. Ну да! Даже в предлагаемой концепции процессорных систем этот этап никто не отменял. Хотя и его наверно можно частично или полностью автоматизировать - набор периферии заранее известен! Поэтому разработка даже опытных, отладочных, экземпляров становится "удовольствием" дорогостоящим! Все это делает подобные системы выгодными только при массовом производстве! Единственный выход - использовать готовые процессорные платы в составе своего продукта! Что в результате имеем: процессор=~10$ (те же TI AM335x) , ddr=~10$, флеш=~10$ (про цены на ddr и флеш не уверен, но где-то так, наверно, за 256МБ). А сколько стоит процессорный модуль - минимум 100$. Гыгыгы.... самая демократичная цена! И это у производителя; у нас же эту цену смело можно умножать на 1.5-2! Мало где встретишь цену ниже 200-300$. И это все с кучей периферии, которую может и использовать то не будешь вообще! Возьмешь Ethernet, UART, ну может LCD... И все! Все остальное болтается мертвым грузом на борде! А ты за это бабло заплатил! Да еще разные формфакторы плат! Для мобильных систем ваще вроде нет никаких стандартов! ну там какие-то доморощенные... типа Qseven, на котором даже UARTа нет - только скоростные последовательные интерфейсы. Короче, зоопарк! А если ты поставил че-то на подобии SODIMM борды, стандартный только разъем, а что на него выводится ничем не регламентируется! Поставил и дальше только его можешь использовать, потому что плата эта будет уникальна и ни с чем не совместима! А если контора, которая их производит откажется их в дальнейшем изготавливать (как у нас произошло), то ...ОПА! - переделка всего с нуля под новый борд! Наиболее приближенным к обсуждаемой концепции можно считать процессор TI OMAP, модель не помню, изготовленный по POP (package on package) технологии, когда процессор садится на плату, а на процессора сверху садится память DDR+FLASH. Но для простых смертных и это не вариант: корпус по-прежнему BGA, да и с пайкой корпуса на корпус еще хуже дела, чем c спайкой BGA корпуса на плату! Есть другой пример! Frescale imx233 в LQFP144 корпусе! Да бог с ним, что это не Cortex-A8, а всего лишь ARM9. Главно, что полноценную ОСь запускает! Вроде даже можно достаточно дешева свою процессорную систему собрать - корпуса все доступные для пайки. Правда DDR там будет только 2-го поколения, прожорливая, потому что в ином случае, это опять же BGA корпус, если вдруг захочется mDDR. Блин! Какая проблема-то была запихнуть DDR и Флеш в тот же корпус! Процессор то сам по себе достаточно маломощный (450 МГц), поэтому диапазон флеш/ddr, которые можно установить, небольшой! Ну и сделали бы линейку продуктов с разным объемом памяти Че-то меня понесло!.... Наболело! Короче, по-моему выгоднее пользовать процессорные системы в одном корпусе (LQFP/QFN/BGA), цена которой будет ~30$, чем процессорную систему на плате за 300$ (неизвестного формфактора) или чем свою делать с нуля! Гораздо приятнее выбирать процессорную систему, удовлетворяющую твоим требованиям, из линейки у одного производителя! Вроде те же TI и Freescale должны все это понимать! При подобном подходе границы между контроллерами и процессорными системами еще больше размываются! Это в любом случае, был бы весьма обширный рынок! Фууууууууу!... Вроде все сказал!... Ваши мнения по теме!?...

Руки никак не доходили отписаться... Проблема была в том, как написал Спенсер Оливер, что не все кристаллов при чтении адреса 0x1ff8004c возвращают размер флеши. Он эту ситуацию учел (коммиты 055abd... и 531fbf...)! Теперь действительно, "полет нормальный"....

Свежая! Возможно даже слишком свежая - из гит-репозитория собирал! Я бы был склонен думать, что она даже сырая, но ведь с stm32f103 проблем-то нет... Да и после гугулежа не нашел, чтобы народ жаловался на работу openocd с stm32l.

Решил переложить пару проектов с STM32F103CB на STM32L151CB. Столкнулся с проблемой: openocd не определяет размер флеш-памяти и ID чипа. Вот лог на команду flash info 0: Три платы - один результат! Думал может из-за того, что флешка заблокирована, но stm32f1xx при тех же условиях по-прежнему определяет объем флешки и выдает ID. так что, полагаю, дело не в этом... Тут собственно два вопроса: 1. из-за чего это может происходить 2. каким наборам команд использовать для управления Второй вопрос возник из-за того, что для stm32f1 есть отдельный набор команд (stm32f1x unlock 0, stm32f1x mass_erase 0,...), а для stm32lx подобного нет. Для стирания флеши попробовал такую команду: flash erase_address pad unlock 0x08000000 0x0001ffff но она не сработала ни для stm32f1x, ни для stm32lx (для последней она не сработала, помимо прочего, все по той же причине: не видит флешку)

Ок... Общее направление действий понял... Пока решил не заморачиваться за С++ (к сожалению мало времени, чтобы ковырять библы). Перевел тот же проект на С и все встало на места - лишнего не тащит, размер кода пришел в норму... А разобраться надо будет обязательно! Но пока и так сойдет! /******************************************************** ************ Всем спасибо за внимание и участие! ************ ********************************************************/

Значит такс: 1.проект на С++ В общем, структура кода приблизительно такова: Главная ф-ция: ResourceManager RM; int main(void) { /*!< At this stage the microcontroller clock setting is already configured, this is done through SystemInit() function which is called from startup file (startup_stm32f10x_xx.s) before to branch to application main. To reconfigure the default setting of SystemInit() function, refer to system_stm32f10x.c file */ RM.start(); } Содержит два класса Первый, базовый class PlatformAbstractionLayer { public: PlatformAbstractionLayer(); virtual ~PlatformAbstractionLayer(); inline void confGPIO(void); inline void confConnection(void); inline bool confSystemTimer(void); protected: ... }; inline void PlatformAbstractionLayer::confGPIO(void) { //Единственное место, где я задействовал библиотеку STM32F10x_StdPeriph_Lib_V3.3.0 ... GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_Init(GPIOB, &GPIO_InitStructure); GPIO_Init(GPIOC, &GPIO_InitStructure); GPIO_Init(GPIOD, &GPIO_InitStructure); ... } inline bool PlatformAbstractionLayer::confSystemTimer(void) { return !SysTick_Config(SystemCoreClock / 1000); } !!!Остальные методы класса пусты!!! второй, наследник class ResourceManager: public PlatformAbstractionLayer { public: ResourceManager(); virtual ~ResourceManager(); inline void start(void); inline void softTimersDecrement(void); private: uint32 SoftTimerTicks[SOFT_TIMER_CNT]; uint32 SoftTimerPeriod[SOFT_TIMER_CNT]; uint32 SoftTimerFlags; inline void confHardware(void); inline void confSoftware(void); }; inline void ResourceManager::start(void) { this->confHardware(); this->confSoftware(); while(1) {} } inline void ResourceManager::softTimersDecrement(void) { uint16 idx; for(idx = 0; idx < SOFT_TIMER_CNT; idx++) { if((this->SoftTimerTicks[idx] != 0) && (--(this->SoftTimerTicks[idx]) == 0)) { this->SoftTimerTicks[idx] = this->SoftTimerPeriod[idx]; this->SoftTimerFlags |= BV32(idx); } } } inline void ResourceManager::confHardware(void) { this->confGPIO(); this->confConnection(); this->confSystemTimer(); } inline void ResourceManager::confSoftware(void) { } 2.опции -fno-exceptions -fno-rtti использовал! 3.Компилил проект четырьмя сборками компилятора а. CodeSourcery б. kgp_arm_eabi_x86_32_20101006 в. Собственная сборка г. Собственная сборка (newlib собирал с опцией (среди прочих, оптимизирующих размер кода) --disable-newlib-supplied-syscalls, с использованием файла-заглушки syscalls.c) Результаты получились такие (размер секции .text в байтах): CodeSourcery - 57936 kgp_arm_eabi_x86_32_20101006 - 5008 Собственная сборка (в) - 10636 Собственная сборка (г) - 7784 При определении класса PlatformAbstractionLayer как абстрактный: class PlatformAbstractionLayer { public: PlatformAbstractionLayer(); virtual ~PlatformAbstractionLayer(); inline void confGPIO(void); inline void confConnection(void); inline bool confSystemTimer(void); protected: virtual inline void softTimersDecrement(void)=0; ... }; ситуация меняется так (размер секции .text в байтах): CodeSourcery - 57936 kgp_arm_eabi_x86_32_20101006 - 41716 Собственная сборка (в) - 65664 Собственная сборка (г) - 64728

Проблема у меня таже, что у AlexeyVoroshen (несколько постов тому назад) - накидал мне компилятор/линковщик всякого барахла под 50КБ во флеху. До определенного момента все было ок (размер кода вроде соответствовал тому, что я писал).... А потом - шаг влево, шаг вправо (даже при добавлении вызова ПУСТОЙ ф-ции) - захламляет флеха не пойми чем. А перед этим говорит, "undefined reference to `_exit' ", "undefined reference to `_sbrk' " "undefined reference to `_sbrk' ", и т.д... Ну на тебе заглушку syscalls.c.... Компилит... Вроде все нормуль... Но размер кода махом увеличивается на 50КБ! А проект- то пока еще пустой... Операторы типа new,... и др. не использовал подавно. .... Собрал тулчейн собственными силами вот из этого {gcc-4.5.1 | binutils-2.20 | newlib-1.18 | gdb-7.2 | openocd-0.5.0} Причем, newlib собирал с опцией --disable-newlib-supplied-syscalls (сказать по правде, немного не понимаю - то ли при этом вообще должны запрещаться системные вызовы, то ли компилятор начинает искать их реализацию в других исходниках).... Ну ладно, в любом случае проблема остается - непомерно великий код. хотя размер целевого кода не должен вылезти за пределы 32К флеши (решил перейти с MSP430 на STM32, а заодно и перенести (переписать) существующий проект, который на первом занял менее 10КБ). Брать STM32 со 128КБ флешой ради 50КБ ховнятены (прошу прощения за мой французский) - стремно. Как же мне вразумить компилятор не тащить то, че он не должен тащить (не нужны мне системные вызовы, обработчики исключений, ... - без них как то работал на MSP-шнике)?!!!!!!!!!!!!!!! С какими ключами можно собрать компилятор, чтобы тот размещал в памяти исключительно целевой код и самый минимум из необходимого, не относящегося к целевому коду?!!!!!!!!!!!!!!!

Клен, а ты делаешь сборки тулчейной для linux? или быть может выложишь исходники (исходники или патчи) с краткой инструкцией по самостоятельной сборке (опции сборки, ...) :) Меня интересует тулчейн для армов

чес слово, не знаю, не пробовал... желания такого не возникало... Сейчас пытаюсь получить рабочую среду (редактор,компилятор, отладчик,...) для линукса, чтобы можно было полностью уйти от винды... IAR - единственно, что меня держит на ней... То самое "барахло" на 400КБ, тоже меня по-началу смутило... подумал, ну блин, с нуля собирать что ли... качнул, установил цигвин (gcc, wget, perl и еще что-то там нужно добавить к установке по умолчанию), распаковал "барахло" в домашний каталог (через файл-манагер из под винды можно закинуть) запускаем цигвин меняем каталог, где лежит скрипт (куда мы только что распаковали) $ cd $HOME/mspgcc4-20100815 запускаем скрипт $ ./buildgcc.pl Далее, отвечаем на вопросы, которые по ходу дела вываливаются (о версиях софта, что мы желаем установить)... Сборка начинается... Что делать с собранным пакетом в винде... Х. её З.... (может с этого места кто другой рассказ продолжит...) Дальше я наткнулся на готовую сброку (20100218-msp430-gcc-4.4.3-gdb-7.0.1-insight-6.8.exe (9,5МБ)), которую чудесным образом до того момента не замечал... на том мои эксперименты по сборке mspgcc для винды завершились... Может прижмет... Тогда продолжу... По ходу дела возникает другой вопрос: как приладить GDB7.0.1, который находится в этой сборке к eclipse? С предыдущим вариантом отладчика все понятно было... Была инструкция (весьма удачная, считаю) написанная для дураков... http://www.levap.ru/2009/11/eclipse-mspgcc/ http://www.levap.ru/2009/12/debug-eclipse-gdb/ Что делать с текущей версией? Утилита msp430-gdbproxy в ней не наблюдается... А это значит, что текущая версия gdb (7.0.1) обходится как то без нее! Но как? Я не понял! И поэтому запустил версию gdb-7.0.1 с msp430-gdbproxy из предыдущей сборки mspgcc (3.2.3) Вроде заработало! но коряво... Все хреного... Все шатается... Убожество...! Может кто знает другие методы запуска gdb-7.0.1 из под eclipse?

Да не, вызовом скрипта buildgcc.sh: svn checkout https://mspgcc4.svn.sourceforge.net/svnroot/mspgcc4 cd mspgcc4 && sh buildgcc.sh

Чуть ниже нужно спуститься: All Files -> Каталог gcc-4.4.3-gdb-7.0.1-20100218 -> 20100218-msp430-gcc-4.4.3-gdb-7.0.1-insight-6.8.exe (9,5МБ) Это уже собранный пакет (mspgcc+gdb). "борохло" - это для самостоятельной сборки. Под виндой пользую готовую сборку, пол линухой - собрал самостоятельно, там это в два шага делается... в винде мутки какие-то с цигвином или МинГВ... в общем, ересь какая-то... не стал я заморачиваться...