UserXP

По поводу JTAG лока, если кому интересно, это при переназначении пинов джитага на что-нибудь другое. Отключается хитрой последовательностью описанной в даташите на МК. У люминари есть специальная утилита LM Flash Programmer которая умеет делать JTAG unlock. Взять можно тут http://www.luminarymicro.com/products/software_updates.html на вкладке с утилитами. В моем случае не помогло. Подозреваю что сдох сам МК но причины мне все равно не понятны. Был отправлен запрос в саппорт ТИ, ждем ответа.

а ссылочки нет? я вроде всю документацию просмотрел и поиск по JTAG remap ничего не дал

Да я тоже думаю, что не должно, но проект пустой был абсолютно, две строчки, включение плл, и замер частоты, далее бесконечный цикл. Что такое JTAG remap? И как разлочить?

да да, во время работы я не дергал, я дергал только отключенный девайс. Это в квикстарте еще написано

самое интересное что да, написано... и написано что делать чтобы добиться "максимальной" совместимости проверяю..

да я прекрасно это понимаю что не надо, но есть люди которые хотят затычку от непредвиденных ситуаций.. и при тестах на разных контроллерах шины были получены разные результаты при записи двубайтного числа по нечетному адресу... вот я и хотел уточнить этот момент, описана ли эта ситуация в стандарте на шину p.s. поковырявшись в Гуке нашел вроде нужную табличку, будем надеяться что так оно и есть на самом деле)

Поясните пожалуйста поведение слейва на шине при записи 16-ти разрядного числа в нечетный адрес. Как я понимаю такого быть не должно, а вдруг случится? в частности интересует сигнал IOCS16 (подразумевается что слейв 16-ти разрядный) я так понимаю что слейв должен запретить передачу двух байт за один такт?

Здравствуйте. Нужна подсказка. Значит так работаю с сабжем в CrossStudio 1.6 build 2 программатор Segger. Написан кусок программы, которая сохраняет некие настройки во флеш. Массив с найстройками выглядит так unsigned long Data4Flash[256]; Записывается с адреса 0x10000 256 байт, т.е. не весь массив а 64 первых значения. При настройке проекта FlashDebug все работает на ура. При настройке проекта FlashRelease при установке в Data4Flash[0] значения 0x00 и записи контроллер умирает смертью храбрых и не реагирует на внешние раздражители. В чем может быть причина? Заранее спасибо за любые идеи

Чтобы не быть голословным сейчас у меня такой код while (1) //Главный цикл { if (ArrIn[0]!=0) Common(); //Если пришла посылка по уарту - обработать if (fADC==2) // если запущен АЦП висим тут { while (!ADCSTA) {} //Ждем завершения преобразования LED_OFF; if (ADCCP==1) { ADCResult[ADCCount/2] = MY_ADCDAT; //Сохраняем результат ADCCP = 0x02; } else { ADCResult[48+ADCCount/2] = MY_ADCDAT; //Сохраняем результат ADCCP = 0x01; } ADCCount++; T0CON |= BIT7; if (ADCCount>95) //если набрали 96 байт { T0CON &= ~BIT7; // останавливаем запускающий таймер fADC = 0; //снимаем флаг ADCCount = 0; //обнуляем счетчик } } }

А какова конечная цель работы АЦП? А то в этом примере результат работы как видно неважен :-). Потому что обычно кучу времени съедает раскладка полученных данных в буфер и проверка окончания цикла. А как сконфигурен ADCCON? Там же все зависит от настройки клоков в битах 10-12 и 9-8. Кстати, гнаться за минимальным ADC acquisition time нестоит-тогда нужен мощнай драйвер входа АЦП и ошибки становяться слишком большие. Намного лучше чем в референсном дизайне несделать ftp://ftp.analog.com/pub/www/technology/d...source_code.zip Можно только выиграть на раскладке данных в пямять при многоканальном сборе данных. А дерганье ЛЕДа вообще все тормозит. К сожалению АД не приводит данных по конкретной реализации внутренностей портов ИО, но все помнять проблемы филипса с "дрыгоножеством", когда пришлось вводить дополнительную периферию фастио. Поэтому для измерений лучше выпустить наружу сигнал ADCBUSY и использовать его для контроля быстродействия. Да, я привел пример на котором я увидел что конверсия длиться меньше 1мкс, и запись и перезапуск длятся чуть больше 1 мкс.. Если я обмеряю два канала и рассовываю все по разным массивам то время обработки вырастает в разы... По поводу acquisition time... я тестил разные значения и не заметил ухудшения при установке 2 клоков... ухудшения точности измерений происходят при снижении vref'а ниже 1 вольта :) А ADC clock speed = 000 т.е. делитель частоты = 1; У меня другой даташит :) но именно поэтому функии засунуты в оперативку...

Cначала было так: #define LED_ON GP4CLR = 0x00040000 #define LED_OFF GP4SET = 0x00040000 void My_funk_ram (void) __ram { ADCCON |= BIT0|BIT1|BIT7; //запуск конверсии ADCCON &= ~BIT7; while (1) { while (!ADCSTA){} LED_OFF; ADCResult = (unsigned short)(ADCDAT>>16); ADCCON |= BIT0|BIT1|BIT7; //запуск конверсии ADCCON &= ~BIT7; //защита от случайного запуска по пину LED_ON; } } функция запускается из мейна, т.к. как загнать сам мейн в RAM я так и не понял Потом сделал #define MY_ADCDAT (*(volatile unsigned short *) 0XFFFF0512) и заменил ADCResult = (unsigned short)(ADCDAT>>16); на ADCResult = MY_ADCDAT; судя по ассемблеру минус три инструкции MOV В общем и целом шеф доволен, и меня по большей части не интересуют конкретные ситуации. Возможно есть какие-то глобальные вещи влияющие на производительность о котрых я не знаю...

Скажем так, время сохранения результата и перезапуска АЦП превышает время преобразования в 1,5-2,5 раза даже при размещении обработчиков в RAM... смысл измерять с 1мспс, если я даже сохранять результат так быстро не могу?

Добрый день. Сделал без прерываний в цикле вручную запуск ацп, получил на выходе время между запускоми и завершением конверсии менее 1мкс, при определенных настройках 500-600нс, но время обработки просто ужасное... Посоветуйте способы улучшения быстродействия выполнения кода на ARM. (Пишу на С, компилятор Keil) Заранее благодарен.

Здравствуйте. Суть проблемы в том что я уже три недели не могу получить картину подтверждающую тот факт что АЦП этого контроллера способно выполнить преобразование за 1мкс. Лучший из результатов который я получал был таков: между запуском АЦП и заходом в прерывание FIQ проходило 1,9мкс (500ksps). Контроллер настроен на тактовую частоту 42,7МГц, АЦП настроен на максимальное быстродействие, обработчик прерывания размещен в RAM. Запуск АЦП по таймеру. Хотелось бы спросить ваших рекомендаций на что можно еще обратить внимание, т.к. я первый раз работаю ARM и с 32-х разрядным контроллером вообще. p.s. Еще один странный факт, если в главном цикле делаю мигание леда, через GP4CLR и GP4SET на выходе вижу максимум 10МГц... судя по полученному из кейла ассемблеру там 2 инструкции... на каждую по 2 такта? и где обещанные 40MIPS на 40МГц? Заранее благодарен.