jcxz

Резисторы R1-R3 подключите не к +V, а к 3-м GPIO-выводам. Подаёте на них бегущую лог.1 (на остальных двух - 3-е состояние) - т.е. запитываете только одну строку диодов. Далее - там где у вас показано SWITCH - на три входа АЦП. Или на три компаратора (если вам нужен только уровень срабатывания), сигналы с них - на GPIO. Тогда вам не нужно никаких доп. мультиплексоров. Надеюсь понятно объяснил. Раз задача поставлена именно таким образом, значит луч УЖЕ попал. И нужно УЖЕ только определять когда этот грузовик (а может быть - танк?) проезжает (т.е. - величину отклонения луча при некотором воздействии на систему). К гадалке не ходи: первоначально наверняка производится калибровка с центровкой луча по полю. Да и кто сказал что там есть грузовики? Может это прибор для фиксации сейсмических колебаний в отдалённом районе? PS: А насчёт оптики и линз я Вас не зря спрашивал. Так и предполагал что у вас лазер скорей всего. И зря не рассматриваете вариант с камерой. У дискретных диодов наверняка есть разброс характеристик от диода к диоду. А значит из-за этого может быть большая погрешность в определении положения луча (у вас же будет не точечный приём, а некотрое пятно (даже лазер через 1.5км рассеивается)). Для вашей задачи можно предложить такое: Луч лазера попадает на экран. Камера фиксирована относительно экрана и смотрит на этот экран (в отражённом свете, либо матовый экран на просвет). На экран нанесены (чёрные/цветные) метки (решётка) для калибровки исходного положения луча (установка 0). PPS: 1.5км как я понимаю - вполне себе прицельная дальность для танковой пушки или противотанковых средств. Чьи танки собираетесь лазером подсвечивать - сепаратистские или укропские? Ахтырка за кого?

Элементарно: оторвать линии D+/D- оставить только питание и воткнуть. Можно оторвать только от источника D+/D-, высокий уровень на D+ к хосту всё равно подавать. Старт firmware будет, но без энумерации. Скорей всего это и нужно ТС - старт ПО без подключения к хосту.

А каков источник света? Оптика (линзы) нужна? Ну - ломать - не строить. Убрать лишнее, загрубить не сложно. Выбираете из готового кадра пиксели с некоторым шагом и всё.

Изобретаете ИК ПЗС-матрицу? Почему не подходит готовая?

Нормальный МК. У нас на 1778 (это почти то же самое) несколько законченных проектов уже сделано. Никаких проблем. Дальше - открываете usermanual (UM10470.pdf) и вперёд.

Какой такой вопрос я задавал???

Вы нужность или ненужность M4 определяете по необходимости FAT и TCP? Странно как-то...

Глюки в железе CPU + баги HAL? Нет уж, увольте. Лучше просто refmanual. Переносимость не нужна - не Hello world пишем. FatFS - не нужна, а TCP-стек свой есть. Переписать MAC-уровень думаю будет не проблема.

Мне кажется Ваш вопрос больше не про ARM, а про средства разработки. Так что здесь более уместна: http://electronix.ru/forum/index.php?showforum=162 может там лучше подскажут.

Нам и не нужно. Нужно чтобы Tiva не уступал или не сильно уступал STM32 и всё. А это так и есть на требуемой задаче. Для нас важнее - наличие необходимой периферии. Как раз недостаточно. Так как все каналы у STM32 сильно привязаны к запросам периферии, и когда нужно 5 UART + 2 SPI + 1/2 I2C + чтоб ещё резерв остался (и всё это одновременно), то тут всё равно придётся с частью периферии без DMA работать. А у Tiva гораздо легче с зависимостью DMA-каналов от периферии. Да к тому-же при 16 байт FIFO в UART, гораздо легче и без DMA работать. Это как раз неважно. Любая ОС легко переносится между всеми M3/M4-ядрами. А прочие библиотеки мы практически не используем, хватит уже наступать на грабли оставленные написателями халявного софта. Это хорошо когда нужно только FIR-фильтры считать. Но в прикладном ПО такого практически не бывает, а всё гораздо сложнее. И на осциллографе ничего не проанализируешь.

