AlexeyT

Ну у Уоррена есть примеры сверхбыстрого вычисления sqrt для float. А на сколько быстрее? Сам пока оценить не могу, нет ни компилятора, чтобы ассемблерный листинг посмотреть, ни само собой отладочной платы. Может кто-нибудь дать оценку?

Всем доброго дня! Есть вопрос: какие операции с плавающей точкой выполняются быстрее - умножение или деление? То есть, как эффективней считать нормировку на ядре Arm: double a; double b, c, d;//значения присваиваются в ходе выполнения программы a = sqrt(b*b + c*c + d*d); b /= a; c /= a; d /= a; Или: double a; double b, c, d;//значения присваиваются в ходе выполнения программы a = 1./sqrt(b*b + c*c + d*d); b *= a; c *= a; d *= a; Ядрa: Cortex-M1 и Cortex-M4F (что не особо важно, т.к. расчеты должны быть в формате double и плавающая запятая в Cortex-M4F не поможет) Спасибо

Вот страница 301 (описание с сайта Миландра) и тут четко сказано, чему равна предельная частота UART. Можно ткнуть меня носом в место, где написано про "UART до 9 Мбит/сек"?

Мы используем Миландровский 1986ВЕ1Т с тактовой 144 МГц. На такой частоте по Вашей оценке можно реализовать программный контроллер RS-485 со скоростью 2 Мбит/с?

Спасибо за ответы, только у Миландра - это приемопередатчики, а нужен бы специализированный контроллер. Почему не можем использовать UART - потому что скорости не хватает - 921600 бод, а нам надо около 2 Мбит (RS-485 с такими скоростями позволяет работать)

Всем привет! Нет ли у кого-нибудь информации по отечественным ARM-процесорам с встроенным контроллером RS-485? Может быть, кто о разработках таких знает? Может отдельная отечественная микросхема существует? Сразу отвечаю, что Гугл не помог

Никакого секрета. Используем свой камень 1914ВА018 (http://mvc-nn.ru/продукция/микропроцессоры-и-микроконтроллеры/), очень стойкий ко всякой гадости (проверено испытаниями). Еще раз спасибо всем за ответы

Есть 4 кБ ПЗУ с загрузчиком, зашитым на заводе (намертво, не Flash). Пользователю оно доступно только на чтение. Процессор стартует из него. Для пользователя есть 128 кБ ОЗУ под инструкции и 64 кБ ОЗУ под данные. Пользовательская программа может появиться в ОЗУ двумя способами: через JTAG или в результате работы заводского загрузчика. После чего управление передается на нее способом, описанным в первом посте, т.е. без сброса. Именно потому, что раньше проблем не было, ожидал - это способ, используемый заводским загрузчиком. "Магические процедуры" - типа __main, которая вызывается в векторе RESET. Собственно, и вопрос - в чем отличие? NVIC_SystemReset() - это таки "сброс" или "Передача управления в начало программы"? Периферия - блоки на шинах AHB/APB? Или все-таки регистры SCB? Мысль с WDT проработаю, спасибо.

Уважаемые коллеги, помогите разобраться: Есть процессор на базе Cortex-M4, с FPU. У него есть встроенный загрузчик, но нет ПЗУ - только ОЗУ. Есть подключенные к нему внешняя флэш-память и программатор JTAG. Есть тестовая прошивка - настройка тактовой частоты, СОМ-порта и пока всё, дальше бесконечный цикл while(1) {}. Раньше было больше, но при уменьшении до нынешнего варианта косяк не исчез. Принципиальный момент - NVIC в тестовой прошивке не настраивается, обработчики исключений не переопределены. Последовательность работы: При подаче питания процессор начинает исполнять код заводского загрузчика, анализирует линии задания режима загрузки и переходит в режим исполнения программы из внешней флэш-памяти. Она успешно исполняется, используя прерывания - одно от периферийного блока СнК (контроллер МКИО) и одно внешнее. После чего в какой-то момент надо передать управление другой программе. Имитирую передачу управления. Для этого я выполняю останов (команда "h") процессора через J-Link Commander. А вот дальше есть два варианта развития событий: 1) не_выполняя_сброса, заливаю в ОЗУ инструкций образ тестовой прошивки, пишу во VTOR новый адрес таблицы, указываю новую вершину стека (первое слово прошивки), пишу в PC адрес вектора сброса (второе слово прошивки) и запускаю (команда "g"). После чего снова останавливаю ядро и вижу, что упал в исключение NMI. 2) выполняю сброс (команда "R"), и выполняю те же действия, что и ранее, над той же тестовой прошивкой. После чего останавливаю ядро и вижу, что что ядро спокойно остановлено (NoException). В чем может быть принципиальное отличие этих режимов? Какие регистры SCB нужно сбросить в начале п.1, чтобы состояние стало близким к идеальному, т.е. после Reset? Чем сброс через JTAG отличается от сброса через NVIC_SystemReset() с точки зрения системных процедур, выполняемых перед main?

Всем спасибо! Пойдем чуть дальше - действительно есть возможность доработать аналоговую часть, перенеся сигнал с полосой в 20 МГц на несущую в 15 МГц, например. Дальше - 14-битный АЦП с тактовой 50-60 МГц. При таком раскладе можно быть уверенным, что TigerSharck с тактовой 450 сдюжит?

Есть ламерский вопрос: Может ли сигнальный процессор TigerSharck справиться с такой задачей: У нас с 14-битного АЦП с частотой 200 МГц поступают оцифрованные отсчеты сигнала (несущая 70 МГц, полоса - 20 МГц). Задача - сбросить спектр сигнала в квадратуру, т.е. разделить его на две ветки, умножить на sin(2*pi*70e+6*t) и cos(2*pi*70e+6*t) соответственно, пропустить результаты умножения через цифровые ФНЧ полосой 10 МГц, получить I/Q компоненты, снизить частоту дискретизации. Дальше с полученными I/Q компонентами делается стандартная обработка. Сейчас мы эту обработку делаем на Virtex5, есть вопрос, может ли с этим справиться TigerSharck с тактовой 450 МГц (конкретно 1967ВЦ2Ф http://milandr.ru/index.php?mact=Products,...t01returnid=68) Понимаю, что вопрос ламерский и заранее благодарю всех желающих посоветовать пользоваться поиском форума, гуглом, чтением книг))) С подобными процессорами дела никогда не имели, а принципиальный ответ заказчику надо дать быстро. Спасибо

Есть ламерский вопрос: Может ли сигнальный процессор TigerSharck справиться с такой задачей: У нас с 14-битного АЦП с частотой 200 МГц поступают оцифрованные отсчеты сигнала (несущая 70 МГц, полоса - 20 МГц). Задача - сбросить спектр сигнала в квадратуру, т.е. разделить его на две ветки, умножить на sin(2*pi*70e+6*t) и cos(2*pi*70e+6*t) соответственно, пропустить результаты умножения через цифровые ФНЧ полосой 10 МГц, получить I/Q компоненты, снизить частоту дискретизации. Дальше с полученными I/Q компонентами делается стандартная обработка. Сейчас мы эту обработку делаем на Virtex5, есть вопрос, может ли с этим справиться TigerSharck с тактовой 450 МГц (конкретно 1967ВЦ2Ф http://milandr.ru/index.php?mact=Products,...t01returnid=68) Понимаю, что вопрос ламерский и заранее благодарю всех желающих посоветовать пользоваться поиском форума, гуглом, чтением книг))) С подобными процессорами дела никогда не имели, а принципиальный ответ заказчику надо дать быстро. Спасибо Update: перенес тему в раздел "Вопросы новичка"

Само собой, указателю tst присваивается адрес массива test_buff[2]. При этом значение int-переменной я получаю, обратившись к *tst. В каком именно месте происходит зависание, сказать не могу, процессор - 1986ВЕ1Т, там с дебагом туго. Вот полный исходник тестового кода, на котором все виснет: unsigned char test_buff[20] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20}; unsigned char *tst_point = &test_buff[0]; unsigned int *tst; unsigned int temp; tst = (unsigned int *)(tst_point + 2*sizeof(unsigned char)); //должны получить 0x06050403 = 100992003 temp = *tst; printf("%d", temp);

???? 1) Мне нужна int-переменная, состоящая из test_buff[2]...test_buff[5]. 2) test_buff[0]<<24 даст все нули, т.к. имеет 8 бит. 3) При чем тут арифметическое сложение, вообще непонятно.