Вряд-ли без асм или intrinsic-функций или без какой другой привязки к компилятору обойдётесь. По-моему это всё ерунда. Лучше-бы тогда уж ROM-бутлоадер OMAP L-137 поправили. :) Чтобы он грузился с SPI-флеши находящейся в Sleep-mode. Это, имхо, полезнее.

Если вопрос в размере и известно, что расстояние до этих ROM-функций позволяет использовать BL (с его укороченной досягаемостью) и известен стартовый адрес образа вашего кода в памяти, то можно в асм-файле определить команды перехода на ROM-функции как обычные константы (не знаю как в gcc, но в IAR): wrap_funcX: DC16 XXXX ;здесь код команды безусловный B с непосредственным 11-битным смещением описать wrap_funcX как функцию, прилинковать в известное место (по известному смещению) своего выходного исполняемого образа и вызывать как обычную функцию.

Да, непонятно мне тоже. Почему-бы SM не сделать просто функцию-обёртку этого ROM-вызова, переключаясь внутри этой обёртки в thumb, а вызывая её обычным образом?

Выбирают всегда исходя из потребностей задачи. Какие у вас потребности? Сколько ОЗУ/флеша нужно? Важна скорость или малое потребление? Какая и сколько периферии? И т.п. По этим критериям и выбирать. Маэйнстрим производителей M3/M4: NXP,ST,TI,ATMEL. Из их поделий и нужно выбирать. А на форумы не смотрите. Подавляющее большинство их обитателей - чайники, а для чайников самый главный критерий - дешёвая(бесплатная) отладка. Поэтому они и выбирают ST. Если Вы профессиональный разработчик и у Вас в планах - делать свои платы, а не использовать только отладки, то цена её не играет роли. Почему-то большинство народу смотрит только на саму цифру в МГц и совсем не думает, что за ней скрывается. И как работает prefetch и кеш, и какая ширина шины до флеш и какова её частота. А ведь может оказаться что эти 180МГц будут тратиться на тупое ожидание данных из флеш. И окажется что Tiva (TI) на 120МГц с 256-битной шиной к флеши гораздо быстрее ST со 128-битной. А может вперёд выйдет Atmel с вдвое большим чем у ST L1-кешем команд. А ведь есть ещё и периферия. И хроническое отсутствие буферов в UARTах и SPI у STM32, резко ужесточит требования к латентности обслуживания периферии (а значит - сожрёт МГц и увеличит потребление). PS: Мы, для своей новой разработки скорей всего выберем Tiva. Из-за требований к кол-ву периферии, интенсивности работы с ней (все UART и SPI имеют FIFO у Tiva), удобству DMA-контроллера для работы с периферией (у STM32 получается затык с его большой потребностью к каналам DMA, ограниченностью их кол-ва и жёсткой привязкой каналов к периферии). А лишние +60МГц STM32 думаю нивелируются удвоенной шириной шины к флеш у Tiva (хоть и почти без кеша :((( ). А раньше мы жили исключительно на NXP...

Линкёр команды не генерит. Максимум, что он может - вставить врапперы (или как оно там называется), когда видит, что цель перехода - вне пределов досягаемости. Когда компилятор генерит выходные секции из исходника, то внутри секции он может вычислить расстояния переходов, и соответственно - использовать команду перехода с непосредственным смещением в теле. Если же переход идёт в другую секцию, то расстояние станет известно только на этапе компоновки, а значит при компиляции оно не известно. Тогда линкёр может вставить враппер с косвенным переходом внутри для увеличения длины перехода. А в данном случае переход идёт из перемещаемой области (для компилятора её адрес не известен) в константный адрес. Тут само собой нужен BX сразу без всяких доп. врапперов.

Как оно может не отличаться? если BX - косвенная адресация, соотв. -32битное смещение, а B - с адресом в команде (т.е. - явно меньше 32 бит).

Выключайте автоген: typedef void (__thumb *iap_entry_typ)(u32 *, u32 *); #define iap_entry ((iap_entry_typ)0x7FFFFFF1) iap_entry(buf, buf); for IAR

Здесь помещение закрытое и наверняка с твёрдыми стенами. А это значит - будет куча отражений и наложений (отражённых сигналов на исходный). Как от стен так и от самих кубиков. Как Вы с этим бороться будете? А тени на пути волны образованные соседними кубиками? А как обеспечите равномерную диаграмму направленности излучения из самого кубика во всех направлениях? Ведь УЗ - довольно направленная вещь. Если уж говорить о триангуляции и если допустимо использование измерений аналоговых величин, то лучше её делать по какой-нить другой физической величине. Например: три источника магнитного поля в макете здания, в кубиках - измерители его напряжённости, макет и кубики - из немагнитного материала.

Тогда не надо кубов. Достаточно кнопки и лампочки "занято" на каждое место. А если всё-же нужно определение координат каждого объекта на поверхности, то можно ещё вариант системы со сканированием: Под полом располагаем решётку из N электродов по оси X и M электродов по оси Y. Даём стартовый импульс (начало сканирования, по радио). И на N-линейку последовательно на каждую пару электродов подаём некую частоту (кГц). Потом ещё стартовый импульс, и теперь на M-линейку бегущий сигнал. В кубике детектор колебаний эл. поля. Определяет момент максимальной амплитуды колебаний и запоминает. По X и по Y. Вобщем сканирование подобно сенсорной клавиатуре. Ну и опрос по радиоканалу. Можно кста без стартового по радио. А передавать код каждой пары электродов в подаваемом на неё сигнале.

Если ставить на каждую площадку только "соответствующий ей кубик", то какой смысл в задаче? Тогда уже сразу заранее известно на какой площадке что может стоять без вариантов. И тогда достаточно просто на каждой такой площадке расположить кнопку - нажимаем её - она занята - подсвечивается лампочкой как занятая. И всё. Судя по описанию, должна быть возможность свободного расположения на поверхности разных по площади и форме элементов. Чтобы определить компоновку пространства ТЦ. Такой 3D-редактор довиртуальной эры. :)

Какое разрешение должно быть у системы определения позиции? Т.е. - сколько дискрет по обоим граням пола? Самое простое решение в этом случае для точного определения позиции может быть типа такого: Берём старый ЭЛТ монитор, располагаем его экраном кверху (плоскость экрана горизонтальна). На этот экран и кидаем кубики. В каждой грани кубика (или только в тех, которыми он может лечь на пол) - оптопара. По RF передаётся сигнал начала кадровой развёртки. Все кубики запускают от него таймеры. Когда луч развёртки попадает на отпопару, регистрируется величина интервала времени, от момента старта кадра. По этой величине определяется координата (строка X столбец). Если нужно определять угол поворота кубика относительно стен "здания", то нужно две оптопары на грань. Ну или магнитный компас внутри кубика. Периодически центр опрашивает все кубики по радиоканалу и считывает их текущие данные о положении. ЭЛТ-монитор - это условность. Функционально это должно быть что-то подобное ему, может просто множество светодиодов в полу. Или готовая большая светодиодная панель. Главное чтобы у неё была строчная и кадровая развёртка (в каждый момент времени горел только один светодиод). И как же определить на каком герконе какой кубик лежит? К тому-же неодимовый магнит вам запросто замкнёт два соседних геркона. Такое решение возможно только если все кубики и занимаемые ими места одинаковы по площади и форме и не нужно знать где какой куб лежит.

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

Маленькая поправочка: может Вы чего-то и должны топикстартеру, но смею предположить, что большая часть здесь присутствующих ничего ему не должна. Так же впрочем как и любому другому вопрошающему.

А что он должен в этот map записать? Ведь по идее линкёр должен (в соответствии с правилами описанными в .cmd) так скомпоновать, чтобы всё влезало. А если не влезла, то что ему писать? Какая секция не влезла? A? А может B? А почему B? Вы последнюю модифицировали секцию A, но она компоновалась первой и поэтому не влезла B, которую уже сто лет не меняли. И вам линкёр должен показать как не влезшую B? Чтобы был map и в случае неудачной линковки, можно создать фиктивную область памяти, в которую разрешить линковку с самым низшим приоритетом (не помню - поддерживает-ли CCS множественное назначение out-регионов?, типа: .text >> RAM_A | RAM_B | RAM_C). И если там окажется какая-то секция - значит она не влезла.

Возможно передаёте со слишком большой скоростью, а в данном модуле нет управления потоком. Заменить на модуль с управлением потоком.