Задача такая - есть массив test_buff, из подряд идущих 4-х элементов которого нужно сформировать переменную unsigned int. unsigned char test_buff[20] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20}; unsigned char *tst_point = &test_buff[0]; unsigned int *tst; tst = (unsigned int *)(tst_point + 2*sizeof(unsigned char)); //должны получить 0x06050403 = 100992003 Т.е. в *tst пытаюсь записать unsigned int, состоящий из байтов массива с 3-го по 6-й. При исполнении этого кода на ARM-процессоре (ядро Cortex-M1) происходит зависание ядра (когда обращаюсь к адресу, некратному 4 байтам). При исполнении этого же кода на ПК - все ок, *tst = 100992003, как и должно быть. Компилятор Keil. Есть идеи, как решить задачу?

Тестовая программа стала работать при вот таких изменениях: 1) НЕ РАБОТАЛО (сваливалось в Hard Fault): main() { ..... qq = simple_proc_int(ww,ee);//Hard Fault ... } 2) ЗАРАБОТАЛО: main() { ... *(volatile unsigned int*)(0x30010000) = 0xFFFF5500; // пишем во внешнюю шину неважно какие значения *(volatile unsigned int*)(0x30010000) = 0xAAAAFF01; // пишем во внешнюю шину неважно какие значения *(volatile unsigned int*)(0x30010000) = 0xFFFF5500; // пишем во внешнюю шину неважно какие значения qq = simple_proc_int(ww,ee);//нормально проходим, в Hard Fault не сваливаемся! ... } Здесь int simple_proc_int(int a, int B) { int c = 0; c += a<<2; c += b<<3; return c; } - элементарная тестовая функция, записанная в другом 32-кБ сегменте памяти. Память данных условно разбита на 2 сегмента по 32 кБ. "Условно" - потому что с точки зрения процессора, вся память представляет собой единый массив до 128 кБ. Проект57 - в верхнем сегменте памяти только тестовые функции, исполняется корректно. Между всеми вызовами тестовых функций стоят обращения на внешнюю шину. Проект58 - линкер закинул в верхний сегмент памяти часть системных функций, но проект исполняется. Между всеми вызовами тестовых функций стоят обращения на внешнюю шину. Проект59 - в верхней части находятся тестовые и часть системных функций. Но обращения стоят только в начале и конце процедуры main. Проект НЕ исполняется, падает в UsageFault при выполнении процедуры a = simple_proc_dbl(b,c). Вроде бы времена обращений - но при пошаговом исполнении из-под отладчика проект59 также не работает. Кто-то может предположить причины такого бреда? _______.rar

Регистр такой есть. SCB->SHCSR (0xE000ED24). Но в нем устанавливаются только UsageFault, BusFault, MemFault. По умолчанию все обработчики были запрещены. При их разрешении и намеренных ошибках процессор стал падать не в Hard, а в Usage или Bus. Но вот основной косяк объяснению не поддается . Имеем один и тот же простейший проект, с чуть разными картами памяти. 64 КБ разбиты на 2 части по 32 КБ. В первом случае (Проект55) в верхнюю область памяти закинуты лишь 3 простых пользовательских функции. Во втором (Проект56) - в верхнюю область линкер на свое усмотрение закинул и часть системных. При этом Проект55 - работает, Проект56 - падает в UsageFault. Активные регистры при падении: LR=0xFFFFFFF9 (9 - использовался основной стек), MSP=0x20005370 (использовано 0xF0 из 0x1000), PC=0x08008080 (UsageFault_Handler), xPSR=0x01000006 (UsageFault) В стеке лежат: LR=0x080080CB (следующая после команды _dadd), PC=0x08008184 (SUBS - вроде ничего страшного. А вот команда перед ней, BMI.W 0x0800033C - условно-подозрительная) xPSR=0x01000000. ______55.zip ______56.zip

Как это можно сделать средствами компилятора для проекта на С? Проверили регистры при падении - действительно, кроме исключения HardFault, есть прерывания, ожидающие обслуживания. Обработчики для них прописаны. Но они маскируемые, и по умолчанию (в программе) не разрешены. Если разрешить их обработку из отладчика, после какого-нибудь из breakpoint'ов, то попадем в исключение DebugMonitor (№=12). Это правильная логика работы, или здесь ?

Про тактирование уже писали - сбрасывали до 100 кГц, результат такой же. Сейчас проверили и с питанием - во всем диапазоне напряжений питания результат такой же. Будем пробовать, т.к. на этом проекте падаем при возврате в основную функцию из вызываемой. Да, и не раз. Повторюсь - при пошаговом исполнении из отладчика (s) программа работает до тех пор, пока пользователю не надоест запускать пошагово. При запуске на исполнение из отладчика (g) - падаем вскоре после начала работы основной функции main. В этом конкретном случае падаем в вызываемой функции putc, во втором вызове по ходу исполнения основной программы. При первом вызове она отработала нормально. С переполнением стека сталкивались в самом начале. С тех пор стека МНОГО:) MSP = 0x20014870 при запуске программы, MSP = 0x20013B00 при падении. Используется 0xD70 из выделенных 0x4000 R0 = 0x40002000, R1 = 0x00000052, R2 = 0x40002000, R3 = 0x000003e8 R12 = 0x2000084C, LR = 0x0800BE47, PC = 0x07FF4FBE, xPSR = 0x21000000 !!! PC улетает ниже области, где лежит программа( Но почему при первом вызове той же процедуры все работает??? По ресету управление передается на 0х0, где должен лежать загрузчик. Как в эмуляторе, так и на железе. Таки да. Микросхема ОКРовская, есть нюансы. Есть вывод, в зависимости от которого обращения в область 0х0-0х1000 отправляются либо на внешнюю шину, либо на внутреннюю ПЗУ с кодом загрузчика.

Эммммм... Какие барьеры и куда напихать? Прошу пояснить

Секция CODE (доступ по I, D шинам) 0x0000_0000-0x0000_0FFF Область для загрузчика, отражается на внешнюю шину 0x0800_0000-0x0805_FFFF Область внутреннего ОЗУ с пользовательской программой 0x1000_0000-0x1FFF_FFFF Область доступа к внешней системной шине Секция DATA 0x2000_0000-0x2000_03FF Область ОЗУ на внешней системной шине 0x2000_0400-0x2001_FFFF Область внутреннего ОЗУ данных, доступ по D шине 0x3000_0000-0x3FFF_FFFF Область доступа к внешней системной шине Peripheral 0x4000_0000-0x4002_F00C Периферия EXT_BUS 0х6000_0000-0x9FFF_FFFF Внешняя системная шина System 0xE000_0000-0xEFFF_FFFF Системная область ядра Чтобы отмести подозрения на загрузчик - он не используется, идет напрямую загрузка bin-файла в ОЗУ через SWD. Потом выставляется MSP, VTOR, PC - и запуск на исполнение. ОЗУ инструкций не разбита на банки, с точки зрения системы - единый блок Тактирование общее на весь блок памяти, всегда включено Просто доступ на чтение/запись есть на всю ОЗУ инструкций, гоняли тестами. DMA есть, но неактивен, больше ведущих на шине нет. Программные Явно нет, стоят значения по умолчанию MPU->TYPE = 0x0000_0800. Унифицированная карта памяти, 8 регионов MPU->CTRL = 0x0000_0000. MPU запрещен Это не мусор, это фрагмент кода). 0x0800_01DC – возврат из вызываемой функции putc(вывод символа по UART) в main. Main занимает пространство 0х0800_B8CA-0x0800_BF6C Затем идет подготовка к передаче нового байта. Вход в следующий putc – 0x8000_01BA, putc занимает адреса 0x0800_01BA – 0x0800_01DC Память по этим адресам есть (см. карту памяти), программа занимает адреса 0х0800_0000-0x0800_CCC0

Думали уже в эту сторону. Не совсем 2, было 3 - один сожгли( Но образцы, которые у нас, прошли отбраковку как на пластине, так и после корпусирования. Поэтому здесь было предположение, что какой-то сбой тестами не обнаруживается. Кроме функциональных тестов производителя, мы сами еще гоняли проблемную область памяти на чтение-запись, сбоев не обнаружили даже на высокой скорости. Кроме того, дефект кристалла не объясняет работоспособность программы при пошаговом исполнении в debug'е

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

Клок сбрасывали до килогерц - все также. Мысль об увеличенном времени перехода через границу посещала, но как её измерить - есть идеи? Располагаем логическим анализатором, подключенным к шине

Любезный Obam, что заставляет Вас думать, что в славном городе НН не пытались решить проблему? Микросхема ОКРовская (если Вам это о чем-то говорит), требовать техподдержки рано. Хотелось бы таки предложений по решению